I finally got this working, although I’ve got to sit down and work out the old makefile format to bind in the hxrt stub instead of running it all on the CLI…
So as a poor example, I used the ancient Fortran 5.1 to build up an OS/2 1.x VIO executable of dungeon, which would run happily on NT 3.1, but of course will not run on XP as they have removed the OS/2 subsystem.
Anyways it’s impossible to run the exe on dos, but fishing around I came across my old Visual C++ 1.5 CD, and on there was the Phar lap 286 dos extender. And one of the neat things it could do, was run simple OS/2 applications under MS-DOS!
So I bound the exe and now it’d run under MS-DOS.
phar lap 286 dungeon 2.5..6
However, since it’s a trial version, it’s limited to 2MB of ram, and you can’t redistribute the resulting exe. Now this is where HX DOS Extender (archive.org mirror/sourceforge mirror) comes in. Over the years, the HX dos extender has provided the functionality of the old Phar lap TNT dos extender by allowing you to run Win32 exe’s under MS-DOS, and it provides a pretty impressive subset of the Win32 api on MS-DOS.
So taking this lead, HX now has a 16 bit 286 centric version that provides a basic OS/2 emulation layer.
So by simply passing the OS/2 exe as a parameter to the DPMI loader (I haven’t quite worked out the stub syntax…) you can run the OS/2 build of dungeon under MS-DOS!
HX16 dungeon 2.5.6
For anyone stuck with either legacy 16bit tools, or a need to support ancient systems, it’s certainly nicer with OS/2 as you have access to a LOT more memory! According to the documentation the HX extender should work nicely with the OpenWatcom Fortran & C, although I currently haven’t tested it.
What’s kind of interesting is that HX doesn’t work under DOSBox, while the Phar Lap 286 DOS Extender will….
Both of these dos extenders build on the old idea of the “Family API” where common API’s between OS/2 and MS-DOS could be mapped between the two OS’s, and a common “bound” executable could then run in either environment. However on the MS-DOS side, it’d be subject to the memory constraints of a realmode MS-DOS executable. The DOS extenders build on this idea, but provide access to additional memory, and a more feature rich OS/2 api.