Phil Taylor wrote:
>As far as I can see, the Windows API allows DLLs to be placed
anywhere
>you like, as long as the calling program knows where to find them.
>Would it not be possible to put any DLLs you install in the same
>directory as the program, rather than in the Windows folder?
This is actually recommended for program specific (non-shared) DLLs.
However, shared DLLs should be placed in the system directory. In the case
of self-registering DLLs (which includes all active x controls) placing them
in the application directory won't help because they still have to be
registered. Only one implementation of a class can be registered at a time
so registering the new copy of the DLL forces all programs that use it to
use the one in your application directory.
SHARED, self-registering DLLs should NEVER be placed in your
application directory because doing so almost ensures that your installation
will corrupt another program. Here's what happens. You create a perfectly
good setup but to avoid stepping on other programs you put all the DLLs in
your application directory. Naturally, you have to register the active-x
controls and other self-registering DLLs. A few months later Microsoft
updates one of the controls you are delivering and companies begin shipping
products with the new control. Interfaces to such DLLs are backwards
compatible. So, your software will run with the new DLL just fine but newer
software that relies on the latest version of the DLL will NOT run with the
older version that you are delivering. Now, someone installs your program.
Since you told the setup utility to place the shared DLLs in your
application directory, it has no way to detect that newer versions of those
files are already installed in the system directory. It blithely copies
your (old version) DLLs to the application directory and THEN REGISTERS
THEM. As soon as it registers them, ALL applications are forced to use the
old versions that you installed! Bad scene, and it happens. I've seen
several instances of software delivered by major vendors that did exactly
that.
A few years ago, the utilities delivered with some ZIP drives were a
killer example. They copied a shared dll to their own directory and
registered it. EACH TIME THE MACHINE REBOOTED their driver re-registered
the version of the control in their directory! I don't remember the DLL
involved, but it was a fairly obscure problem that drove us absolutely nuts.
A client would install our software and it would work fine. The next time
they turned the machine on our software would crap out with an error message
on a particular DLL. Reinstall our software, or reregister that DLL, and
everything would be fine until the machine was turned off again. It took us
weeks to finally realize that the problem was only occuring on machines with
certain zip drives and the full set of zip drive utilities. Sure enough, we
found a copy of the shared DLL in the zip utilities directory. As soon as
we deleted that bogus copy of the DLL, everything was fine.
If you use an install utility like Installshield properly, those
shared DLLs will be written to the system directory. The setup utility will
arbitrate and only overwrite files with newer versions. Thus
(theoretically) no one's software gets broken because all changes to an
object class are required to be backward compatible. That is, you can add
new interface elements but you cannot delete or change existing interface
elements when implementing a newer version.
The bottom line is that it is far more likely that you will CAUSE
problems by installing shared DLLs any place other than the system
directory. This is a VERY common "failure mode" of software delivered by
amateurs (and even by pros, as shown by the zip example above). The second
most common failure mode is configuring the setup improperly such that newer
shared files may be overwritten by older versions. The third most common
installation problem is failing to register self-registering dlls correctly
-- especially not getting the dependencies right -- the good news about this
mode is that it generally only affects the software being installed and NOT
previously installed software. The LEAST common failure mode (probably far
less than 1% of all failures) is where a party violates the rules and
changes the interface of an object class without maintaining backward
compatibility.
So, again, you are FAR more likely to CAUSE problems by placing
SHARED DLLs anyplace other than the system directory. Also, you should use
a good setup utility like Installshield because it will arbitrate file
versions and register files in the correct order. Finally, learn enough to
use the setup utility properly, don't rely on wizards! Installshield is a
pretty good product, but even so there are many "time bomb" programs out
there created when people used the IS 5.5 VB wizard to create an install.
When those programs are uninstalled they'll also delete required windoze
system files because the VB wizard incorrectly placed some shared system
DLLs in a group that was not flagged as shared. Because the files were "not
shared" the uninstall script will delete them unconditionally instead of
checking to see if they are used by other applications and so on.
Windoze has become so complex that it's fair to say that developing
a good installation is often more complex than developing a good
application. That's especially true for VB where the application
programming environment is incredibly simple and the installation
requirements are the most complex. In VC++ you can create very complex
applications and, if you link statically to the run time library, the
application can be delivered as a single file. In VB even the simplest
"hello world" program is going to require the delivery of at least one
shared, self-registered DLL, and a typical VB program will require the
delivery of almost a dozen DLLs of different flavors!
John Atchley
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
