GLoaderState is moved to a new lib2ine library, which everything links
to and sets up what it can in a DLL constructor, so your app can just
link to doscalls or whatever and it'll have what it needs without
something like lx_loader doing a lot of heavy lifting before your
main() runs.
Now a perl script parses our headers and generates glue code, export tables,
etc. This automates all the macro nonsense and bridge code, and separates
out all the stuff you need for binary compat with OS/2, so you can remove it
all from the build if you want to just build native libraries that supply
the OS/2 API to native apps (like Winelib vs Wine).
This makes upkeep details less nasty, and easier to build native binaries
when implementing and improving APIs, so you can debug directly without
a lot of drama.
Finger (etc) also rely on MPTN\DLL\tnls32.dll, which I pulled out a copy of
OS/2 Warp 4.52, which loads and limps along enough to not be a problem.
Reimplementing that library is going to be a pain, so that's a job for another
day. Inexplicably, tnls32 references pmgpi.dll's GpiQueryTextBox(), so I put a
stub for that in, too, but we're nowhere near really implementing GPI yet.
This is enough to run "finger.exe icculus@icculus.org" and see my .plan file,
which I consider a victory. A few more TCP/IP command line tools aren't far
behind.
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.
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.
Ryan C. Gordon