21.2 DJGPP environment in v2.x

Q: There's been this talk about v2 and about go32 going away in that version, but I'm confused on what the new setup will be. Could you clarify the details of this change?

A: In v1.x of DJGPP, the go32 extender was responsible for the following:

• Loading and running the application in protected mode.
• Managing protected-mode and virtual memory.
• "Extending DOS" so that protected-mode programs could issue calls to real-mode DOS and BIOS services and still run. (This is mostly done by switching to real mode and reissuing the interrupt, but some services require special handling by the extender.)
• Handling of hardware interrupts which happen while the CPU is in protected mode.
• Loading 387 emulator (if required).
• Loading the graphics driver and working with VGA bank-switching to create an illusion of a linear video memory.
• Command-line and wild-card expansion in a Unix-like fashion.

In v2.x, a minority of these functions are done by a DPMI host, which is a memory-resident software required to run protected-mode programs under MS-DOS. There are a few commercial DPMI hosts (like Quarterdeck's QDPMI, Qualitas 386Max, MS-Windows 3.X and Windows 9X, OS/2, even Linux), but DJGPP v2 comes with a free DPMI host called CWSDPMI for those who don't have one already. Loading the application into protected-mode memory (a function done in v1.x by go32) is handled by a 2KB-long real-mode stub which runs at start-up, before the application's main functions is called (the stub will also load CWSDPMI if no other DPMI host is detected). All the other custom code required to process BIOS- and DOS-related calls from protected-mode is now built into the library functions which your program calls, so there is no need for a special extender, because the application just issues DPMI calls serviced by the DPMI host.

CWSDPMI can be loaded as a TSR, even loaded HIGH into the HMA/UMB, which will make applications load much faster.