libc0xx mayhem....what to do?

[Dariusz Piatkowski]

Folks!

Here are the contents of m \OS2\DLL sub-directory as they partain to the libc0xx
DDLs:

Directory of G:\os2\dll

10-27-03 5:13p 230785 124 libc04.dll
4-14-04 4:37p 356330 0 libc05.dll
10-03-11 6:07a 48142 0 libc06.dll
10-03-11 6:07a 48142 0 libc061.dll
10-03-11 6:07a 157124 0 libc062.dll
10-03-11 6:07a 157124 0 libc063.dll
10-03-11 6:07a 1345016 0 libc064.dll
8-11-08 5:53a 1353252 124 libc064x.dll
2-01-05 10:21a 562710 0 libc06b4.dll
11-22-99 11:45a 210916 0 LIBCM.DLL
11-22-99 11:45a 57340 0 LIBCN.DLL
11-22-99 11:45a 192386 0 LIBCS.DLL
12 file(s) 4719267 bytes used

..and here are the gccxx specifics:

Directory of G:\os2\dll

2-23-04 3:40p 28718 0 gcc322.dll
10-03-11 6:05a 32801 0 gcc335.dll
1-26-09 6:32a 24416 124 gcc433.dll
8-06-09 10:39a 23266 0 gcc434.dll
11-16-09 11:45p 22569 0 gcc442.dll
12-29-10 5:24p 23691 0 gcc444.dll
5-01-10 8:47a 22647 0 gcc444.dll.previous
12-29-10 8:33p 23691 0 gcc445.dll
12-16-11 4:01a 131447 124 gcc446.dll
12-29-10 12:27a 21899 0 gcc452.dll
6-11-11 9:29p 21888 124 gcc453.dll
11 file(s) 377033 bytes used

So why am I paying attention to this?

Well, the recent experience with VLC 1.1.13 release, where I was missing
gcc446.dll prompted me to try to clean the place up a bit.

For quite some time now I've had an issue with my Firefox installs where all the
4 cores in my machine would wildly spike up and down as long as I was not using
the following environment setting:

SET NSPR_OS2_NO_HIRES_TIMER=1

...therefore, at some point in time, not being able to figure out why I
experienced this problem I simply gave up and left the above CONFIG.SYS
statement in place and happily moved on.

Well, as the VLC issue came up I started looking at the various libc & gcc DLLs
on my system...and boy, there are plenty of them there...lol. What was strange
is that as I upgraded to Firefox 9.0.1 I REM'med out the hires_timer statement
just to check things out. Strangely enough, all of a sudden my PMView 3.61
install started showing problems...same kind of crazy CPU spikes...sure enough,
as I was troubleshooting VLC that is a similar type of a behaviour that I was
seeing.

Long story short I tracked all this down to libc06b4.dll, which I had now
renamed on my system to prevent it from being loaded. End result? As best as I
can tell the Innotek FreeType/2 library is what is relying on this DLL,
narrowing this down to a particualr application I see that OpenOffice 3.1 no
longer works, but to my naked eye, that appears to be the only application which
requires this DLL.

What I can not explain however, is that even without OpenOffice loaded I would
see apps like Firefox & PMView somehow pull libc06b4 into memory. I can see
these in Theseus4 outputs as well as PSTAT outputs.

OK, so given all of the above I'm curious of the following:

1) are there any newer OpenOffice relases which no longer use the libc06b4 DLL?
2) is there a way for me to scan all my OS2 apps to determine which ones have
been linked to the libc06b4 dll?
3) given the above libc & gcc DLL listing, is there a process to determine what
the heck to get rid of?

As always...thanks!
-Dariusz

[Peter Brown]

Hi Dariusz

Post by Dariusz Piatkowski
Folks!
Here are the contents of m \OS2\DLL sub-directory as they partain to the libc0xx
Directory of G:\os2\dll
10-27-03 5:13p 230785 124 libc04.dll
4-14-04 4:37p 356330 0 libc05.dll
10-03-11 6:07a 48142 0 libc06.dll
10-03-11 6:07a 48142 0 libc061.dll
10-03-11 6:07a 157124 0 libc062.dll
10-03-11 6:07a 157124 0 libc063.dll
10-03-11 6:07a 1345016 0 libc064.dll
8-11-08 5:53a 1353252 124 libc064x.dll
2-01-05 10:21a 562710 0 libc06b4.dll
11-22-99 11:45a 210916 0 LIBCM.DLL
11-22-99 11:45a 57340 0 LIBCN.DLL
11-22-99 11:45a 192386 0 LIBCS.DLL
12 file(s) 4719267 bytes used
Directory of G:\os2\dll
2-23-04 3:40p 28718 0 gcc322.dll
10-03-11 6:05a 32801 0 gcc335.dll
1-26-09 6:32a 24416 124 gcc433.dll
8-06-09 10:39a 23266 0 gcc434.dll
11-16-09 11:45p 22569 0 gcc442.dll
12-29-10 5:24p 23691 0 gcc444.dll
5-01-10 8:47a 22647 0 gcc444.dll.previous
12-29-10 8:33p 23691 0 gcc445.dll
12-16-11 4:01a 131447 124 gcc446.dll
12-29-10 12:27a 21899 0 gcc452.dll
6-11-11 9:29p 21888 124 gcc453.dll
11 file(s) 377033 bytes used
So why am I paying attention to this?
Well, the recent experience with VLC 1.1.13 release, where I was missing
gcc446.dll prompted me to try to clean the place up a bit.
For quite some time now I've had an issue with my Firefox installs where all the
4 cores in my machine would wildly spike up and down as long as I was not using
SET NSPR_OS2_NO_HIRES_TIMER=1
...therefore, at some point in time, not being able to figure out why I
experienced this problem I simply gave up and left the above CONFIG.SYS
statement in place and happily moved on.
Well, as the VLC issue came up I started looking at the various libc& gcc DLLs
on my system...and boy, there are plenty of them there...lol. What was strange
is that as I upgraded to Firefox 9.0.1 I REM'med out the hires_timer statement
just to check things out. Strangely enough, all of a sudden my PMView 3.61
install started showing problems...same kind of crazy CPU spikes...sure enough,
as I was troubleshooting VLC that is a similar type of a behaviour that I was
seeing.
Long story short I tracked all this down to libc06b4.dll, which I had now
renamed on my system to prevent it from being loaded. End result? As best as I
can tell the Innotek FreeType/2 library is what is relying on this DLL,
narrowing this down to a particualr application I see that OpenOffice 3.1 no
longer works, but to my naked eye, that appears to be the only application which
requires this DLL.
What I can not explain however, is that even without OpenOffice loaded I would
see apps like Firefox& PMView somehow pull libc06b4 into memory. I can see
these in Theseus4 outputs as well as PSTAT outputs.
1) are there any newer OpenOffice relases which no longer use the libc06b4 DLL?
2) is there a way for me to scan all my OS2 apps to determine which ones have
been linked to the libc06b4 dll?
3) given the above libc& gcc DLL listing, is there a process to determine what
the heck to get rid of?
As always...thanks!
-Dariusz

If it is of any help I do *not* have libc06b4.dll on my system and that
does not seem to affect Innotek Font Engine (2.40) or Seamonkey
(currently 2.6) at all.

Not sure what OO3.10/3.20 uses offhand as that software crashes so
frequently that I do not use it and no longer give it disk space.

I currently have the following libc files installed:-

14-04-04 4:37p 356,330 0 a--- libc05.dll
3-10-11 6:07a 48,142 0 a--- libc06.dll
3-10-11 6:07a 48,142 0 a--- libc061.dll
3-10-11 6:07a 157,124 0 a--- libc062.dll
11-06-07 10:53p 1,349,060 0 a--- libc063.dll
3-10-11 6:07a 157,124 229 a--- libc063.dll.new
3-10-11 6:07a 1,345,016 0 a--- libc064.dll
23-05-08 5:29a 1,349,061 346 a--- libc064x.dll


I *think* that the earlier lic06*.dll files are now "forwarder" dlls
that pass on requests to the libc064.dll file. I am, however, using the
"real" libc063.dll at the moment as I was trying it to see if it helped
smplayer069b3 to actually work - it does not.

If you are using an eCS system you should also check \ecs\dll for
libc*.dll and gcc*.dll files as eCS installs some to that location. I
decided to put all libc and gcc files into ecs\dll to keep them all in 1
place and prevent duplication and possible problems - and on an ecs
system \ecs\dll is usually before \os2\dll in the LibPath.


Regards

Pete

[Dariusz Piatkowski]

Hi Pete!

Post by Peter Brown
Hi Dariusz

Post by Dariusz Piatkowski
Folks!
Here are the contents of m \OS2\DLL sub-directory as they partain to the libc0xx
Directory of G:\os2\dll
10-27-03 5:13p 230785 124 libc04.dll
4-14-04 4:37p 356330 0 libc05.dll
10-03-11 6:07a 48142 0 libc06.dll
10-03-11 6:07a 48142 0 libc061.dll
10-03-11 6:07a 157124 0 libc062.dll
10-03-11 6:07a 157124 0 libc063.dll
10-03-11 6:07a 1345016 0 libc064.dll
8-11-08 5:53a 1353252 124 libc064x.dll
2-01-05 10:21a 562710 0 libc06b4.dll
11-22-99 11:45a 210916 0 LIBCM.DLL
11-22-99 11:45a 57340 0 LIBCN.DLL
11-22-99 11:45a 192386 0 LIBCS.DLL
12 file(s) 4719267 bytes used
Directory of G:\os2\dll
2-23-04 3:40p 28718 0 gcc322.dll
10-03-11 6:05a 32801 0 gcc335.dll
1-26-09 6:32a 24416 124 gcc433.dll
8-06-09 10:39a 23266 0 gcc434.dll
11-16-09 11:45p 22569 0 gcc442.dll
12-29-10 5:24p 23691 0 gcc444.dll
5-01-10 8:47a 22647 0 gcc444.dll.previous
12-29-10 8:33p 23691 0 gcc445.dll
12-16-11 4:01a 131447 124 gcc446.dll
12-29-10 12:27a 21899 0 gcc452.dll
6-11-11 9:29p 21888 124 gcc453.dll
11 file(s) 377033 bytes used

..snip...

Post by Peter Brown

Post by Dariusz Piatkowski
Long story short I tracked all this down to libc06b4.dll, which I had now
renamed on my system to prevent it from being loaded. End result? As best as I
can tell the Innotek FreeType/2 library is what is relying on this DLL,
narrowing this down to a particualr application I see that OpenOffice 3.1 no
longer works, but to my naked eye, that appears to be the only application which
requires this DLL.
What I can not explain however, is that even without OpenOffice loaded I would
see apps like Firefox& PMView somehow pull libc06b4 into memory. I can see
these in Theseus4 outputs as well as PSTAT outputs.
1) are there any newer OpenOffice relases which no longer use the libc06b4 DLL?
2) is there a way for me to scan all my OS2 apps to determine which ones have
been linked to the libc06b4 dll?
3) given the above libc& gcc DLL listing, is there a process to determine what
the heck to get rid of?

...snip...

Post by Peter Brown
I *think* that the earlier lic06*.dll files are now "forwarder" dlls
that pass on requests to the libc064.dll file.

And that's my thinking too...ultimately maybe a short-term fix is to get a
forwarder DLL created, with the same name, basically libc06b4.dll, which would
then forward the calls to the libc064.dll.

Post by Peter Brown
If you are using an eCS system you should also check \ecs\dll for
libc*.dll and gcc*.dll files as eCS installs some to that location. I
decided to put all libc and gcc files into ecs\dll to keep them all in 1
place and prevent duplication and possible problems - and on an ecs
system \ecs\dll is usually before \os2\dll in the LibPath.

No, not using eCS...I'm on Warp4 CP2 FP6 SMP enabled configuration here.

[Dave Yeo]

Post by Dariusz Piatkowski

I*think* that the earlier lic06*.dll files are now "forwarder" dlls

Post by Peter Brown
that pass on requests to the libc064.dll file.

And that's my thinking too...ultimately maybe a short-term fix is to get a
forwarder DLL created, with the same name, basically libc06b4.dll, which would
then forward the calls to the libc064.dll.

Not sure but I wouldn't be surprised if some fundamental data structures
changed between 06b4 and 06x
Dave

[Paul Smedley]

Post by Dave Yeo

Post by Dariusz Piatkowski

I*think* that the earlier lic06*.dll files are now "forwarder" dlls

Post by Peter Brown
that pass on requests to the libc064.dll file.

And that's my thinking too...ultimately maybe a short-term fix is to get a
forwarder DLL created, with the same name, basically libc06b4.dll, which would
then forward the calls to the libc064.dll.

Not sure but I wouldn't be surprised if some fundamental data structures
changed between 06b4 and 06x

Yup which is why Knut didn't create a forwarder...

[Steve Wendt]

Post by Dariusz Piatkowski
10-27-03 5:13p 230785 124 libc04.dll

I doubt you have anything that needs this.

Post by Dariusz Piatkowski
4-14-04 4:37p 356330 0 libc05.dll

Or this, unless you have some really old Mozilla browsers.

Post by Dariusz Piatkowski
8-11-08 5:53a 1353252 124 libc064x.dll

You may not need this, either. If you have anything that still uses it,
nag the person who built the program to update it.

Post by Dariusz Piatkowski
2-01-05 10:21a 562710 0 libc06b4.dll

As you discovered, FT2LIB version 2.6 needs this. You can either revert
to version 2.4 (and get different bugs), or live with it. I hope that
it gets updated sooner rather than later (netlabs.org has the source
code for it), or the apps that use it (OpenOffice being the biggest
culprit, as you noted) switch to real FreeType, or a derivative like
mozfontconfig. I'm not holding my breath, though.

Post by Dariusz Piatkowski
11-22-99 11:45a 210916 0 LIBCM.DLL
11-22-99 11:45a 57340 0 LIBCN.DLL
11-22-99 11:45a 192386 0 LIBCS.DLL

These are IBM DLLs; no idea what uses them.

Post by Dariusz Piatkowski
2-23-04 3:40p 28718 0 gcc322.dll
10-03-11 6:05a 32801 0 gcc335.dll
8-06-09 10:39a 23266 0 gcc434.dll
11-16-09 11:45p 22569 0 gcc442.dll
12-29-10 5:24p 23691 0 gcc444.dll
5-01-10 8:47a 22647 0 gcc444.dll.previous
12-16-11 4:01a 131447 124 gcc446.dll
12-29-10 12:27a 21899 0 gcc452.dll

FWIW, I have all of these, although I'm not sure I need all of them. I
think most of them come in some WarpIn package. My gcc444 is your
"previous" one; perhaps I am missing a bugfix version. Your gcc446
looks like it needs lxlite run on it; I see Paul forgot to do that in
the ZIP archive. :-/

Post by Dariusz Piatkowski
1-26-09 6:32a 24416 124 gcc433.dll
12-29-10 8:33p 23691 0 gcc445.dll
6-11-11 9:29p 21888 124 gcc453.dll

FIW, I removed the first two from my LIBPATH a while ago (along with
29027, 29166, 432, 440, and 441), and so far haven't missed them. I
never had anything that needed the last one. Your mileage may vary,
depending on what apps you have.

Post by Dariusz Piatkowski
1) are there any newer OpenOffice relases which no longer use the libc06b4 DLL?

OpenOffice doesn't need it, but it does need FT2Lib. In turn, FT2Lib
2.6 needs libc06b4, although version 2.4 does not (that probably needs
libc05).

Post by Dariusz Piatkowski
2) is there a way for me to scan all my OS2 apps to determine which ones have
been linked to the libc06b4 dll?

Steven Levine's PMDLL can probably help you here, although I'm not
familiar enough with it to know if you can have it "scan all the apps"
looking for a specific DLL.
http://hobbes.nmsu.edu/h-search.php?key=pmdll

Post by Dariusz Piatkowski
3) given the above libc& gcc DLL listing, is there a process to determine what
the heck to get rid of?

Short of the above, remove what you think you don't want, and see if
anything breaks. :-)

[Dave Yeo]

Post by Steve Wendt

Post by Dariusz Piatkowski
1-26-09 6:32a 24416 124 gcc433.dll
12-29-10 8:33p 23691 0 gcc445.dll
6-11-11 9:29p 21888 124 gcc453.dll

FIW, I removed the first two from my LIBPATH a while ago (along with
29027, 29166, 432, 440, and 441), and so far haven't missed them. I
never had anything that needed the last one.

SeaMonkey didn't break from the lack of gcc441.dll? I screwed up and
forgot to static link it.
Dave

[Steve Wendt]

Post by Dave Yeo

Post by Steve Wendt
FIW, I removed the first two from my LIBPATH a while ago (along with
29027, 29166, 432, 440, and 441), and so far haven't missed them. I
never had anything that needed the last one.

SeaMonkey didn't break from the lack of gcc441.dll? I screwed up and
forgot to static link it.

Apparently not...

[Dave Yeo]

Post by Steve Wendt

Post by Dave Yeo

Post by Steve Wendt
FIW, I removed the first two from my LIBPATH a while ago (along with
29027, 29166, 432, 440, and 441), and so far haven't missed them. I
never had anything that needed the last one.

SeaMonkey didn't break from the lack of gcc441.dll? I screwed up and
forgot to static link it.

Apparently not...

PMdll says it is not a dependency. When I tested gcc 4.4.6 it failed due
to missing gcc446.dll so it seems a bit hit and miss whether a program
will end up with a dependency.
Btw, Mozilla built with 4.4.6 couldn't connect to anything, just an
error, connection refused like if connecting to a non-existent port.
Dave

[Paul Smedley]

Hi Dave,

Post by Dave Yeo

Post by Steve Wendt

Post by Dave Yeo

Post by Steve Wendt
FIW, I removed the first two from my LIBPATH a while ago (along with
29027, 29166, 432, 440, and 441), and so far haven't missed them. I
never had anything that needed the last one.

SeaMonkey didn't break from the lack of gcc441.dll? I screwed up and
forgot to static link it.

Apparently not...

PMdll says it is not a dependency. When I tested gcc 4.4.6 it failed due
to missing gcc446.dll so it seems a bit hit and miss whether a program
will end up with a dependency.
Btw, Mozilla built with 4.4.6 couldn't connect to anything, just an
error, connection refused like if connecting to a non-existent port.

With libc064 or libc063?

Cheers,

Paul

[Dave Yeo]

Post by Paul Smedley

Post by Dave Yeo
Btw, Mozilla built with 4.4.6 couldn't connect to anything, just an
error, connection refused like if connecting to a non-existent port.

With libc064 or libc063?

I tested both, also tested with and without the old 16 bit stack.
Dave

[Paul Smedley]

Hi Dave,

Post by Dave Yeo

Post by Paul Smedley

Post by Dave Yeo
Btw, Mozilla built with 4.4.6 couldn't connect to anything, just an
error, connection refused like if connecting to a non-existent port.

With libc064 or libc063?

I tested both, also tested with and without the old 16 bit stack.

Interesting... as libc064 seems to have introduced a few hihg-mem
related tcpip issues...

But if the GCC 4.4.6 issues happen with libc063 as well then there goes
that theory,.....

[Dave Yeo]

Post by Paul Smedley
Hi Dave,

Post by Dave Yeo

Post by Paul Smedley

Post by Dave Yeo
Btw, Mozilla built with 4.4.6 couldn't connect to anything, just an
error, connection refused like if connecting to a non-existent port.

With libc064 or libc063?

I tested both, also tested with and without the old 16 bit stack.

Interesting... as libc064 seems to have introduced a few hihg-mem
related tcpip issues...

libc064 compiled Mozilla can't load a SSL page (or mailbox), just
quietly fails by loading a blank page.

Post by Paul Smedley
But if the GCC 4.4.6 issues happen with libc063 as well then there goes
that theory,.....

I was wondering the same which is why I tested both libc's
Dave

[Dave Yeo]

My gcc444 is your "previous" one; perhaps I am missing a bugfix version.

The last version of 444 stopped working for compiling Mozilla along with
all the newer ones so as usual with such complex programs, one bug fix
is likely to trigger another.
Dave

[Dave Saville]

On Fri, 30 Dec 2011 05:45:52 UTC, Steve Wendt <***@forgetit.org>
wrote:

<snip>

Post by Steve Wendt
Steven Levine's PMDLL can probably help you here, although I'm not
familiar enough with it to know if you can have it "scan all the apps"
looking for a specific DLL.
http://hobbes.nmsu.edu/h-search.php?key=pmdll

Crashes after pressing "Use" after following instructions: select
'SystemDLL paths' from the options menu. Press the delete button on
the '?:\OS2\DLL' entry (where ? is the drive where you have installed
OS/2) and press the
'Use' button. The tree will be much more interesting now.

T:\TMP\PMDLL.EXE
c000009b
00011fac
EAX=0000020e EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000
DS=0053 DSACC=f0f3 DSLIM=ffffffff
ES=0053 ESACC=f0f3 ESLIM=ffffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:00011fac CSACC=f0df CSLIM=ffffffff
SS:ESP=0053:0005f9cc SSACC=f0f3 SSLIM=ffffffff
EBP=0005f9e0 FLG=00010206

PMDLL.EXE 0001:00001fac

[Andreas Schnellbacher]

Post by Dave Saville

Post by Steve Wendt
Steven Levine's PMDLL can probably help you here,
http://hobbes.nmsu.edu/h-search.php?key=pmdll

Crashes

Version 2.9 beta 4 works much more stable and reliable for me.
Yesterday, I found that it shows some DLLs as missing, although they
exist. (I've forgotten which app it was.) Maybe it's related to the
problems mentioned in the readme. It can be found here:

http://home.earthlink.net/~steve53/betas/

[Dariusz Piatkowski]

Hi Andreas!

Post by Andreas Schnellbacher

Post by Dave Saville

Post by Steve Wendt
Steven Levine's PMDLL can probably help you here,
http://hobbes.nmsu.edu/h-search.php?key=pmdll

Crashes

Version 2.9 beta 4 works much more stable and reliable for me.
Yesterday, I found that it shows some DLLs as missing, although they
exist. (I've forgotten which app it was.) Maybe it's related to the
http://home.earthlink.net/~steve53/betas/

Yup...I have been using Beta4 and it works great indeed. This is what I had
actually used to determine that ft2lib.dll is what is actually linked against
libc06b4.dll, and is actualy being used by OpenOffice on my machine.

[Steven Levine]

On Fri, 30 Dec 2011 13:02:57 UTC, "Dave Saville"
<***@invalid.invalid> wrote:

Hi,

Post by Dave Saville
T:\TMP\PMDLL.EXE
c000009b
00011fac
EAX=0000020e EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000
DS=0053 DSACC=f0f3 DSLIM=ffffffff
ES=0053 ESACC=f0f3 ESLIM=ffffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:00011fac CSACC=f0df CSLIM=ffffffff
SS:ESP=0053:0005f9cc SSACC=f0f3 SSLIM=ffffffff
EBP=0005f9e0 FLG=00010206
PMDLL.EXE 0001:00001fac

Pmdll has pretty limited font support. You are probably missing a
required font issue. Grab

http://home.earthlink.net/~steve53/betas/pmdll29beta4.zip

It should tell you what is missing. Typically it's the SYSMONO font
entry that missing in PM_Fonts.

Steven

[Dave Saville]

On Sat, 31 Dec 2011 01:48:54 UTC, "Steven Levine"

Post by Steven Levine
On Fri, 30 Dec 2011 13:02:57 UTC, "Dave Saville"
Hi,

Post by Dave Saville
T:\TMP\PMDLL.EXE
c000009b
00011fac
EAX=0000020e EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000
DS=0053 DSACC=f0f3 DSLIM=ffffffff
ES=0053 ESACC=f0f3 ESLIM=ffffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:00011fac CSACC=f0df CSLIM=ffffffff
SS:ESP=0053:0005f9cc SSACC=f0f3 SSLIM=ffffffff
EBP=0005f9e0 FLG=00010206
PMDLL.EXE 0001:00001fac

Pmdll has pretty limited font support. You are probably missing a
required font issue. Grab
http://home.earthlink.net/~steve53/betas/pmdll29beta4.zip
It should tell you what is missing. Typically it's the SYSMONO font
entry that missing in PM_Fonts.

Hi Steven

Beta version does not complain but nothing happens when you delete the
entry and hit "use". I gathered from the old readme that *something*
ought to appear.

[Steven Levine]

On Sat, 31 Dec 2011 09:28:29 UTC, "Dave Saville"
<***@invalid.invalid> wrote:

Hi Dave,

Still waiting for New Year to arrive here...

Post by Dave Saville
Beta version does not complain but nothing happens when you delete the
entry and hit "use". I gathered from the old readme that *something*
ought to appear.

Define nothing happens.

What happens depends on the setting of the Options->Load System DLLs
toggle. Toggling this option on has the same effect as emptying the
System DLLs list. Toggle both Options->Load System DLLs and
Options->Test Load DLLs off and run pmdll for firefox.exe. Then
toggle the options on and you will see changes. You will also see
differences depending on the current directory at the time you start
pmdll. Firefox expects to find a number of DLLs in the current
directory.

Steven

[Dave Saville]

On Sun, 1 Jan 2012 06:48:59 UTC, "Steven Levine"

Post by Steven Levine
On Sat, 31 Dec 2011 09:28:29 UTC, "Dave Saville"
Hi Dave,
Still waiting for New Year to arrive here...

Post by Dave Saville
Beta version does not complain but nothing happens when you delete the
entry and hit "use". I gathered from the old readme that *something*
ought to appear.

Define nothing happens.

Nothing appears in the main window.

Post by Steven Levine
What happens depends on the setting of the Options->Load System DLLs
toggle. Toggling this option on has the same effect as emptying the
System DLLs list.

Toggle either way and a popup says "Could not get application type
(2)"

Ha, that goes away after an exe is loaded. As does the original
problem. Not obvious that one needs an exe loaded.

[Steven Levine]

On Sun, 1 Jan 2012 11:02:49 UTC, "Dave Saville" <***@invalid.invalid>
wrote:

Hi Dave,

Post by Dave Saville
Nothing appears in the main window.
Toggle either way and a popup says "Could not get application type
(2)"

That pretty much explains why pmdll left the tree window empty,
doesn't it?

Post by Dave Saville
Ha, that goes away after an exe is loaded. As does the original
problem. Not obvious that one needs an exe loaded.

No, it's a defect. Since you did not have an EXE/DLL selected the
code should be smart enough to not try to regenerate the tree after
the mode change. It's smart enough to do this on start up. I'll fix
this.

Thanks,

Steven

[Dariusz Piatkowski]

Hi Steve!

On Fri, 30 Dec 2011 05:45:52 UTC, Steve Wendt <***@forgetit.org> wrote:

...snip...

Post by Steve Wendt

Post by Dariusz Piatkowski
2-01-05 10:21a 562710 0 libc06b4.dll

As you discovered, FT2LIB version 2.6 needs this. You can either revert
to version 2.4 (and get different bugs), or live with it. I hope that
it gets updated sooner rather than later (netlabs.org has the source
code for it), or the apps that use it (OpenOffice being the biggest
culprit, as you noted) switch to real FreeType, or a derivative like
mozfontconfig. I'm not holding my breath, though.

I'm thinking the libc06b4.dll could be removed in 2 ways:

1) take a gamble and just copy libc064.dll and re-name as libc06b4.dll (only
testing would show the impact I suppose)

2) create a forwarder DLL, name it libc06b4.dll and simply shuffle the call over
to libc064.dll (certainly has some more impacts then I can envision in my mind
at the moment, but that's due to me just not knowing enough about this)

So here is a follow-up question: what would be required for one to take on a
project like re-compiling the netlabs.org source code for the Innotek library? I
see this as a good way for me to get involved in the OS2 support efforts and it
certainly, at least from my perspective, would allow me to alleviate some pesky
issues I've been seeing.

Post by Steve Wendt

Post by Dariusz Piatkowski
2-23-04 3:40p 28718 0 gcc322.dll
10-03-11 6:05a 32801 0 gcc335.dll
8-06-09 10:39a 23266 0 gcc434.dll
11-16-09 11:45p 22569 0 gcc442.dll
12-29-10 5:24p 23691 0 gcc444.dll
5-01-10 8:47a 22647 0 gcc444.dll.previous
12-16-11 4:01a 131447 124 gcc446.dll
12-29-10 12:27a 21899 0 gcc452.dll

FWIW, I have all of these, although I'm not sure I need all of them. I
think most of them come in some WarpIn package. My gcc444 is your
"previous" one; perhaps I am missing a bugfix version. Your gcc446
looks like it needs lxlite run on it; I see Paul forgot to do that in
the ZIP archive. :-/

Here is where I picked up the latest AFAIK GCC runtimes:
http://ignum.dl.sourceforge.net/project/ecsports/GCC%20Runtime%20DLLs/

Post by Steve Wendt

Post by Dariusz Piatkowski
1) are there any newer OpenOffice relases which no longer use the libc06b4 DLL?

OpenOffice doesn't need it, but it does need FT2Lib. In turn, FT2Lib
2.6 needs libc06b4, although version 2.4 does not (that probably needs
libc05).

Yes, precisely as you described. I actually relied on the PMDLL application to
map out the DLL usage and to trace through what uses what in some of the bigger
apps.

Post by Steve Wendt

Post by Dariusz Piatkowski
3) given the above libc& gcc DLL listing, is there a process to determine what
the heck to get rid of?

Short of the above, remove what you think you don't want, and see if
anything breaks. :-)

I have Warp4.52 Toolkit installed on my machine...including VAC4 and C/C++ 3.65
(for better or for worse...lol...yes, I'm showing how out-dated my environment
really is...), but...my point being that I would not hesitate to take a stab at
some of this.

Quite some time ago I was looking at writing a HPFS386Stats application, a sort
of a GUI equivalent of the cache386 utility. Not knowing anything about what the
HPFS386.DLL offers I remember running something against that DLL to export out
the APIs (could have been IMPLIB maybe?). The end result was a text file which
contained all the APIs along with their ID...I wrote some code to call these
various pieces, got some stuff compiling/running, but eventually got stuck on a
problem I ran into...that was just about "2 kids ago"...so yes, a few years
back. But...if back then I was able to take a stab at this, then now I would
like to take a stab at creating the libc06b4 forwarder DLL...if that makes
sense...any pointers?

[Dave Yeo]

Post by Dariusz Piatkowski
Hi Steve!
...snip...

Post by Steve Wendt

Post by Dariusz Piatkowski
2-01-05 10:21a 562710 0 libc06b4.dll

As you discovered, FT2LIB version 2.6 needs this. You can either revert
to version 2.4 (and get different bugs), or live with it. I hope that
it gets updated sooner rather than later (netlabs.org has the source
code for it), or the apps that use it (OpenOffice being the biggest
culprit, as you noted) switch to real FreeType, or a derivative like
mozfontconfig. I'm not holding my breath, though.

1) take a gamble and just copy libc064.dll and re-name as libc06b4.dll (only
testing would show the impact I suppose)

Won't work as the file name needs to match the internal name. With a Hex
editor you can rename DLLs as long as the length of the name doesn't
change (or perhaps gets shorter)

Post by Dariusz Piatkowski
2) create a forwarder DLL, name it libc06b4.dll and simply shuffle the call over
to libc064.dll (certainly has some more impacts then I can envision in my mind
at the moment, but that's due to me just not knowing enough about this)
So here is a follow-up question: what would be required for one to take on a
project like re-compiling the netlabs.org source code for the Innotek library? I
see this as a good way for me to get involved in the OS2 support efforts and it
certainly, at least from my perspective, would allow me to alleviate some pesky
issues I've been seeing.

In theory it should just recompile with a newer GCC.
[...]

Post by Dariusz Piatkowski
Quite some time ago I was looking at writing a HPFS386Stats application, a sort
of a GUI equivalent of the cache386 utility. Not knowing anything about what the
HPFS386.DLL offers I remember running something against that DLL to export out
the APIs (could have been IMPLIB maybe?). The end result was a text file which
contained all the APIs along with their ID...I wrote some code to call these
various pieces, got some stuff compiling/running, but eventually got stuck on a
problem I ran into...that was just about "2 kids ago"...so yes, a few years
back. But...if back then I was able to take a stab at this, then now I would
like to take a stab at creating the libc06b4 forwarder DLL...if that makes
sense...any pointers?

Take a look at the source of libc to see how the current DLL forwarders
are created and extend it to also create a libc06b4 forwarder and hope
that no data structures or functions were changed too much.
Dave

[Dariusz Piatkowski]

Dave,

Post by Dave Yeo

Post by Dariusz Piatkowski
2) create a forwarder DLL, name it libc06b4.dll and simply shuffle the call over
to libc064.dll (certainly has some more impacts then I can envision in my mind
at the moment, but that's due to me just not knowing enough about this)
So here is a follow-up question: what would be required for one to take on a
project like re-compiling the netlabs.org source code for the Innotek library? I
see this as a good way for me to get involved in the OS2 support efforts and it
certainly, at least from my perspective, would allow me to alleviate some pesky
issues I've been seeing.

In theory it should just recompile with a newer GCC.

...snip...

Post by Dave Yeo
Take a look at the source of libc to see how the current DLL forwarders
are created and extend it to also create a libc06b4 forwarder and hope
that no data structures or functions were changed too much.

Alright...lol, need a little push in the right direction here. I am familiar
with the following:

1) ftp.netlabs.org/pub/libc, saw nothing there as far as libc sources...lots of
runtimes, etc.

2) ftp.netlabs.org/pub/gcc/, nothing here either, these appear to be the
run-time environments, toolsets, etc

3) http://svn.netlabs.org/libc, this I think is the right place to be...I d/l'ed
GCC-3.3.5-csd4.zip and GCC-3.3.5-csd4-doc.zip....do I need the
GCC-3.3.5-csd4-src-xxx series as well? Sorry...lol...I'm sure these are
rudimentary type questions to those in the 'know'...but the only way for me to
get even remotely familiar is to ask. I see that
http://svn.netlabs.org/libc/wiki/BuildLibc has a decent description of
tasks...so that's where I'm starting

4) OK, final question (I promise...for this session anyways) is regarding the
libc forwarder DLLs...can you point me to a tree location that I need to focus
on?

Thanks!

BTW: Are the gmane groups live? Is that the correct place to post questions in?

[Dave Yeo]

Post by Dariusz Piatkowski

Post by Dave Yeo
In theory it should just recompile with a newer GCC.

...snip...

Post by Dave Yeo

Post by Dave Yeo
Take a look at the source of libc to see how the current DLL forwarders
are created and extend it to also create a libc06b4 forwarder and hope
that no data structures or functions were changed too much.

Alright...lol, need a little push in the right direction here. I am familiar
1)ftp.netlabs.org/pub/libc, saw nothing there as far as libc sources...lots of
runtimes, etc.
2)ftp.netlabs.org/pub/gcc/, nothing here either, these appear to be the
run-time environments, toolsets, etc
3)http://svn.netlabs.org/libc, this I think is the right place to be...I d/l'ed
GCC-3.3.5-csd4.zip and GCC-3.3.5-csd4-doc.zip....do I need the
GCC-3.3.5-csd4-src-xxx series as well? Sorry...lol...I'm sure these are
rudimentary type questions to those in the 'know'...but the only way for me to
get even remotely familiar is to ask. I see that
http://svn.netlabs.org/libc/wiki/BuildLibc has a decent description of
tasks...so that's where I'm starting

Naturally to look at the source you need to download the source. I'd
advise getting the source using subversion (svn). Should be directions
in the wiki. I used Paul Smedleys build.

Post by Dariusz Piatkowski
4) OK, final question (I promise...for this session anyways) is regarding the
libc forwarder DLLs...can you point me to a tree location that I need to focus
on?

libc-0.6\drc\emx\src\lib. I see the def file for libc06b4 is there as
well as other supporting files.

Post by Dariusz Piatkowski
Thanks!
BTW: Are the gmane groups live? Is that the correct place to post questions in?

They're still live as far as I know but unused
Dave

[Paul Ratcliffe]

Post by Dariusz Piatkowski
1) take a gamble and just copy libc064.dll and re-name as libc06b4.dll (only
testing would show the impact I suppose)

That won't work as the module name is built into the DLL header.
You would need to use DLLRNAME to do the job properly, but it only
works for DLL names which have the same number of characters.

[Dariusz Piatkowski]

Hi Paul!

On Sat, 31 Dec 2011 01:05:10 UTC, Paul Ratcliffe

Post by Paul Ratcliffe

Post by Dariusz Piatkowski
1) take a gamble and just copy libc064.dll and re-name as libc06b4.dll (only
testing would show the impact I suppose)

That won't work as the module name is built into the DLL header.
You would need to use DLLRNAME to do the job properly, but it only
works for DLL names which have the same number of characters.

Thanks for that insight...speaking about taking the 'from the ground up'
approach instead...I see that the existing libc stuff is GCC 3.3.5 based...how
does that compare to attempting to compile this with your latest GCC release?

I am very tempted to take the 'easy way out' and install your complete
environment package...

Thanks!

[Paul Ratcliffe]

Post by Dariusz Piatkowski

Post by Paul Ratcliffe

Post by Dariusz Piatkowski
1) take a gamble and just copy libc064.dll and re-name as libc06b4.dll (only
testing would show the impact I suppose)

That won't work as the module name is built into the DLL header.
You would need to use DLLRNAME to do the job properly, but it only
works for DLL names which have the same number of characters.

Thanks for that insight...speaking about taking the 'from the ground up'
approach instead...I see that the existing libc stuff is GCC 3.3.5 based...how
does that compare to attempting to compile this with your latest GCC release?
I am very tempted to take the 'easy way out' and install your complete
environment package...

You've got the wrong Paul. You want Mr. Smedley, not me. I know virtually
nothing about GCC, apart from having struggled with it to compile ISOFS.

Forwarder DLLs are fairly easy (in IBM VAC++ 3 anyway, no idea about GCC)
if you know what you are trying to achieve, since they are just lists of
imports and exports. Of course, you MUST make sure the interfaces are
the same between libc versions, otherwise you will crash and burn.
This may or may not be easy to deduce. I guess you need to look at all
the relevant source code to be sure.

[Dariusz Piatkowski]

Hi Paul (and this time, I know which 'Paul' I'm addressing too...lol):

On Sat, 31 Dec 2011 11:46:01 UTC, Paul Ratcliffe

Post by Paul Ratcliffe

Post by Dariusz Piatkowski

Post by Paul Ratcliffe

Post by Dariusz Piatkowski
1) take a gamble and just copy libc064.dll and re-name as libc06b4.dll (only
testing would show the impact I suppose)

That won't work as the module name is built into the DLL header.
You would need to use DLLRNAME to do the job properly, but it only
works for DLL names which have the same number of characters.

Thanks for that insight...speaking about taking the 'from the ground up'
approach instead...I see that the existing libc stuff is GCC 3.3.5 based...how
does that compare to attempting to compile this with your latest GCC release?
I am very tempted to take the 'easy way out' and install your complete
environment package...

You've got the wrong Paul. You want Mr. Smedley, not me. I know virtually
nothing about GCC, apart from having struggled with it to compile ISOFS.

...ouch...I'm sorry...I missed this as I was in the 'heat' of looking at the
various ZIPs, LIBs, GCCs and DLLs...sorry again!

Post by Paul Ratcliffe
Forwarder DLLs are fairly easy (in IBM VAC++ 3 anyway, no idea about GCC)
if you know what you are trying to achieve, since they are just lists of
imports and exports. Of course, you MUST make sure the interfaces are
the same between libc versions, otherwise you will crash and burn.
This may or may not be easy to deduce. I guess you need to look at all
the relevant source code to be sure.

I had previously done some VAC++ work with similar issue...and as far as I
remember it was able to grapple my mind around this process...so I'll try here
as well. It seems my biggest obstacle will be to arrange for a properly
structured build environment first. One thing at a time though...no issues
there.

Thanks for your insight!

--