Article View: comp.os.os2.programmer
Article #1935Re: DLLs and LIBPATH (Was: Re: Minor wishlist item: any IBMers out there?)
From: David Bolen
Date: Wed, 07 Oct 1992 15:28
Date: Wed, 07 Oct 1992 15:28
46 lines
3078 bytes
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!db3lReferences:
<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