Q: My compiles run OK from the command line, but hang or crash when
I invoke the compiler from Make.
Q: When I try to compile something, I get a message "16-bit DPMI
not supported".
A: Be sure you aren't inadvertently invoking some 16-bit programs,
such as Borland's Make or cpp.exe from Borland C. GCC cannot run
them, and cannot run under Borland's Make (because Borland's programs
are 16-bit DPMI clients, and the DPMI 0.9 spec doesn't allow mixing them
with 32-bit DPMI clients such as the DJGPP programs). It might be that
another program called make.exe or cpp.exe is found
earlier on your PATH than the Make and the preprocessor which
came with DJGPP. Moving DJGPP's bin directory to the beginning
of your PATH will usually solve these problems.
Note that if you try to mix 16-bit and 32-bit DPMI clients in Windows
DOS box (like use Borland's Make to run GCC, or invoking Borland's
cpp.exe under GCC), the DOS box will usually crash. So this
problem is not specific to CWSDPMI.
If you must use a non-DJGPP compiler or another utility together with DJGPP programs, one solution would be to find a version of that utility that doesn't use the 16-bit DPMI services. For example, many DOS compilers have a real-mode version that won't conflict with DJGPP.
If you use Make compiled under DJGPP v1.x, you will also experience all
kinds of trouble when invoking programs compiled under DJGPP v2. That's
because v1.x programs cannot spawn v2 programs directly (the v1.x
program sees that the child is a DJGPP program and tries to call
go32 to run it, but v1's go32 cannot run v2 programs).
The result usually will be that the child either crashes or silently
exits. If that's your problem, be sure to upgrade your Make to
the port distributed with v2. (Note that v2.x programs generally know
how to spawn both v1.x and v2.x programs.) You can use go32-v2
to work around this limitation (see description of go32-v2, below), but I suggest doing
that only if you absolutely cannot upgrade to v2's Make.
Some users report that v1.x programs might sometimes hang or reboot the
machine when invoked from v2.x Make. The reason for this is a known bug
in the versions of go32-v2.exe program distributed with DJGPP
v2.0 and 2.01: it would not restore the keyboard handler after the COFF
image it runs exits. To work around that bug, don't touch the keyboard
throughout the entire run of Make; to solve it, upgrade.