home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / msdos / programm / 9225 < prev    next >
Encoding:
Internet Message Format  |  1992-09-10  |  3.3 KB
  1. Path: sparky!uunet!mcsun!sun4nl!and!jos
  2. From: jos@and.nl (Jos Horsmeier)
  3. Newsgroups: comp.os.msdos.programmer
  4. Subject: C/C++ 7.00 problems
  5. Keywords: startup failure
  6. Message-ID: <3406@baby.and.nl>
  7. Date: 9 Sep 92 13:50:19 GMT
  8. Organization: AND Software BV Rotterdam
  9. Lines: 72
  10.  
  11. Greetings all,
  12.  
  13. I have a problem: I'm using C/C++ version 7.00 on a Compaq 486/50MHz
  14. thingy. Well ... I'm trying to use it, because most of the time some
  15. values (defined in the crt0.asm startup code) get screwed up.
  16. Here's the snippet from the crt0.asm file:
  17.  
  18. --------------------------------------------------------------------------
  19. ; OK, we now have DS = ES = DGROUP for all models, and SS = DGROUP
  20. ; except for the far stack model.
  21.  
  22. ;    Must run this initializer prior to any far heap allocations being
  23. ;    done.  This means that we have hack-ed this in here.  There should
  24. ;    be a better solution for C7
  25.  
  26.     mov    cx,__qczrinit        ;* Get initializer addr
  27.     jcxz    @F            ;* Is it zero?
  28.     call    cx            ;* No -- call indirect through
  29. @@:
  30.  
  31. ;    process command line and environment
  32.  
  33.     call    _setenvp    ; crack environment
  34.     call    _setargv    ; crack command line
  35.  
  36.     ; etc. etc. all preparations needed to call _main properly.
  37. --------------------------------------------------------------------------
  38.  
  39. It's the value at location __qczrinit. It contains a trash value
  40. (always non-zero), so the indirect call to cx causes my program
  41. to jump straight into la-la-land.
  42.  
  43. I'm currently developing a small application: about 96Kb, large model,
  44. and when I leave out a few small functions, the size of the resulting
  45. executable gets smaller of course and this bug disappears! It can't
  46. be a bug in my code, because _main hasn't even been called yet. 
  47.  
  48. A few months back I experienced the same thing in the crt0dat.asm
  49. part of the startup code, where a similar trick is used to check
  50. whether or not the floating point emulator is loaded. Microsoft uses
  51. a linking trick: in the (14 bytes) cdata segment, the first element
  52. of that segment (FYI: fpmath) _should_ contain the address of the
  53. emulator init code. Well ... when the executable file crosses the
  54. (arbitrary) 64K bytes boundary, this word contains nonsense too.
  55.  
  56. That problem could be worked around, by _always_ including some
  57. expressions (statements) involving some floating point operations,
  58. otherwise, the floating point emulator was not linked in, but
  59. this first address in fpmath did _not_ contain all zero values.
  60. Note: I'm not talking about the `floating point not loaded' error
  61. here: I'm not using any floating point stuff at all! And I'm
  62. sure about that: the emulator is _not_ linked in, but the
  63. corresponding startup address is _not_ zero.
  64.  
  65. And now, I get the same silly behavior with this __qczrinit address.
  66. It seems that whenever the size of the executable crosses a 64K
  67. byte boundary, something goes wrong ...
  68.  
  69. Did anyone else experience this bug? What's worrying me is the 
  70. comment in the code snippet above: `we have hack-ed this in here.
  71. There should be ...' What does this mean? I've contacted Microsoft
  72. Product Support Service here in Holland, but I still didn't get an
  73. answer or a solution to this problem.
  74.  
  75. Any tips, hints, moral support ;-) are higly appreciated. If you want
  76. to mail me, I'll summarize on the net if there's enough interest. 
  77. Followups on the net are ok too, I will read this group on a daily
  78. basis.
  79.  
  80. kind regards and thanks in advance,
  81.  
  82. Jos aka jos@and.nl
  83.