home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / os2 / programm / 7457 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  4.1 KB
  1. Path: sparky!uunet!gatech!rutgers!njitgw.njit.edu!hertz.njit.edu!dic5340
  2. From: dic5340@hertz.njit.edu (David Charlap)
  3. Newsgroups: comp.os.os2.programmer
  4. Subject: Re: **SEGMENT VIOLATIONS and DLLs**
  5. Message-ID: <1993Jan9.092321.29100@njitgw.njit.edu>
  6. Date: 9 Jan 93 09:23:21 GMT
  7. References: <1993Jan8.171124.1078@beckman.com>
  8. Sender: news@njit.edu
  9. Organization: New Jersey Institute of Technology, Newark, N.J.
  10. Lines: 87
  11. Nntp-Posting-Host: hertz.njit.edu
  12.  
  13. In article <1993Jan8.171124.1078@beckman.com> rariedel@beckman.com (Bob Riedel) writes:
  14. >I am having difficulty getting an application object library to work
  15. >without generating segment violation errors under OS/2 V1.3 using the
  16. >Microsoft C6 compiler.
  17. >
  18. >The modules which make up the library are being compiled using the
  19. >/MT /AL /Aw /G2 /Gc switches because they are ultimately destined to be
  20. >part of a DLL (they are not currently).
  21.  
  22. Good, I only use Large and Huge models when writing OS/2 code - it
  23. saves a lot of problems later.  I found that /Aw doesn't always work.
  24. Using /Au will force _loadds with every function call - perhaps a bit
  25. overkill, but it eliminates much of these errors.
  26.  
  27. >I am having some difficulty deciding when to use the _loadds attribute
  28. >on the individual functions, and the absence of this attribute on some
  29. >of the components of the library seems to be the primary cause of the
  30. >problem.
  31.  
  32. Use _loadds on any function that will be exported to procedures
  33. outside the DLL.  I believe such functions should all be declared with
  34. the EXPENTRY keyword, which is, in effect _loadds pascal.
  35.  
  36. >All of the problems (so far) appear when one module passes stack variables
  37. >by reference to another module. For some reason the receiving module cannot
  38. >reference the caller's data. It even happens when private modules (those not
  39. >referenced outside the DLL) in a separate thread wake up on a timer and pass
  40. >stack variables by reference to another function (which then blows up). The
  41. >offending private modules have static data.
  42.  
  43. Yes.  Each DLL has it's own stack and global data, I believe.  You
  44. should not pass variables by reference to DLL's, since your data
  45. segment, and possible also stack segment are different.  Be sure that
  46. the compiler always assumes that ss!=ds.
  47.  
  48. >These are my questions:
  49. >
  50. >    1 - When do you use the _loadds attribute, and when do you not
  51. >        have to?
  52.  
  53. Code that has no out-of-the-module references doesn't need it.
  54. Anything that's going to be called from another module should use it.
  55. The easiest way is to declare all exported functions with the EXPENTRY
  56. keyword.
  57.  
  58. >    2 - Can the private parts of the library, that is those functions
  59. >        which cannot be called outside the library, be compiled using
  60. >        a standard model (ie: /MT /AL), while only the exported sections
  61. >        are compiled using /ALw?
  62.  
  63. No.  The entire library should be compiled with the same model.  If
  64. you flag the exported sections appropriately, that will be enough.
  65. Mixing memory models is painful enough.  Don't make things worse by
  66. trying to do this in a DLL.
  67.  
  68. >    3 - If the answer to (2) is no, then does that mean that even some
  69. >         private modules must have the _loadds attribute?
  70.  
  71. It really doesn't hurt.  If you suspect there being a problem, compile
  72. it with the /ALu switches in place.  This way, everything will get a
  73. _loadds.
  74.  
  75. >    4 - Does the main() need any special attributes if it is compiled
  76. >        using /ALw?
  77.  
  78. I don't think so.
  79.  
  80. >    5 - Why can't the Microsoft C "Advanced" Programming Techniques
  81. >        manual answer some of these stupid questions?
  82.  
  83. Because it assumes you already know this.  It also assumes that you'll
  84. have the Microsoft OS/2 toolkit to answer these questions.  The
  85. "advanced" programming techniques deals mostly with DOS code and
  86. leaves Windows and OS/2 stuff to the respective toolkits.  Since IBM's
  87. C/2 compiler is a repackaged MS-C, you might check the IBM 1.3 toolkit
  88. for help.
  89.  
  90. Don't forget that if your DLL calls any C library functions,
  91. whatsoever, you must link it with LLIBCDLL and not LLIBCEP.
  92.  
  93.  
  94.  
  95. -- 
  96.   |)  David Charlap          | .signature confiscated by FBI due to
  97.  /|_  dic5340@hertz.njit.edu | an ongoing investigation into the
  98. ((|,)                        | source of these .signature virusses
  99.  ~|~
  100.