>I have found the threads "Shared Libraries and why they are broken",
>"DLL hell" etc. interesting, but I have not participated (till now) out
>of ignorance of MS DLL.
>Perhaps we can get the discussion more on track by discussing the
>differences between MS DLL and UNIX shared libraries. All of the
>discussion so far seems to suppose that the two are very similar. It
>has been my understanding (and this may just be out of ignorance of MS
>DLL) that they are very different.
Not really. If you are curious, check the Windows PE file
format. Even some of the terminology is the same.
There are differences, of course. But many of the same ideas
were used in creating both.
Quote:>UNIX shared libraries are literally that, a shared library that is
>resolved at run-time. It has two clear goals - to save memory
>resources, and to eliminate relinking when the implementation changes
>but the interface does not change.
The Windows DLL specification has these same goals.
MS had some additional ideas in mind, though.
DLLs are also intended to allow partitioning code so that
components, organized in DLLs, can be included when
installing or not, at the discretion of the user. This, I think,
was never part of the Unix thinking on shared libraries.
Additionally, the DLL specification is designed to allow
an application to 'degrade gracefully'. In practice, this
means developers can write a single EXE, that links to the
appropriate, available services at run time.
This allows a single program to use new user interface
features of, for example, Windows 95, while still running
on Windows NT 3.51, where these features are not
present. In practice, this is time-consuming and only
done in cases where the time and money is justified,
or the app is simple enough that the additional code
I think these additional points show a philosophical
difference between Windows and Unix. In Windows,
DLLs are considered application components
first and OS components secondarily.
In Unix, I think the general thinking is that Shared
Libraries are a feature of the system, but are used
by applications as well.
Quote:>I have always understood MS DLLs as being more of a formalization of the
>old terminate and stay resident (TSR) program.
Not really. DLLs in Win32 are exactly the same as EXE files,
with the addition of some specific code that windows calls when
- attaching the DLL to the process
- detaching the DLL from the process
- attaching or detaching a DLL from a new thread.
Quote:>A TSR's main purpose was
>to provide some rudimentary client server architecture on a single task
>operating system (MS-DOS). In this light the DLL is more of a "server"
>and IPC mechanism rather than a library.
Interesting way of looking at it. MS, in their docs, seemed to view
TSRs as a way to override the behavior of application code or OS
code. The MS docs refer to Window subclassing or hooks as the
The DLL linkage mechanism *is* designed to do a minimal
'querying of interface' which in some ways resembles a
light IPC mechanism. But it's minimal. Function names
can be looked up, but the types and numbers of parameters
and the return types of the functions can't
This is extended in COM, which actually does encapsulate
a form of client server architecture on a single PC.
Quote:>In fact it seems to be the
>preferred method of doing MS servers when the client and server are on
>the same host (which accounts for most apps for MS).
I'd say that is more do to the preferences and prejudices of the
DOS-trained developer community in Windows, although in the
case of COM, you're right. It's a desktop-usable version of the
Quote:>So maybe the topic we should discuss is: What mechanism can be used in
>UNIX to give DLL type functionality (or is DLL functionality totally out
>of the UNIX philosophy)?
I think the Unix community doesn't really want a more
'Microsoft-y' shared library usage. I think the Unix
community probably wants to move the other way,
reducing modifications to shared libraries and
controlling them more fully.
I think the shared libraries mechanism is sufficiently similar
to the DLL mechanism as to be interchangeable, at the
functional level. The real difference is how they are being
One thing pointed out by some respondents is that shared
libraries and DLLs can both suffer from functionally
identical 'DLL hell'
I think the main difference is that Unix shared libraries are
expected to be updated by the administrator, as a deliberate
action (although this is not necessarily the case), while Windows
DLLs are expected to be handled by the designer of the
application, without the knowledge or involvement of the user
The installation and update process is inherently less secure
and safe in Windows, although MS is adding additional security
options to prevent careless DLL updating in Windows 2000.
The question is, how many people will turn that optional security
on, and how many will disable it as a nuisance.