🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.os2.programmer
Article #1935

Re: DLLs and LIBPATH (Was: Re: Minor wishlist item: any IBMers out there?)

#1935
From: David Bolen
Date: Wed, 07 Oct 1992 15:28
46 lines
3078 bytes
In article <1992Oct7.143622.1387@news.eng.convex.com> Andrew Bros <bros@convex.COM> writes:

>  If anyone's still reading at this point, I'd like to know if there's
>any way of determining a revision level of a dll.  Or is it dependent
>on the programmer to provide this functionality?  I can see this as
>becoming a problem as more code becomes shared, and dependencies
>arise.

This is where (IMHO) OS/2 DLLs have a definitely failing.  I've posted
before about the fact that I think that having version identification
for DLLs supplied as part of the base OS is very important.  As you
say, it's just going to become more of a problem as they become more
prevalent.

For the moment, it's pretty much up to the particular DLL writer.  My
suggestion when writing a DLL would be to make sure you come up with
the version checking procedure right from the beginning, so that
issuing the version check call is always safe, no matter what version
of your DLL an application gets linked to.

For some of my work, I've had a version call that an application
supplied with the version (MajorVersion.MinorVersion.BuildLevel) of
the library it was linked with, and that was then returned the same
information for the DLL, as well as whether or not the DLL supported
that application level.  The application knew it's own level through
some data that was automatically linked statically into the
application through the same library that provided the DLL links.  It
was then up to the DLL to decide if it could handle that application,
and perhaps to keep track of what version the application expected so
that it could adapt appropriately.

Note that this doesn't solve the problem when a DLL has functions
removed from it's interface, as OS/2 will not even allow the
application to start due to unresolved references.  So if you want to
make sure and support backlevel applications, you have to at a minimum
have stub functions for all previous revisions of your DLL to get by
the load-time checking.

--
-- David
--
/-----------------------------------------------------------------------\
 \              David Bolen             \  Internet: db3l@ans.net      /
  |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
 / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
\-----------------------------------------------------------------------/
Technical Details
Message-ID: <1992Oct07.192423.2842@ans.net>
Path: arc1-ca.pugleaf.net!sparky!uunet!noc.near.net!hri.com!ukma!darwin.sura.net!europa.asd.contel.com!news.ans.net!ans.net!db3l
References: <1992Oct5.135715.854@debet.nhh.no> <1992Oct6.214026.3576@networx.com> <1992Oct7.143622.1387@news.eng.convex.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!noc.near.net!hri.com!ukma!darwin.sura.net!europa.asd.contel.com!news.ans.net!ans.net!db3l
From: db3l@ans.net (David Bolen)
Newsgroups: comp.os.os2.programmer
Subject: Re: DLLs and LIBPATH (Was: Re: Minor wishlist item: any IBMers out there?)
Message-ID: <1992Oct07.192423.2842@ans.net>
Date: 7 Oct 92 15:28:08 GMT
References: <1992Oct5.135715.854@debet.nhh.no> <1992Oct6.214026.3576@networx.com>
 <1992Oct7.143622.1387@news.eng.convex.com>
Sender: news@ans.net (News Administrator)
Organization: Advanced Network & Services, Inc. - Elmsford, NY
Lines: 46
In-Reply-To: Andrew Bros's message of Wed, 7 Oct 1992 14: 36:22 GMT