🚀 go-pugleaf

In article <2494@cronos.metaphor.com> pstevens@Metaphor.COM (Paul Stevens) writes:

>We are developing a set of applications that make use of several different
>DLL's to share common code.  We frequently encounter problems when one of
>the applications or even a DLL itself has not been linked with the most 
>current version of one of these DLL's.
> (...)
>Can someone explain exactly what fails during image activation that causes
>this "silent" failure?

I'm not quite sure why it's silent - normally when I've got a DLL that is
mismatched with an application, I'll get some sort of loader error (like
a particular export doesn't match), or just a trap.  Do you have AUTOFAIL
turned on in CONFIG.SYS?

I suppose a possibility is that something in the DLL startup code is
causing a "normal" exit call rather than actually dying, but I'm not sure.

>Is there not some way that a developer can get more information about
>what the incompatibility is?  Problems of these sort continually cost
>developers significant amounts of time.  It's just one more of the things
>that makes almost all the developers here loathe OS/2 as a development
>environment.  

Well, IMHO I think that if you are writing a system that depends on DLLs then
you had better come up with a mechanism whereby your main application can
identify it's own version and query that of the DLLs.  I personally think that
is a big issue, as DLLs aren't static, and future releases may not be directly
plug compatible with the past releases.  It would be nice if OS/2 helped out
in this area, but right now, an application is pretty much on its own.

It can be as simple as an initial version call that supplies the application
version and let's the DLL determine if it supports that application version,
returning an error if not along with the DLLs version.

I did this for a user interface toolkit I wrote as a DLL and it worked out
pretty well.  The only thing you can't catch is if the DLL doesn't have an
actual linkage point the application needs - but OS/2 generates a trap
specifying the DLL and function at that point so...

The other advantage to this is that your DLL can contain a bit of smarts
for new versions, and can use the version information the application supplied
it in order to emulate a previous version of the DLL for older applications. 

I think of this point every time I see reference to the EMX.DLL file (or
people commenting to be sure and use this date of the file, or the latest
version, or whatever). I wonder if that contains any version checking, and if
not, then what will happen when or if it finally gets updated in an
incompatible way?

--
-- 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    \
\-----------------------------------------------------------------------/