home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / os2 / programm / 4735 < prev    next >
Encoding:
Text File  |  1992-09-04  |  3.4 KB  |  71 lines
  1. Newsgroups: comp.os.os2.programmer
  2. Path: sparky!uunet!newsgate.watson.ibm.com!news.ans.net!ans.net!db3l
  3. From: db3l@ans.net (David Bolen)
  4. Subject: Re: Tracking down DLL incompatibilities
  5. Sender: news@ans.net (News Administrator)
  6. Message-ID: <1992Sep04.144704.65814@ans.net>
  7. In-Reply-To: pstevens@Metaphor.COM's message of 3 Sep 92 20: 17:47 GMT
  8. Date: Fri, 4 Sep 1992 10:48:34 GMT
  9. References: <2494@cronos.metaphor.com>
  10. Organization: Advanced Network & Services, Inc. - Elmsford, NY
  11. Lines: 58
  12.  
  13. In article <2494@cronos.metaphor.com> pstevens@Metaphor.COM (Paul Stevens) writes:
  14.  
  15. >We are developing a set of applications that make use of several different
  16. >DLL's to share common code.  We frequently encounter problems when one of
  17. >the applications or even a DLL itself has not been linked with the most 
  18. >current version of one of these DLL's.
  19. > (...)
  20. >Can someone explain exactly what fails during image activation that causes
  21. >this "silent" failure?
  22.  
  23. I'm not quite sure why it's silent - normally when I've got a DLL that is
  24. mismatched with an application, I'll get some sort of loader error (like
  25. a particular export doesn't match), or just a trap.  Do you have AUTOFAIL
  26. turned on in CONFIG.SYS?
  27.  
  28. I suppose a possibility is that something in the DLL startup code is
  29. causing a "normal" exit call rather than actually dying, but I'm not sure.
  30.  
  31. >Is there not some way that a developer can get more information about
  32. >what the incompatibility is?  Problems of these sort continually cost
  33. >developers significant amounts of time.  It's just one more of the things
  34. >that makes almost all the developers here loathe OS/2 as a development
  35. >environment.  
  36.  
  37. Well, IMHO I think that if you are writing a system that depends on DLLs then
  38. you had better come up with a mechanism whereby your main application can
  39. identify it's own version and query that of the DLLs.  I personally think that
  40. is a big issue, as DLLs aren't static, and future releases may not be directly
  41. plug compatible with the past releases.  It would be nice if OS/2 helped out
  42. in this area, but right now, an application is pretty much on its own.
  43.  
  44. It can be as simple as an initial version call that supplies the application
  45. version and let's the DLL determine if it supports that application version,
  46. returning an error if not along with the DLLs version.
  47.  
  48. I did this for a user interface toolkit I wrote as a DLL and it worked out
  49. pretty well.  The only thing you can't catch is if the DLL doesn't have an
  50. actual linkage point the application needs - but OS/2 generates a trap
  51. specifying the DLL and function at that point so...
  52.  
  53. The other advantage to this is that your DLL can contain a bit of smarts
  54. for new versions, and can use the version information the application supplied
  55. it in order to emulate a previous version of the DLL for older applications. 
  56.  
  57. I think of this point every time I see reference to the EMX.DLL file (or
  58. people commenting to be sure and use this date of the file, or the latest
  59. version, or whatever). I wonder if that contains any version checking, and if
  60. not, then what will happen when or if it finally gets updated in an
  61. incompatible way?
  62.  
  63. --
  64. -- David
  65. --
  66. /-----------------------------------------------------------------------\
  67.  \              David Bolen             \  Internet: db3l@ans.net      /
  68.   |   Advanced Network & Services, Inc.   \   Phone: (914) 789-5327   |
  69.  / 100 Clearbrook Road, Elmsford, NY 10523  \   Fax: (914) 789-5310    \
  70. \-----------------------------------------------------------------------/
  71.