int86Q: Why does my program crash with "Unsupported DOS request 0xNN"
or "Unsupported INT 0xNN" when I call int86 or intdos
functions to invoke a software interrupt?
A: Calling real-mode DOS or BIOS services from protected-mode
programs requires a switch to real mode, so the int86 family of
functions in the DJGPP library should reissue the INT instruction after
the mode switch. However, some services require pointers to memory
buffers. Real-mode DOS/BIOS functions can only access buffers in
conventional memory, so int86 has to move data between your
program and low memory to transparently support these services. But
this means int86 should know about all these services to perform
these chores correctly, because each service has its own layout and size
of the buffer(s). While int86 supports many of these services,
it doesn't support all of them. The supported functions are listed in
the library reference, see
int86.
For those services it doesn't support, you will have to call the
__dpmi_int library function instead; it is also documented in the
library reference. __dpmi_int requires that you set up all the
data as required by the service you are calling, including moving the
data to and from low memory (see how to use buffers with DOS/BIOS services).
Note that calling int86 and intdos can sometimes cause
trouble due to size (16 bits as opposed to 32 bits) of the members in
the union REGS structure. Do not assume that
e.g. regs.x.ax is always 16 bit! This problem and the facilities
available to specify the width of the registers are all described in the
library reference; see
int86.
In particular, programs which interface with the mouse via calls to the
int86 library function, should mask off the high 16 bits of the
registers which report mouse position and other values, since the high
16 bits aren't necessarily zeroed (which will wreak havoc in any program
that interfaces to the mouse).
For these reasons, it is generally recommended to use __dpmi_int
instead of int86 and intdos.