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.