From:	david DOT belius AT chello DOT se (asdsad)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Program crashes under dos but not under windows
Organization:	asd
Message-ID:	<389088a0.282746@news.chello.se>
X-Newsreader:	Forte Free Agent 1.11/32.235
Lines:	39
Date:	Thu, 27 Jan 2000 17:11:52 GMT
NNTP-Posting-Host:	193.150.219.174
X-Complaints-To:	newsmaster AT chello DOT com
X-Trace:	nntp1.chello.se 948993112 193.150.219.174 (Thu, 27 Jan 2000 18:11:52 MET)
NNTP-Posting-Date:	Thu, 27 Jan 2000 18:11:52 MET
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

When running djgpp or djgpp compiled programs under DOS the programs
crash as soon as they are started. When running under windows it
works, but as soon as a press a key(any key) it crashes and windows
reports a page fault. I saw something in the FAQ(section 9.1) about it
but i dont understand it.It says i should set the bit
_CRT0_FLAG_NULLOK in _crt0_startup_flags. How would i do this? Is
_crt0_startup_flags a #define or a variable or what?

Here is the FAQ section:

9.1 My program crashes only in v2.0!
Q: My v2 program crashes, but only under CWSDPMI; it runs OK under
other DPMI hosts like Windows, OS/2 or QDPMI. Is this a bug in
CWSDPMI? 

A: No, it probably is a bug in your program which just goes unnoticed
on Windows. Unlike other DPMI hosts, CWSDPMI supports some DPMI 1.0
extensions which allow DJGPP to capture and disallow dereference of
pointers which point to addresses less than 1000h (a.k.a. NULL pointer
protection). The tell-tale sign of these problems is a message "Page
fault at ..." that is printed when a program crashes, and an error
code of 4 or 6. The NULL pointer protection feature can be disabled by
setting the _CRT0_FLAG_NULLOK bit in _crt0_startup_flags and
recompiling the program; if this makes SIGSEGV crashes go away, your
program is using such invalid pointers; the stack trace printed when
the program crashes should be a starting point to debug this. See how
to debug SIGSEGV, for more details about debugging these problems. 

To make spotting uninitialized memory simpler, you can set
_crt0_startup_flags to _CRT0_FLAG_FILL_DEADBEEF (don't laugh!); this
will cause the sbrk()'ed memory to be filled with the value 0xdeadbeef
(-559038737 in signed decimal or 3735928559 in unsigned decimal) which
should be easy to spot with a debugger. Any pointer variable which has
this value was used without initializing it first. 

An insufficient stack size can also be a cause of your program's
demise, see setting the stack size, below. 

- Raw text -