[EMAIL PROTECTED] wrote:
> In a message dated 4/28/00 4:13:25 PM Central Daylight Time, [EMAIL PROTECTED]
> writes:
>
> > > Not that I know. I know OS/2 uses a DLLPATH but Win32 just reuses the
> > > regular PATH for locating DLLs as well.
> >
> > Well, that's not too bad. You lose a little flexibility, but nothing
> > that can't be dealt with.
>
> Unless some application dumps an older (or newer) version into the path in
> front
> of the one you have tested and relied on. "Sagas from DLL h*ll" is a
> recurring article in most of the developer's magazines - unfortunately, it
> qualifies as NON-fiction.
According to article Q164501 in the Microsoft Knowledge Base, there
is a registry key in NT 4.0 and Windows 2000 called KnownDLLs. It's
at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\KnownDLLs
There are named values under this key. The name is a DLL name (without
path or extension) and the value is the DLL name with the extensions.
This alters the search order listed below to be steps 3,1,2,4,5.
If a DLL is not listed under this key, the following search order is
used:
1. The directory of the executable that's loading the DLL
2. The current directory of the process loading the DLL
3. \Winnt\System32
4. \Winnt
5. A directory in the Path environment variable.
DLL hell is well-documented and real, but is mainly caused by
ignorance or laziness on the part of those writing the installation
procedures (most definitely including Microsoft). Unfortunately, tools
like InstallShield seem to default to the worst possible choices and
make it difficult to set up a more correct installation.
If installations would place DLLs together with the executables rather
than in System32, DLL hell wouldn't happen - each program would get its
own, proper DLLs.
You may think this defeats one of the purposes of DLLs, which is
to share the code in memory. That is, if a DLL is already in use
by a process, another process should be able to map the same
virtual memory pages into its address space, thus conserving
virtual memory. However, this almost never really works, since
(32 bit) DLLs almost always have to be relocated from their default
offsets in the address space, thus requiring a different set
of virtual memory pages anyway.
Granted, if a DLL really is part of the operating system and ought
to be shared, it should go into System32. But then, should parts
of the operating system really be distributed with each application
you install? This is a weird custom that only occurs with Windows -
in other operating systems, no-one would dream of replacing parts
of the OS when you install their apps.
Ken Bandes
---
You are currently subscribed to perl-win32-users as: [archive@jab.org]
To unsubscribe, forward this message to
[EMAIL PROTECTED]
For non-automated Mailing List support, send email to
[EMAIL PROTECTED]
