DLL and SO differences

DLL and SO differences

Post by DeMars, Joh » Thu, 01 Jul 1999 04:00:00



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.

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.

I have always understood MS DLLs as being more of a formalization of the
old terminate and stay resident (TSR) program.  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. 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).

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)?

 
 
 

DLL and SO differences

Post by Ron Rubl » Thu, 01 Jul 1999 04:00:00



>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
is minimal.

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
Windows equivalent.

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
client-server concept.

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
used.

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
(or administrator).

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.

 
 
 

DLL and SO differences

Post by Lyle Meie » Thu, 01 Jul 1999 04:00:00



>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
>(or administrator).

>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.

Microsoft in Windows 2000 is changing to the Unix Philosophy due to
the amount of DLL hell that exists today. With Windows 2000 an ISV
will not be able to ship system dll's as part of his install package but
rather require that system be brought to a given service pack level.
This is in response to a whole bunch of enterprise demands, caused
when the order in which one install apps causes them to work or not work
as the case may be.
So due to enterprise demand MS is moving here towards the Unix direction.
 
 
 

DLL and SO differences

Post by Erik de Castro Lop » Fri, 02 Jul 1999 04:00:00



> 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.

> 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.

> I have always understood MS DLLs as being more of a formalization of the
> old terminate and stay resident (TSR) program.  A TSR's main purpose was
> to provide some rudimentary client server architecture on a single task
> operating system (MS-DOS).  

Sorry, this is wrong. DLLs in windows are Dynamic Link Libraries. One
of them MSCRTL.DLL provides almost exactly the same functionality as
libc on unix systems.

Quote:> In this light the DLL is more of a "server"
> and IPC mechanism rather than a library. 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 think you are confusing DLLs in windows with OLE (Object Linking
Embedding?? which I know almost nothing about). OLE makes heavy use
of a client/server paradigm.

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 don't think linux's shared libraries lack any functionality that
is offerred under windows. I do however agree with mlw that the current
state of affairs could be improved. From what I've read, the versioning
capabilities of ld covers much of what is required. This should be extended
and made more accessible.

Erik
--
+-------------------------------------------------+

+-------------------------------------------------+
Microsoft is not the answer.
Microsoft is the question. NO is the answer.

 
 
 

DLL and SO differences

Post by Ron Rubl » Fri, 02 Jul 1999 04:00:00




>Microsoft in Windows 2000 is changing to the Unix Philosophy due to
>the amount of DLL hell that exists today. With Windows 2000 an ISV
>will not be able to ship system dll's as part of his install package but
>rather require that system be brought to a given service pack level.

This requires the cooperation of Corporate Tech Support
Departments as well, though. A lot of tech support departments
still jump through hoops to be able to do everything without
a proper install.

I think it will take quite some time before we see any results
from these changes, though I'm very glad to see them.

Immediately after I informed one client that these type
of changes were in the works and showed them copies
of the white papers, they called a meeting to see what
they can do to avoid complying.

 
 
 

DLL and SO differences

Post by Jeff Koftinof » Fri, 02 Jul 1999 04:00:00



> 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.

<snip>

They are so similiar I don't understand what the fuss is about.

You can do plugins with unix shared libraries, no problem.

I did this with C++ in mind 4 years ago on linux. check out
    http://www.jdkoftinoff.com/linux1.html

it describes how i made a c++ based plug-in architecture where you can
specify a shared library at run time and have it dynamically open it and
create objects of the C++ classes defined within.

the same thing with almost the exact same code is possible under windows -
just use LoadLibrary() instead of dlopen() and the corresponding call to get
a dll function address. that's it.

Best Regards
Jeff Koftinoff

 
 
 

DLL and SO differences

Post by Richard Krehbie » Fri, 02 Jul 1999 04:00:00




> > 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.

> They are so similar I don't understand what the fuss is about.

The difference is that in Linux, an application has a single name space for
all symbols provided by all shared libraries.  That is, if an app
dynamically loads a library, say "scanner.so", which provides a symbol
called "capture", and the same app loads a library, say "video.so", which
provides a symbol called "capture", the dynamic loader will get two symbols
confused.  This is a terrible terrible way to do this.  Each import should
explicitly name the .SO that the symbol must come from - and this is how
.DLLs work.

--
Richard Krehbiel, Kastle Systems, Arlington VA USA

 
 
 

DLL and SO differences

Post by Marti » Fri, 02 Jul 1999 04:00:00




>> 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.

..

Quote:

>I don't think linux's shared libraries lack any functionality that
>is offerred under windows. I do however agree with mlw that the current
>state of affairs could be improved. From what I've read, the versioning
>capabilities of ld covers much of what is required. This should be extended
>and made more accessible.

>Erik

Unless things have changed recently, I don't think Unix shared libraries
support dynamic linking at run-time by function name... can be very useful
sometimes!

Martin

 
 
 

DLL and SO differences

Post by Stephan Hoube » Fri, 02 Jul 1999 04:00:00



> Unless things have changed recently, I don't think Unix shared libraries
> support dynamic linking at run-time by function name... can be very useful
> sometimes!

Apparently, things have changed "recently".
Check out the dlopen() manpage.

P.S. In a software project here at the university in which I'm
partially involved, this feature is used extensively.

Greetings,

Stephan

 
 
 

DLL and SO differences

Post by Marcus Sundber » Fri, 02 Jul 1999 04:00:00



> Unless things have changed recently, I don't think Unix shared libraries
> support dynamic linking at run-time by function name... can be very useful
> sometimes!

It didn't change "recently", it's been supported for a long time.

//Marcus
--
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404

 
 
 

DLL and SO differences

Post by Craig Kelle » Fri, 02 Jul 1999 04:00:00



> 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.

> I have always understood MS DLLs as being more of a formalization of the
> old terminate and stay resident (TSR) program.  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. 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).

Not really; you can see implementations which do that of course but a
DLL is really just that, a Dynamically Linked Library.  I don't
believe that Win32 will *share* one DLL amongst several applications
in the same way that UNIX boxen share a single in-memory copy with
several apps (copy on write, of course).

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)?

No, they are the same thing, UNIX apps tend to link in *all* their
libaries when first executed, but you could very easily use uselib(2)
instead and allow a user to choose which one to use.

--
The wheel is turning but the hamster is dead.


 
 
 

DLL and SO differences

Post by Timothy J. L » Fri, 02 Jul 1999 04:00:00


|
|>
|>Microsoft in Windows 2000 is changing to the Unix Philosophy due to
|>the amount of DLL hell that exists today. With Windows 2000 an ISV
|>will not be able to ship system dll's as part of his install package but
|>rather require that system be brought to a given service pack level.
|
|This requires the cooperation of Corporate Tech Support
|Departments as well, though. A lot of tech support departments
|still jump through hoops to be able to do everything without
|a proper install.
|
|Immediately after I informed one client that these type
|of changes were in the works and showed them copies
|of the white papers, they called a meeting to see what
|they can do to avoid complying.

Why would Corporate Tech Support Departments be opposed to a change
that would make their lives easier?  Or are they worried that less
work means less jobs for them?

--
------------------------------------------------------------------------

Unsolicited bulk or commercial email is not welcome.             netcom.com
No warranty of any kind is provided with this message.

 
 
 

DLL and SO differences

Post by Jerr » Fri, 02 Jul 1999 04:00:00




> > 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.

> > I have always understood MS DLLs as being more of a formalization of the
> > old terminate and stay resident (TSR) program.  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. 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).

> Not really; you can see implementations which do that of course but a
> DLL is really just that, a Dynamically Linked Library.  I don't
> believe that Win32 will *share* one DLL amongst several applications
> in the same way that UNIX boxen share a single in-memory copy with
> several apps (copy on write, of course).

> > 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)?

What do you mean DLL functionality ? From the above DLLs appear to be
like UNIX shared libraries with the exception that each application that
uses a DLL has a copy of the DLL in memory. Why would UNIX want this ?
Seems like the only functinality gain in using DLLs is that more memory
gets used. Not exactly an increase in functionality is it ?

You might be better off investigating what mechanisms are needed to
implement UNIX-like shared libraries in Windoze......it should only take
MS several years to get around to it....

- Show quoted text -

> No, they are the same thing, UNIX apps tend to link in *all* their
> libaries when first executed, but you could very easily use uselib(2)
> instead and allow a user to choose which one to use.

> --
> The wheel is turning but the hamster is dead.



 
 
 

DLL and SO differences

Post by Ulrich Weiga » Fri, 02 Jul 1999 04:00:00



>Not really; you can see implementations which do that of course but a
>DLL is really just that, a Dynamically Linked Library.  I don't
>believe that Win32 will *share* one DLL amongst several applications
>in the same way that UNIX boxen share a single in-memory copy with
>several apps (copy on write, of course).

Oh, Windows NT certainly does share DLLs copy-on-write between apps.
In Windows 95, it's a little different, because the OS doesn't
really support copy-on-write, but at least the code sections of the
DLL are shared (read-only) here, as well.  For data sections, there
are two sorts: shared data sections, which are mapped read-write
into all processes using the DLL, and private data sections, where
each process gets its own copy.

The details are somewhat different from the way .so files are handled,
especially related to base relocations:  In Unix, .so files are usually
required to contain only position-independent code (i.e. compiled using
the -fPIC switch), so that the code sections can be mapped at another
base address than the one they were compiled for.  In Windows, the DLL
can contain arbitrary code, and the linker will emit relocation records
pointing to all locations that need to be adapted if the base is changed.
These relocation records are then used by the OS paging code that
automatically reapplies the relocations whenever a page is reloaded
from the DLL disk file.  Both the Unix and the Windows method have
their own advantages and disadvantages, obviously ...

--
  Ulrich Weigand,
  IMMD 1, Universitaet Erlangen-Nuernberg,
  Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688

 
 
 

DLL and SO differences

Post by Jeff Koftinof » Fri, 02 Jul 1999 04:00:00





> > They are so similar I don't understand what the fuss is about.

> The difference is that in Linux, an application has a single name space for
> all symbols provided by all shared libraries.  That is, if an app
> dynamically loads a library, say "scanner.so", which provides a symbol
> called "capture", and the same app loads a library, say "video.so", which
> provides a symbol called "capture", the dynamic loader will get two symbols
> confused.  This is a terrible terrible way to do this.  Each import should
> explicitly name the .SO that the symbol must come from - and this is how
> .DLLs work.

How is it confused? hmmm... interesting... With my little c++ plugin program I
modified it to load two 'plugins' with dl_open() at the same time - both
plugins defining a symbol 'factory0()' and it did not get confused.

In what situation would not work?

Best Regards

Jeff Koftinoff

 
 
 

1. Q: The difference between share library and DLL

Hey there,

       I would like to port my UNIX-based application which using the
share library (the dl*() functions) to PC. It sounds to me like the DLL
will be a good approach. Since I am new on PC environment, is there anyone
know the difference?

Thanks, Herman

2. 387 failed: trying to reset

3. Difference between DLLs and Shared Libraries

4. HP9000 setup

5. Ethereal on cygwin - 'which Packet.dll' and 'which wpcap.dll' ??

6. xanim?

7. Unidrv.dll & Mmsystem.dll

8. ssh and ipchains

9. Matrox Mystique ands X.

10. Binary File Differences: When Do Differences Matter?

11. what major differences between sparc IV & IV+ apart the CPU speed difference?

12. DLL Jump 4.4pl2 and libc.so.4 incomp. v# DLL's ??

13. Q: Plug-In API/DLL?