This is leading to a slow and tedious process of learning all the various EXE formats, and to reverse engineering one (the “W3” format used exclusively by the Windows/386 kernel on 3.x releases, titled WIN386.EXE. The W3 format is really just a collection of LE VxDs, with a directory table right after the W3 header describing where each VxD is and its module name.)

I’m looking to get my hands on anything related to Phar-Lap 286 because it supposedly uses two special NE OS type values, one for console and one for GUI, that I’d like to verify the truth of.

Bonus points if I can run this tool through Phar-Lap 286. The current Makefile for OS/2 builds a 16-bit OS/2 1.x program.

You can find the source code to my program, available under the ISC license, at https://github.com/segin/readexe

If I can figure out how to use the GitHub releases feature, I’ll ship out precompiled binaries for everyone to use.

DOS extenders are so much fun! It’s breaking all the rules!

DJGPP is a mixed bag, the v2 stuff is a lot more forgiving than the v1 GO32. I did a haphazzard port of DooM to v1, and it mostly runs, but it’s so prone to crashing. At the same time it’s cool to downgrade to GCC 1.27 and get it building DooM!

targeting OS/2 should get it going

All this talk of DOS Extenders has me wanting to dig out DJGPP and my copy of Borland Power Pack. I seem to recall the DJGPP was more mature and easier to use than Power Pack and Power Pack didn’t have a protected mode video driver.

(*) I would like to get it working for Watcom.

According to Wikipedia, their first (1986) offering was for the 386 – which kind of blows my mind. What was the install base of 386 devices? What 32 bit developer toolchains existed? What 32 bit APIs existed? I can’t imagine that product being remotely useful.

Moving to the 286 seems as much about using the existing OS/2 developer tools and creating the potential for hybrid applications than anything with the 286 itself. In the late 80s, any developer wanting to support high memory applications probably found themselves needing an OS/2 version anyway.

Agree completely about the incredibly strict licensing in these bundled Phar Lap products. It makes me wonder why it’s even there – what did Microsoft gain by distributing something its users couldn’t use? Why was it distributing an effectively OS/2 development toolchain with its 1993/1994 Windows development tools? After looking at TNT, I’m now wondering if this is the price Microsoft paid to move Phar Lap from OS/2 to NT – they could have supported OS/2 2.x LX as a 32 bit DOS target, and it’s conspicuously absent. But due to the strict licensing, I wonder how many applications moved to the Win32 API as a result of Phar Lap.

Its part of what set me on a long journey to get a copy of TNT. Ive gutted the manuals for version 6, the one I managed to get, and made some disk snapshots.

Had there been a more permissive version of TNT included, maybe DOS would have held on for another year or two, although Direct X basically killed DOS by offering a nice abstraction to graphics/audio/peripherals.

the first 32bit version of PharLap I have is 4.1 although it should have been their first product? The Pharlap 2/3 I have is all 286 based, I could have sword I read that the 386 based stuff came first as it was far easier to go from protected to real mode.. Then they built the 286 stuff afterwards.

Coming back to answer my own question…

It turns out that 16 bit Visual C++ includes the OS/2 based Phar Lap, but the 32 bit Visual C++ 1.1 CD includes the NT based Phar Lap TNT Lite, cleverly hidden in the MSVC32S directory. I haven’t messed with it much yet, but it’s clearly implementing a PE loader. Because it’s the “Lite” version, it’s not intended to support redistribution…but that also means there’s a TNTLITE.EXE loader that can be pointed at a PE file, and it will attempt to execute it from DOS.

Unfortunately I haven’t found many things that work with this. It looks like newer (2.0 or above) C runtimes depend on Win32 APIs that this version of TNT didn’t implement (in particular NLS, just like the OS/2 one.) It needs relocation information in the EXE, which means anything compiled with Visual C++ 4.2 or newer is out. It doesn’t seem to have basic Unicode APIs, so anything must be 8 bit chars. As of now, it’s not much more than a runtime that allows people like this community to compile non-Unicode code using Visual C++ 1.1 and launch it from DOS.

It’s crippled to 2Mb of memory, which seems like ought to be straightforward to remove. It also seems to limit the use of DLLs (unlike the 16 bit version) which may be a more problematic restriction.

Note that Visual C++ 1.1 itself was bound with a version of TNT so it can execute from DOS. This is the only 32 bit version of Visual C++ that appears to do this. There seems to be interesting potential to leverage the “real” runtime used by the compiler with the “lite” tools, but so far I haven’t succeeded.

Oddly enough there is a bunch on my BBS but it keeps getting knocked off.. too many people scanning for telnet.

That said check your email!!