GhostScript problem

[t***@antispam.ham]

For some reason that I don't understand, GhostScript has stopped
working for me. The error message is that it can't find the
GhostScript DLL. Yet PMSeek has no trouble finding the GhostScript
DLL, and it's in the same directory as indicated in the Advanced
Configuration menu of GSView.

The timestamps on the directories are 2010 March, and I'm pretty
sure that it has been used successfully at some point over the
last two years, so I don't understand what could have changed.

I suspect that the error message is misleading in this case.
Some other error is triggering this error.

gs8.64
gvpm.exe version 4.9 (the graphical interface launches just fine;
the file open dialog opens just fine, but after I select a file
for viewing, GSview displays the "Can't load Ghostscript DLL"
error message)

Any ideas?

[t***@antispam.ham]

Post by t***@antispam.ham
For some reason that I don't understand, GhostScript has stopped
working for me. The error message is that it can't find the
GhostScript DLL. Yet PMSeek has no trouble finding the GhostScript
DLL, and it's in the same directory as indicated in the Advanced
Configuration menu of GSView.
The timestamps on the directories are 2010 March, and I'm pretty
sure that it has been used successfully at some point over the
last two years, so I don't understand what could have changed.
I suspect that the error message is misleading in this case.
Some other error is triggering this error.
gs8.64
gvpm.exe version 4.9 (the graphical interface launches just fine;
the file open dialog opens just fine, but after I select a file
for viewing, GSview displays the "Can't load Ghostscript DLL"
error message)
Any ideas?

One other thing tha tmight be worth mentioning: there is a second
copy of the GhostScript DLL on my backup drive. It's possible that
the last time I used GhostView successfully was before I added the
backup drive to the system, but I don't understand why a backup
copy of the DLL could cause problems, given that no path points to
it. Nevertheless, I have vague recollections of reading about
problems with some software if a second copy of a DLL exists
somewhere on the system.

I tried renaming the backup copy, but that didn't help, though I
suppose I might need to reboot to clear the problem.

[A.D. Fundum]

Post by t***@antispam.ham

"Can't load Ghostscript DLL" error message

I tried renaming the backup copy, but that didn't help

What happens when both DLLs are unlocked and renamed? Is the error
message the same then? IOW: is it not able to find the DLL, or is it
not able to load the DLL? Or does a simple rbeoot you're trying to
avoid help?


--

[A.D. Fundum]

Or does a simple rbeoot help?

Please read "a simple reboot". I'ld try that first, BTW. And/or a WPS
reset, a kind of "light reboot" if e.g. your LIBPATH is unchanged.


--

[t***@antispam.ham]

Post by A.D. Fundum

Or does a simple rbeoot help?

Please read "a simple reboot". I'ld try that first, BTW. And/or a WPS
reset, a kind of "light reboot" if e.g. your LIBPATH is unchanged.

I know that eCS has a WPS reset option, but I'm running Warp 4.52 on
this machine. The only way I know of to trigger a WPS reset is to
kill the second instance of PMSHELL. But I've always wondered about
unintended consequences of that.

[Steve Wendt]

Post by t***@antispam.ham
I know that eCS has a WPS reset option, but I'm running Warp 4.52 on
this machine. The only way I know of to trigger a WPS reset is to
kill the second instance of PMSHELL. But I've always wondered about
unintended consequences of that.

IBM had an official utility that did it for WSoD, so it apparently isn't
a problem.

[A.D. Fundum]

Post by Steve Wendt

Post by t***@antispam.ham
I know that eCS has a WPS reset option

I don't know that.

Post by Steve Wendt
IBM had an official utility that did it for WSoD, so it
apparently isn't a problem.

As demonstrated by the well-known WPTools' RESETWPS.EXE.


--

[t***@antispam.ham]

Post by A.D. Fundum

Post by t***@antispam.ham

"Can't load Ghostscript DLL" error message

I tried renaming the backup copy, but that didn't help

What happens when both DLLs are unlocked and renamed?

By "unlocked", do you mean "unused"? I ran psfiles and
verified that the DLL isn't loaded.

Post by A.D. Fundum
Is the error message the same then?

Yes. I renamed the real DLL (the backup copy is still
renamed from the earlier test), and received the exact
same error message.

Post by A.D. Fundum
IOW: is it not able to find the DLL, or is it
not able to load the DLL?

The error message says specifically that it can't
load it.

Post by A.D. Fundum
Or does a simple rbeoot you're trying to
avoid help?

I did reboot fairly recently, but that was before I
renamed the backup copy of the DLL. Yes, I do try to
avoid rebooting, as it interrupts number crunching
jobs that I frequently run in the background, and I
hate to reconfigure my desktop each time as well.

[A.D. Fundum]

I do try to avoid rebooting

Fair enough, no need to explain, but that's your problem. Other
people, including programmers, may not want to waist days on a problem
that would be solved by a full reboot (please do try RESETWPS.EXE
first, I don't WANT you to reboot). Some apps or DLLs may stop working
after a while, and a reboot still is a reasonable suggestion.


--

[A.D. Fundum]

Post by t***@antispam.ham
The error message says specifically
that it can't load it.

No, it doesn't.

If DosLoadModule() failed, then a specific (!), AKA SYSxxxx-, error
message would be any of the following error conditions, while there's
no reason to assume it's 2 due to a renamed backup file. What about
e.g. 4 or 8, after a long period of time without a reboot?

2 ERROR_FILE_NOT_FOUND
3 ERROR_PATH_NOT_FOUND
4 ERROR_TOO_MANY_OPEN_FILES
5 ERROR_ACCESS_DENIED
8 ERROR_NOT_ENOUGH_MEMORY
11 ERROR_BAD_FORMAT
26 ERROR_NOT_DOS_DISK
32 ERROR_SHARING_VIOLATION
33 ERROR_LOCK_VIOLATION
36 ERROR_SHARING_BUFFER_EXCEEDED
95 ERROR_INTERRUPT
108 ERROR_DRIVE_LOCKED
123 ERROR_INVALID_NAME
127 ERROR_PROC_NOT_FOUND
180 ERROR_INVALID_SEGMENT_NUMBER
182 ERROR_INVALID_ORDINAL
190 ERROR_INVALID_MODULETYPE
191 ERROR_INVALID_EXE_SIGNATURE
192 ERROR_EXE_MARKED_INVALID
194 ERROR_ITERATED_DATA_EXCEEDS_64K
195 ERROR_INVALID_MINALLOCSIZE
196 ERROR_DYNLINK_FROM_INVALID_RING
198 ERROR_INVALID_SEGDPL
199 ERROR_AUTODATASEG_EXCEEDS_64K
201 ERROR_RELOCSRC_CHAIN_EXCEEDS_SEGLIMIT
206 ERROR_FILENAME_EXCED_RANGE
295 ERROR_INIT_ROUTINE_FAILED


--

[Peter Brown]

hI

Post by t***@antispam.ham
For some reason that I don't understand, GhostScript has stopped
working for me. The error message is that it can't find the
GhostScript DLL. Yet PMSeek has no trouble finding the GhostScript
DLL, and it's in the same directory as indicated in the Advanced
Configuration menu of GSView.
The timestamps on the directories are 2010 March, and I'm pretty
sure that it has been used successfully at some point over the
last two years, so I don't understand what could have changed.
I suspect that the error message is misleading in this case.
Some other error is triggering this error.
gs8.64
gvpm.exe version 4.9 (the graphical interface launches just fine;
the file open dialog opens just fine, but after I select a file
for viewing, GSview displays the "Can't load Ghostscript DLL"
error message)
Any ideas?

Possibly a libcxxx.dll/gccxxx.dll problem?

Check that any required support libraries are available.


Regards

Pete

[t***@antispam.ham]

Post by Peter Brown

Post by t***@antispam.ham
For some reason that I don't understand, GhostScript has stopped
working for me. The error message is that it can't find the
GhostScript DLL. Yet PMSeek has no trouble finding the GhostScript
DLL, and it's in the same directory as indicated in the Advanced
Configuration menu of GSView.
The timestamps on the directories are 2010 March, and I'm pretty
sure that it has been used successfully at some point over the
last two years, so I don't understand what could have changed.
I suspect that the error message is misleading in this case.
Some other error is triggering this error.
gs8.64
gvpm.exe version 4.9 (the graphical interface launches just fine;
the file open dialog opens just fine, but after I select a file
for viewing, GSview displays the "Can't load Ghostscript DLL"
error message)
Any ideas?

Possibly a libcxxx.dll/gccxxx.dll problem?
Check that any required support libraries are available.

Hmm, that's an interesting possibility. There is a copy of
libc063.dll in the gs8.64\bin directory alongside the gsdll2.dll,
but it is of vastly different size than the one in my Firefox
directory:

Directory of D:\view\ghost\gs8.64\bin

09-02-13 5.32 9.302.561 0 ---- gsdll2.dll
09-02-13 5.32 6.629 0 ---- gsos2.exe
09-02-13 5.32 19.817 124 ---- gspmdrv.exe
07-06-11 22.53 1.349.060 0 ---- libc063.dll

Directory of U:\firefox

12-03-23 4.32 48.142 0 a--- libc06.dll
12-03-23 4.32 48.142 0 a--- libc061.dll
12-03-23 4.32 157.124 0 a--- libc062.dll
12-03-23 4.32 157.124 0 a--- libc063.dll
12-03-23 4.32 157.176 0 a--- libc064.dll
12-03-23 4.32 1.353.208 0 a--- libc065.dll

But it's the same size as the libc063.dll used by the
previous version of Firefox:

Directory of U:\firefox1002

07-06-11 22.53 1.349.060 0 a--- libc063.dll

Is the new libc063.dll used by Firefox just a stub?

[Steve Wendt]

Post by t***@antispam.ham
Hmm, that's an interesting possibility. There is a copy of
libc063.dll in the gs8.64\bin directory alongside the gsdll2.dll,
but it is of vastly different size than the one in my Firefox

Sounds like you have identified the problem. Tried renaming the local
copy of libc063.dll yet?

Post by t***@antispam.ham
Is the new libc063.dll used by Firefox just a stub?

It's a forwarder to libc065, as are the rest of libc06*. These are not
intended to be placed with applications, but installed globally. Mixing
them as you are is almost guaranteed to cause problems, unless you
always use LIBPATHSTRICT with your applications.

[t***@antispam.ham]

Post by Steve Wendt

Post by t***@antispam.ham
Hmm, that's an interesting possibility. There is a copy of
libc063.dll in the gs8.64\bin directory alongside the gsdll2.dll,
but it is of vastly different size than the one in my Firefox

Sounds like you have identified the problem. Tried renaming the local
copy of libc063.dll yet?

That doesn't help. Not sure how it could; the DLL would need to
be somewhere in the libpath for it to work. None of my libc DLLs
are in the libpath.

Post by Steve Wendt

Post by t***@antispam.ham
Is the new libc063.dll used by Firefox just a stub?

It's a forwarder to libc065, as are the rest of libc06*. These are not
intended to be placed with applications, but installed globally. Mixing
them as you are is almost guaranteed to cause problems, unless you
always use LIBPATHSTRICT with your applications.

Would LIBPATHSTRICT even work in this particular case? It should
work for the gvpm front end, but gvpm launches gsos2. Would the
daughter process inherit the LIBPATHSTRICT from the parent process?

[Steve Wendt]

None of my libc DLLs are in the libpath.

I believe this is going to cause you more problems than it is going to
solve.

Would LIBPATHSTRICT even work in this particular case? It should
work for the gvpm front end, but gvpm launches gsos2. Would the
daughter process inherit the LIBPATHSTRICT from the parent process?

That's an excellent question; maybe someone that knows for sure will see
this thread and answer that.

[A.D. Fundum]

Post by Steve Wendt

Post by t***@antispam.ham
Would LIBPATHSTRICT even work in this particular case?

That's an excellent question

Didn't he change "nothing", implying that LIBPATHSTRICT suddenly
stopped working forever?


--

[t***@antispam.ham]

Post by Steve Wendt

None of my libc DLLs are in the libpath.

I believe this is going to cause you more problems than it is going to
solve.

Could you give me an example of how it might cause a problem? That
might help my overall understanding of how DLLs work in OS/2.

For example, if an app needs a DLL, does the system first determine
whether that DLL has been loaded by another app before even checking
the LIBPATH? If so, then I can see a potential for a problem if
there is more than one version of the same DLL. That is, if
GhostScript is trying to use the libc063.dll that Firefox 10.0.2
was using, because it's already loaded, rather than loading the one
in the gs8.64\bin directory (assuming they were different), then
that could be a problem. But Firefox 10.0.5 doesn't even use
libc063; rather, it uses libc065, so right now there isn't anything
else running on my system that uses libc063:

[D:\]psfiles | find "LIBC"
0000 0000 0050 0001 00000100 000000a0 000337e4 0012 0000 W:\OS2\DLL\LIBCM.DLL
0000 0000 0108 0001 00000100 000000a0 00056fea 01fe 0000 D:\THUNDERBIRD\LIBC05.DLL

GhostScript allows the user to specify the path to the GhostScript
DLL. Question: does it use the same path to find libc063? That's
where libc063 is with my GhostScript installation, and GhostScript
did work at some point, so the app must have found the DLL somehow.
Maybe the error message about being unable to load the GhostScript
DLL is being triggered because gs2dll.dll in turn can't load the
libc063.dll.

By the way, I am aware that the "Can't load DLL" message can also
be triggered by having the wrong include path to the gs_init.ps file.
Just wanted to note that my gs_init.ps file exists, and the path to
the file is correct in the Include Path setting.

[Steve Wendt]

Post by t***@antispam.ham
For example, if an app needs a DLL, does the system first determine
whether that DLL has been loaded by another app before even checking
the LIBPATH?

It is my understanding that it will share the version already loaded in
memory, unless you are using LIBPATHSTRICT. Whether it first validates
whether it can be found on the LIBPATH, I'm not certain - some simple
experiments could answer that.

[Steven Levine]

On Sun, 24 Jun 2012 17:51:27 UTC, Steve Wendt <***@forgetit.org>
wrote:

Hi,

Post by Steve Wendt
It is my understanding that it will share the version already loaded in
memory, unless you are using LIBPATHSTRICT. Whether it first validates
whether it can be found on the LIBPATH, I'm not certain - some simple
experiments could answer that.

It depends on how the DLL is loaded. In the case of ghostscript, I
assume it is using DosLoadModule with an explict path to load
gsdll2.dll. This takes BEGINLIBPATH and LIBPATHSTRICT out of the
picture.

Steven

[Paul Smedley]

Dave,

Post by t***@antispam.ham

Post by Steve Wendt

Post by t***@antispam.ham
Hmm, that's an interesting possibility. There is a copy of
libc063.dll in the gs8.64\bin directory alongside the gsdll2.dll,
but it is of vastly different size than the one in my Firefox

Sounds like you have identified the problem. Tried renaming the local
copy of libc063.dll yet?

That doesn't help. Not sure how it could; the DLL would need to
be somewhere in the libpath for it to work. None of my libc DLLs
are in the libpath.

Post by Steve Wendt

Post by t***@antispam.ham
Is the new libc063.dll used by Firefox just a stub?

It's a forwarder to libc065, as are the rest of libc06*. These are not
intended to be placed with applications, but installed globally. Mixing
them as you are is almost guaranteed to cause problems, unless you
always use LIBPATHSTRICT with your applications.

Would LIBPATHSTRICT even work in this particular case? It should
work for the gvpm front end, but gvpm launches gsos2. Would the
daughter process inherit the LIBPATHSTRICT from the parent process?

What does chkdll32 (or pmdll) say about gsdll2.dll? does it require a
gcc*.dll?

Cheers,

Paul

[t***@antispam.ham]

Post by Paul Smedley
What does chkdll32 (or pmdll) say about gsdll2.dll? does it require a
gcc*.dll?

PMDLL says that it requires libc063.dll, which is located in the same
directory as gsdll2.dll, a configuration that apparently worked at one
time.

[Peter Brown]

Hi

Post by t***@antispam.ham

Post by Peter Brown

Post by t***@antispam.ham
For some reason that I don't understand, GhostScript has stopped
working for me. The error message is that it can't find the
GhostScript DLL. Yet PMSeek has no trouble finding the GhostScript
DLL, and it's in the same directory as indicated in the Advanced
Configuration menu of GSView.
The timestamps on the directories are 2010 March, and I'm pretty
sure that it has been used successfully at some point over the
last two years, so I don't understand what could have changed.
I suspect that the error message is misleading in this case.
Some other error is triggering this error.
gs8.64
gvpm.exe version 4.9 (the graphical interface launches just fine;
the file open dialog opens just fine, but after I select a file
for viewing, GSview displays the "Can't load Ghostscript DLL"
error message)
Any ideas?

Possibly a libcxxx.dll/gccxxx.dll problem?
Check that any required support libraries are available.

Hmm, that's an interesting possibility. There is a copy of
libc063.dll in the gs8.64\bin directory alongside the gsdll2.dll,
but it is of vastly different size than the one in my Firefox
Directory of D:\view\ghost\gs8.64\bin
09-02-13 5.32 9.302.561 0 ---- gsdll2.dll
09-02-13 5.32 6.629 0 ---- gsos2.exe
09-02-13 5.32 19.817 124 ---- gspmdrv.exe
07-06-11 22.53 1.349.060 0 ---- libc063.dll

The above looks like the original libc063.dll

Post by t***@antispam.ham
Directory of U:\firefox
12-03-23 4.32 48.142 0 a--- libc06.dll
12-03-23 4.32 48.142 0 a--- libc061.dll
12-03-23 4.32 157.124 0 a--- libc062.dll
12-03-23 4.32 157.124 0 a--- libc063.dll

The above is a "forwarder" dll which forwards libc063 requests to
libc065.dll

Post by t***@antispam.ham
12-03-23 4.32 157.176 0 a--- libc064.dll
12-03-23 4.32 1.353.208 0 a--- libc065.dll
But it's the same size as the libc063.dll used by the
Directory of U:\firefox1002
07-06-11 22.53 1.349.060 0 a--- libc063.dll
Is the new libc063.dll used by Firefox just a stub?

Yes.

If I understand things correctly the libc06?.dll files do not get
unloaded when the application using them is closed.

So, if you run an app that uses the old libc063.dll then it will cause
problems when another app requires the later (forwarder) libc063.dll as
the later dll will not load as the earlier libc063.dll is already loaded.

I think your best bet is to install current libc and gcc dll files in
[boot]:\ecs\dll or [boot]:\os2\dll - the path should be in the
config.sys libpath - so they are available for any app that requires them.


Regards

Pete

[Steve Wendt]

Post by Peter Brown
If I understand things correctly the libc06?.dll files do not get
unloaded when the application using them is closed.

I don't believe this...

Post by Peter Brown
I think your best bet is to install current libc and gcc dll files in
[boot]:\ecs\dll or [boot]:\os2\dll - the path should be in the
config.sys libpath - so they are available for any app that requires them.

... but do agree with this.

[Paul Smedley]

Hi Steve,

Post by Steve Wendt

Post by Peter Brown
If I understand things correctly the libc06?.dll files do not get
unloaded when the application using them is closed.

I don't believe this...

I do... but the behaviour is inconsistent. I've had cases where I can't
find any traces of apps being still running that use a specific libc*
but I can't unlock the DLL.

Cheers,

Paul

[Steven Levine]

On Sat, 23 Jun 2012 09:46:27 UTC, Paul Smedley
<***@DESPAMMsmedley.id.au> wrote:

Hi Paul,

Post by Paul Smedley
I do... but the behaviour is inconsistent. I've had cases where I can't
find any traces of apps being still running that use a specific libc*
but I can't unlock the DLL.

Does this include trying psfiles and/or Theseus?

Steven

[t***@antispam.ham]

Post by Steven Levine

Post by Paul Smedley
I do... but the behaviour is inconsistent. I've had cases where I can't
find any traces of apps being still running that use a specific libc*
but I can't unlock the DLL.

Does this include trying psfiles and/or Theseus?

I've been trying psfiles, and as I noted in a posting from a
few minutes ago, I've seen cases where closing an app causes
the DLL to disappear from the psfiles listing, and I've also
seen cases where closing an app does NOT cause the DLL to
disappear from the psfiles listing. I agree with Paul that
the behavior is inconsistent.

But maybe the inconsistency is related to the system becoming
unstable. When I couldn't rename the Firefox directory to
prepare for unzipping the newer Firefox, because the DLL was
still listed by psfiles as being used by Firefox, even though
the app had been closed, my audio had already been acting up.

[Steven Levine]

On Sun, 24 Jun 2012 02:19:31 UTC, ***@antispam.ham wrote:

Hi,

Post by t***@antispam.ham
the DLL to disappear from the psfiles listing, and I've also
seen cases where closing an app does NOT cause the DLL to
disappear from the psfiles listing.

All that means is that the DLL is still in use somewhere or your
systems is hosed in some way.

Post by t***@antispam.ham
But maybe the inconsistency is related to the system becoming
unstable.

If your system is already unstable, common sense says that
inconsistent results are to be expected.

Post by t***@antispam.ham
prepare for unzipping the newer Firefox, because the DLL was
still listed by psfiles as being used by Firefox, even though
the app had been closed, my audio had already been acting up.

That means that you only thought the app had fully closed. If I had
to guess, I'd suspect that firefox was hung in the exit list, but
there might be other reasons. A bit of analysis would tell whether or
not this is a correct guess.

Steven

[Paul Smedley]

Hi Steven,

Post by Steven Levine
On Sat, 23 Jun 2012 09:46:27 UTC, Paul Smedley
Hi Paul,

Post by Paul Smedley
I do... but the behaviour is inconsistent. I've had cases where I can't
find any traces of apps being still running that use a specific libc*
but I can't unlock the DLL.

Does this include trying psfiles and/or Theseus?

Nope - I've never been that concerned - I've usually just ended up
rebooting :P

[t***@antispam.ham]

Post by Peter Brown
If I understand things correctly the libc06?.dll files do not get
unloaded when the application using them is closed.

Just to make sure we're using the term the same way, if PSFILES
does not show the DLL as being used, does that mean it isn't
loaded?

If so, then OS/2 has been inconsistent in its behavior. I've
seen cases where the DLL associated with an application disappears
from the PSFILES list, and I've seen other cases where it does
not. In fact, my most recent reboot was triggered in part by
the failure of my audio, but also because I couldn't rename my
Firefox directory to Firefox1002 (in preparation for unzipping
Firefox 10.0.5, because you don't want to overwrite an existing
Firefox installation), with the libc063.dll being listed by
PSFILES as being in use by Firefox, thus the directory was still
in use.

I just tried PSFILES and it listed libc065.dll as being in use
by Firefox, then I closed Firefox, and now libc065.dll is no
longer being listed as in use by PSFILES. Does that mean it has
been unloaded by the system? That is, I'm not sure that "unused"
is the same thing as "unloaded".

Post by Peter Brown
So, if you run an app that uses the old libc063.dll then it will cause
problems when another app requires the later (forwarder) libc063.dll as
the later dll will not load as the earlier libc063.dll is already loaded.
I think your best bet is to install current libc and gcc dll files in
[boot]:\ecs\dll or [boot]:\os2\dll - the path should be in the
config.sys libpath - so they are available for any app that requires them.

I may give that a try at some point when I can afford to reboot
(or am forced to). But I'm also trying to get a better understanding
of how the system works, which could aid in future problem solvings.

[Peter Brown]

Hi

Post by t***@antispam.ham

Post by Peter Brown
If I understand things correctly the libc06?.dll files do not get
unloaded when the application using them is closed.

Just to make sure we're using the term the same way, if PSFILES
does not show the DLL as being used, does that mean it isn't
loaded?
If so, then OS/2 has been inconsistent in its behavior. I've
seen cases where the DLL associated with an application disappears
from the PSFILES list, and I've seen other cases where it does
not. In fact, my most recent reboot was triggered in part by
the failure of my audio, but also because I couldn't rename my
Firefox directory to Firefox1002 (in preparation for unzipping
Firefox 10.0.5, because you don't want to overwrite an existing
Firefox installation), with the libc063.dll being listed by
PSFILES as being in use by Firefox, thus the directory was still
in use.
I just tried PSFILES and it listed libc065.dll as being in use
by Firefox, then I closed Firefox, and now libc065.dll is no
longer being listed as in use by PSFILES. Does that mean it has
been unloaded by the system? That is, I'm not sure that "unused"
is the same thing as "unloaded".

Sorry, I do not know what psfiles is so cannot comment on whether
psfiles equates "unused" to "unloaded".

I do know that some apps requiring libc063.dll did not want to work with
the libc063.dll "forwarder" dll supplied with libc064.dll.

That problem could be overcome by using the earlier "full" libc063.dll -
but then some other apps, eg smplayer, would not work properly as they
required the "forwarder" libc063.dll.

Trying to use LIBPATHSTRICT did not resolve those problems here.

Post by t***@antispam.ham

Post by Peter Brown
So, if you run an app that uses the old libc063.dll then it will cause
problems when another app requires the later (forwarder) libc063.dll as
the later dll will not load as the earlier libc063.dll is already loaded.
I think your best bet is to install current libc and gcc dll files in
[boot]:\ecs\dll or [boot]:\os2\dll - the path should be in the
config.sys libpath - so they are available for any app that requires them.

I may give that a try at some point when I can afford to reboot
(or am forced to). But I'm also trying to get a better understanding
of how the system works, which could aid in future problem solvings.

Later builds of libc06?.dll and gcc*.dll packages contain "forwarder"
dll files so that apps requiring earlier libc/gcc dll files, eg
libc063.dll, continue working fine - as long as there are no bugs in the
later libc06?.dll or gcc*.dll files.

So, it makes sense to accumulate all those files in 1 directory in the
LIBPATH rather than having lots of different versions scattered all over
the place.



Regards

Pete