JC> A quick workaround to the problem you point out is to run DLLRNAME
 JC> from C Set++ on the DLL and all referencing DLLs and EXEs.  Or, the
 JC> developer could serially name shipped DLLs as their contents would
 JC> break older versions.

Maybe IBM should consider shipping such a utility with OS/2.  How else are
users going to work around such problems without development tools?  I
doubt that many developers are going to be super-helpful with problems like
this as it isn't a bug, it is an unfortunate
coincidence.

 JC> But perhaps the new 8.3 restriction is present precisely because IBM
 JC> has added just the feature you're asking for.  WARP II has a dynamic
 JC> LIBPATH per session.  By issuing SET BEGINLIBPATH=xxx (and hopefully
 JC> anything that sets the environment variable BEGINLIBATH), you can
 JC> prepend a path to the LIBPATH= statement specified in CONFIG.SYS.  For
 JC> that session, these new path(s) will be searched before the default
 JC> LIBPATH.  An ENDLIBPATH also exists to append paths to the default
 JC> LIBPATH.

That's really useful.  Most DLL's do not need to be globally accessible via
LIBPATH.  Most of the time, sticking a "." at the front of
LIBPATH is good enough, but I can see how this wouldn't be enough for
application suites that may be sharing DLL's but should have different
components stored in separate directories.

 JC> I'm unclear on what happens when a load module is already in memory
 JC> with the same module name as one that now appears earlier in the
 JC> dynamic LIBPATH, when a new DosLoadModule is issued.  Perhaps
 JC> everything is now based on fully qualified paths when the kernel
 JC> searches for already loaded DLLs?  There are probably other issues I
 JC> haven't thought of, that hopefully IBM *did* think of. :-)

I'm certainly not going to assume that IBM actually thought of such things.
 They finally got around to "fixing" the named pipe blocking
issue I reported as a bug in October 1993.  Their "fix" is an
improvement, but it still doesn't address the root problem of why doesn't a
thread blocked on DosConnectNPipe() unblock and return with an error when
another thread issues DosClose() on the named pipe? The work-around is that
if you want to shut down a named pipe server in an orderly fashion, it is
necessary to issues DosOpen() calls inside the server to
"connect" all the named pipes long enough to get the
DosConnectNPipe() calls to unblock.  What IBM did fix is that there is no
longer a race condition in the kernel that frequently resulted in the
thread never unblocking even with this workaround.

 JC> Also puzzling in WARP II is that a SET BEGINLIBPATH=xxx statement
 JC> doesn't appear to define a (visible) environment variable.  Unless SET
 JC> BEGINLIBPATH=xxx is interpreted by CMD.EXE as different from other SET
 JC> statements, and a new API is being called, this is inconsistent and
 JC> should be done differently.

I don't mind if it isn't an environment variable as long as they provide
new commands and API calls to manipulate the DLL search paths. My personal
opinion is that IBM would do a lot of good for the entire OS/2 community if
they would overall the entire software
installation/deinstallation mechanism in OS/2 to provide a
standardized and comprehensive method to install and deinstall OS/2
software without having to muck around changing CONFIG.SYS and STARTUP.CMD
and without leaving garbages around in INI files after deinstallation.


--- Maximus/2 2.01wb