Mail Archives: djgpp/1999/09/15/16:04:19
Dear list members,
On November 1997 we found that system() calls under NT 4
caused program crashes or erratic behaviours on DJGPP
compilations if, after the system() call, malloc() or accesses
to stdout or files were made. The problem was not present
on Windows95 or 3.1x, nor compiling using Borland 5.x compilers
and running on NT 4.0 (+Service Pack 4).
The DJGPP list (and Eli in particular) helped us suggesting:
int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;
And it worked! Up to now the problem seemed solved.
Nevertheless, another problem appeared (we do not know how
time ago), again only in DJGPP compilations running under NT 4,
and in this case caused by the _crt0_startup_flags
assignement (the problem disappears if the assignement to
_CRT0_FLAG_UNIX_SBRK is not done).
Here the description of the problem (providing you state
int _crt0_startup_flags=_CRT0_FLAG_UNIX_SBRK outside any
function body):
"In some circumstancies, a fast keyboard return after a
getch() causes the program to abruptily terminate and to
return to the DOS prompt; neverteless, if the key is
pressed slowly, no problem occurs and the program continues."
We suppose you are wondering if we are jocking, but we are not:
you can check it by compiling the small code at the end of
this message. This code has been obtained by simplifying
a large project, but happyly the problem can be reproduced
in this so simple code.
Due to the continuous improvement of DJGPP, we have supposed
that the old problem (1997) dissapeared in the meantime. And
again yes: the old problem described at the beginning of
this message seems not to appear although not stating:
int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK;
Conclusion: perhaps thisassignement is not longer needed.
Obviously you can say: No problem, remove this line and
continue using DJGPP. But a question arises:
- Was the problem with system() and malloc(), printf(), etc
in NT really solved? Or simply we have not fount it yet, after
removing int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK.
On the other hand, we think that DJGPP developpers could
perhaps be interested in this new strange behaviour involving
the speed of the return keystroke after getch() under NT.
The reason for the malloc() series in the code at the end is
simply because they come from simplifying the original code
(where, obviously, the malloc's are useful and assigned to a
pointer). If less malloc() calls are done, the problem
even dissapears.
Unfortunately, we do not have enough knowledge of low level
programming for undestanding the meaning of the
_crt0_startup_flags and how it can interact with getch()
and malloc() causing the program to stop after a fast
return keystroke. We are only programmers that use DJGPP
as a C compiler for relatively high level programming.
Hope this helps to improve this wonderful compiler.
Sorry for the message length. Thanks,
Xavier Pons and Joan Masó
=== Here the code that causes this strange behaviour ===
#include <stdio.h>
#include <conio.h>
#include <stdlib.h>
#ifdef __DJGPP__
#include <crt0.h>
#endif
#ifdef __DJGPP__
int _crt0_startup_flags = _CRT0_FLAG_UNIX_SBRK; /* By comenting this line,
the keystroke problem disappears and you can always read
"Hello world" */
#endif
int main(void)
{
getch();
malloc(80000L);
malloc(8000);
malloc(320000L);
malloc(64000L);
malloc(38400L);
malloc(32000);
puts("Hello world");
return 0;
}
=== End ===
- Raw text -