From: bros@convex.COM (Andrew Bros)
Newsgroups: comp.os.os2.programmer
Subject: DLLs and LIBPATH (Was: Re: Minor wishlist item: any IBMers out there?)
Date: 7 Oct 92 14:36:22 GMT
Reply-To: bros@convex.COM (Andrew Bros)
Organization: Convex Computer Corporation, Richardson, TX
Originator: bros@neptune.convex.com
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In article <1992Oct6.214026.3576@networx.com> mikel@networx.com (Mike Lempriere) writes:
>Sorry, gotta flame on this one...
>
>The DLL itself is not inherently evil, however, the implementation is.
>It is absurd to have a program split in pieces in DIFFERENT PLACES!
>If I were to make a program and use a DLL, I would expect ALL the code
>to be in one place.  .DLL and .EXE in the relese directory tree.
>An install process should not have to go messing around in the SYSTEM
>(/OS2/DLL) directory.  A simple recursive copy should suffice.  Most
>importantly, if that software package were to be deleted, only it's
>directory need be deleted -- no turds are left behind in the SYSTEM's
>directory tree.

  It's really a matter of user education.  The LIBPATH can be set to
look in a second directory for user program shared libraries.  Also
adding . to LIBPATH will search the current directory.  This way, if I
set up a program object for an executable that uses shared libaries, I
can set the working directory to the directory that contains both, and
there's no problem.

  I can see real advantages to having symbolic links in the
filesystem, as in *nix.  It would be much cleaner to create links in a
single directory to the shared libraries that reside along with the
executable and other miscellaneous files.

>Worst yet, the greatest insult of them all, is that the poor clod has
>to reboot.  Real computers, with real OS's reboot when the power comes
>back on, and that's it.  I thought a 486 with OS/2 wass real.  Wrong.

  This isn't necessary if your system is set up properly.  For
example, change libpath in config.sys to:

LIBPATH=/os2/dll:/usr/lib:.

  Then, when a new program requires a shared library, move the dll
into /usr/lib.  You don't have to reboot.  Or just run the program
from a CLI window, with the executable and dll in the current
directory.

  I don't disagree that the documentation doesn't do a very good job
of instructing the user on how to set up a system.  I think it was the
same when users are confronted with directory hierarchies for the
first time.  How many people do you know that put everything in the
root directory?  They need someone to show them how to set up and use
the system.  Those people with experience in *nix have a real
advantage, since it requires a good understanding of the configuration
issues.

  I also believe that putting applications' shared libraries in
/os2/dll is asking for trouble.  Eventually, you're going to need to
reinstall OS/2, and you'll wipe out a library necessary to run an
application.

  If anyone's still reading at this point, I'd like to know if there's
any way of determining a revision level of a dll.  Or is it dependent
on the programmer to provide this functionality?  I can see this as
becoming a problem as more code becomes shared, and dependencies
arise.
-- 
Andrew Bros                             bros@convex.com
System Integration Group                Convex Computer Corporation
It does not do to leave a live dragon out of your calculations,
if you live near him.  - JRR Tolkien, The Hobbit.