Q: What about Windows NT?
A: Current Windows NT versions support DPMI programs in the DOS box, so DJGPP programs should in general run fine under NT (but see the list of possible problems below).
The DPMI server built into NT (and Windows 9X) loses selectors with each
child program that is invoked by a DJGPP program, so after about two
thousand calls to functions from the spawnXX family you can see
an error message like this:
Load error: no DPMI selectors
Some versions of NT lose DOS memory instead of selectors, so you might see another error message:
Load error: no DOS memory
These problems are likely to afflict only DJGPP ports of Unix shells
(such as bash), since no other DJGPP program, not even
Make, is likely to call so many child programs before it exits.
The only known work-around is to exit the shell every now and then,
because when all the available selectors are exhausted, the DOS box will
crash. I'm told that Make sometimes fails on long
Makefiles on Windows 9X, where the selectors are lost at even
higher rate than on NT. If you ever run a very long Makefile and
see Make crash, just run Make again, and it will pick up
where the crashed session has left off.
The long filename API (the special functions of Int 21h which support file names longer than the DOS 8+3 limitation) for DOS box is not supported by current versions of Windows/NT, so you cannot have long filenames there from DJGPP programs. An alpha version of an LFN driver for NT which enables long file name support for DJGPP programs, written by Andrew Crabtree and significantly improved by Wojciech Galazka, can be downloaded the Web.
The popular DJGPP IDE RHIDE needs a -M switch to work on NT
(to disable the mouse support which will otherwise crash RHIDE).
Version 1.4.7b or RHIDE reportedly solves this problem and allows
the mouse to be used on NT. Also, one user reported that he had to type
rhide twice to enter RHIDE, because the first invocation
immediately exits back to the command-line prompt with no message, if
you don't disable the mouse with -M.
You might have problems with using the SVGA modes of your video card
under Windows/NT; only standard VGA modes (including mode-X) work. That
is because NT doesn't allow arbitrary direct access to the SVGA
registers, without which it is impossible to recognize the type of the
SVGA and employ its capabilities. For example, a user reported that GRX
functions and the MODETEST.EXE program thought that only a
standard VGA was installed, whereas he had an S3 card. There is nothing
you can do about this feature of Windows/NT; that is the price you pay
for the stability and protection you get under this OS (a runaway
program that accesses hardware registers can wipe out your disk or wedge
the entire system cold). However, I'm told that Windows/NT 4.0 supports
DirectX which is a method of accessing screen, audio and other
peripherals directly, and the Win32 ports of Allegro and other graphics
packages can use it.
The Allegro library also has problems on NT. One user reports that even switching into the standard 640x480 video mode turns the screen black and kills the machine. Programs that use Allegro to switch into VESA modes usually don't work, since NT doesn't support SVGA graphics modes. In particular, the example programs provided with Allegro print an error message like this:
Error setting 24 bit graphics mode VESA not available
Programs that use the "nearptr" facility of DJGPP to access absolute
memory addresses (e.g., for memory-mapped devices) won't work on NT,
because its DPMI server silently ignores functions that set huge limits
on selectors. Since the default algorithm which allocates memory from
the DPMI server needs to set such huge limit in some rare cases, there's
a small probability that a program will fail or crash even if it doesn't
set selector limits in user code. It is best to use the Unix-style
sbrk algorithm in programs that run on Windows/NT. See the
library docs for the variable _crt0_startup_flags where the
_CRT0_FLAG_UNIX_SBRK bit is explained, for more info on this
issue. If you cannot switch to the Unixy sbrk (e.g., if you
don't have access to the program's sources), I'm told that sometimes
such problems can be worked around if you run DJGPP programs in a
full-screen session; your mileage may vary.
Another problem on NT is that you cannot install a handler for the
SIGFPE, SIGINT, or SIGALRM signals: if you do, your
program will crash as soon as the signal is generated (in DJGPP
v2.02 and later, FP exceptions are masked by default, so you will need
to unmask them first, otherwise SIGFPE won't be generated). This
is due to a bug in NT.
Windows/NT makes it impossible to use FP emulation on a machine that has
the FP hardware. If you set 387=n on NT, the DJGPP startup code
calls the DPMI function to switch on the FP emulation, but NT ignores it
and continues to use the hardware FPU.
Yet another problem with NT is that interrupting some programs with Ctrl-<C> causes Dr. Watson to complain about "Access Violation" (that's NT'ese for GPF) and abort the program; careful inspection of Dr. Watson's logfile seems to indicate that the crash is inside NT's own code which handles the exception deliberately produced by the DJGPP's machinery that translates the Ctrl-<C> keypress into a signal. It seems NT uses the DJGPP stack for some of that processing, which is a no-no inside an exception handler. Sorry, no work-around.
The above-mentioned problems with signals are probably the cause for
another type of calamities on Windows/NT: running a program compiled
with the -pg option causes it to crash almost immediately due
to--you guessed it--"Access Violation" in NTVDM (that's the NT DOS
Emulator).
Windows/NT comes with its own version of redir.exe, which serves
a different purpose. If you invoke redir, and the NT's
winnt\system32 directory is before DJGPP's bin
directory in your PATH, you will see a message saying "The VDM
Redirector is already loaded". To solve this, rearrange your
PATH or rename DJGPP's redir.exe to somethink like
djredir.exe.
Programs that use the library function delay may hang if the
<Pause> key is pressed while the program is inside the call to
delay. The work-around is to use usleep or write a loop
which calls uclock.
Another peculiarity of the NT DOS box is that beeping by printing the
\007 character to stdout or stderr behaves
strangely. Usually it beeps, but the beep is very long; sometimes, you
get the Windows "ding" sound. It is recommended that you turn on the
"visible bell" feature of the tools that support it, like Emacs and
Less.
Accessing the serial communication ports on NT also has some problems.
Anton Helm says that the first
two invocations of a program that accesses the port behave abnormally;
e.g., the data from the device on the other end of the link doesn't get
fed into your program. After that, the third and subsequent invocations
work correctly, but only if you use COMAND.COM as your shell.
Using the default cmd.exe leaves the link in a state where you
get the replies from the other device for the nth invocation of
your program in the n+1st invocation.
In other words, to make the com port work on NT, you need to open the
DOS box with COMMAND.COM, run your program and exit it two times,
then invoke the program for the third time and start working.
Some people report that NT servers cause much more problems than NT workstations of the same version and build. It seems that these problems usually mean that NT installation was done incorrectly (maybe it is much harder to get it right with a server than with a workstation?). If you have such problems, try to install a workstation, or re-install the server, and see if that helps. And if you gain some insight as to why servers like DJGPP less than workstations, please tell what you've learned.
The Cygnus Win32 project is another (unrelated to DJGPP) port of GCC and development tools to Windows/NT and Windows 9X platforms, which specifically targets development of Windows programs. See description of the Cygwin project, for more details about the Cygnus ports.