🚀 go-pugleaf

Greetings all,

I have a problem: I'm using C/C++ version 7.00 on a Compaq 486/50MHz
thingy. Well ... I'm trying to use it, because most of the time some
values (defined in the crt0.asm startup code) get screwed up.
Here's the snippet from the crt0.asm file:

--------------------------------------------------------------------------
; OK, we now have DS = ES = DGROUP for all models, and SS = DGROUP
; except for the far stack model.

;	Must run this initializer prior to any far heap allocations being
;	done.  This means that we have hack-ed this in here.  There should
;	be a better solution for C7

	mov	cx,__qczrinit		;* Get initializer addr
	jcxz	@F			;* Is it zero?
	call	cx			;* No -- call indirect through
@@:

;	process command line and environment

	call	_setenvp	; crack environment
	call	_setargv	; crack command line

	; etc. etc. all preparations needed to call _main properly.
--------------------------------------------------------------------------

It's the value at location __qczrinit. It contains a trash value
(always non-zero), so the indirect call to cx causes my program
to jump straight into la-la-land.

I'm currently developing a small application: about 96Kb, large model,
and when I leave out a few small functions, the size of the resulting
executable gets smaller of course and this bug disappears! It can't
be a bug in my code, because _main hasn't even been called yet. 

A few months back I experienced the same thing in the crt0dat.asm
part of the startup code, where a similar trick is used to check
whether or not the floating point emulator is loaded. Microsoft uses
a linking trick: in the (14 bytes) cdata segment, the first element
of that segment (FYI: fpmath) _should_ contain the address of the
emulator init code. Well ... when the executable file crosses the
(arbitrary) 64K bytes boundary, this word contains nonsense too.

That problem could be worked around, by _always_ including some
expressions (statements) involving some floating point operations,
otherwise, the floating point emulator was not linked in, but
this first address in fpmath did _not_ contain all zero values.
Note: I'm not talking about the `floating point not loaded' error
here: I'm not using any floating point stuff at all! And I'm
sure about that: the emulator is _not_ linked in, but the
corresponding startup address is _not_ zero.

And now, I get the same silly behavior with this __qczrinit address.
It seems that whenever the size of the executable crosses a 64K
byte boundary, something goes wrong ...

Did anyone else experience this bug? What's worrying me is the 
comment in the code snippet above: `we have hack-ed this in here.
There should be ...' What does this mean? I've contacted Microsoft
Product Support Service here in Holland, but I still didn't get an
answer or a solution to this problem.

Any tips, hints, moral support ;-) are higly appreciated. If you want
to mail me, I'll summarize on the net if there's enough interest. 
Followups on the net are ok too, I will read this group on a daily
basis.

kind regards and thanks in advance,

Jos aka jos@and.nl