This is the ring-3 32-bit linear address space's code segment, and it is
hardcoded on OS/2. Generally it isn't explicitly referenced, but things
like CSet/2 would generate thunks that hardcode jmps to it when returning
to 32-bit mode, so you have to patch those out (Linux also hardcodes a
code segment number, but doesn't promise the value won't change, and indeed,
it's different between x86, x86-64, and x86-on-x86-64 apps).
- Let allocateSelector() specify number of pages to allocate.
- Let findSelector() specify if this is a code or data segment.
- Let findSelector() choose if this is a code or data segment
if the caller doesn't know (DosFlatToSel(), etc).
This gets us everything we need (I hope!) to support 16-bit code in LX
binaries and call into 16-bit OS/2 APIs. This is just enough to call
into VioGetMode() (which isn't otherwise implemented yet) as an example.
If this is ever used Winelib-style to provide an OS/2 API to native Linux
binaries, the 16-bit system APIs are 32-bit clean and C callable, as one
might expect them to be. All the tapdancing is to support existing LX
binaries in the loader and bridge between the 32-bit clean APIs and
existing 16-bit code that expects to call 16-bit APIs.
This was a staggering amount of effort, but yay!
Other fixes and improvements probably leaked into this commit, as a
lot of code got touched and a lot of research and debugging took place.
Otherwise, it won't be available to DLL init code when run before the
main executable starts.
Fixes Watcom C's wlink.exe crashing because it gets a NULL command line.
Eventually, we'll maybe need to set the FS register to be a proper TIB pointer,
but I'm mostly hoping that everything else was well-behaved enough to always
use DosGetInfoBlocks() instead. Yeah, right.
Wanted to do this now before it gets out of hand.
Ideally, this can be used for a Winelib-like option eventually, too, where you
don't load OS/2 binaries at all but rather compile and link your OS/2-based
source code against this API reimplementation.
It looks like most of the remaining work for that is filling in dozens of
OS/2 APIs that EMX uses at startup just so we can get to our single
printf() call. :)
Ryan C. Gordon