This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: DLL naming conventions


At 02:46 PM 8/31/2000, you wrote:
>On Thu, Aug 31, 2000 at 09:25:34PM +0300, Tor Lillqvist wrote:
> >Paul Sokolovsky writes:
> > > GIMP's stupid shrink-wrapped installer drop its to
> > > windows/system).
> >
> >No it doesn't. (It did at some point, a long time ago.) Currently it
> >puts the DLLs in \Program Files\Common Files\GNU.
> >
> >Currently the GIMP for Windows does not use DLLs for the JPEG, Zlib or
> >TIFF libraries, precisely because of the lack of consensus in naming
> >etc. And if there is anything to learn from this discussion, it is
> >that it is best to stick to static libraries in the future, too...
> >
> >One point that has not been brought up here is that it is not enough
> >that some library's API is stable, like for instance zlib. The ABI
> >must also be identical in order to be able to share the same DLL
> >between applications from different sources. With this I am thinking
> >of struct packing issues, i.e. whether gcc compilations use
> >-fnative-struct (MSVC-compatible bitfield packing) or not.
> >
> >Sorry that this is mostly off-topic to the cygwin list.
>
>I actually think that this is quite on topic for this discussion.
>
>I guess the one thing that reading this mailing list for three
>years has showed me is that any change is expensive.  I never would
>have thought that something like having the installer default to
>putting cygwin stuff in its own directory would have caused
>people's heads to explode but I was obviously naive.
>
>This reaction to change has made me very reluctant to consider
>user visible changes to cygwin since I can easily imagine the
>onslaught of "newbies" looking for libz.dll.
>
>Maybe you're right and we are starting to rely too much on DLLs for
>things that are clearly established and relatively static (no pun
>intended) like zlib.  The benefit to shared libraries is that
>you're sharing a common code base among many applications, making
>upgrading due to bugs easier.  Also, if multiple programs are
>using shared libraries then there should be a reduction in load
>times.
>
>I'm not sure that these benefits outweigh the difficulties that
>are being raised.
>
>cgf



Quite true.  Microsoft (a bad word I know!;-)) calls this all "DLL Hell"
and has plans to address it with their ".NET" initiative (interesting that
at their web site you find information about this under "Products"!;-))
Anyway, they plan to address the issue by grouping all dependencies (DLLs
in this case) together so that an application runs the DLLs it was shipped
with and not any others that exist on the system.  This gets us back very
close to the idea of static libs, which I find an interesting turn of 
events.  In any case, I'm not advocating that people need to follow what
Microsoft does but it does point out that this is an issue, others have 
thought about it, and at least one group has decided to mostly punt on the
idea of DLLs!

Those interested can look at:

http://msdn.microsoft.com/msdnmag/nettop.asp?page=/msdnmag/issues/0900/Framework/Framework.asp&ad=ads.ddj.com/msdnmag/premium.htm

http://msdn.microsoft.com/msdnmag/nettop.asp?page=/msdnmag/issues/1000/Framework2/Framework2.asp&ad=ads.ddj.com/msdnmag/premium.htm

but let's not let this discussion degrade into an analysis of whether 
Microsoft is doing the right thing or not!;-)




Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]