DOS ain't dead

Interesting, but it makes some sense. The PE part seems to be like win32 console app and RTM extender allows it ro run under DOS like HXDOS. But there muse be some 16bit stub that loads RTM extender so I wonder in run under win64 without NTVDM.

Maybe it would be possible to modify other stubs for 32bit DOS compilers (DJGPP and OWC and maybe others) to be compatible with win64.

---
DOS gives me freedom to unlimited HW access.

> It is probably already known, but just to make sure here an observation I
> just made:
>
> On my vista/64 workstation, I was decrunching some old dos archives, and
> these are compressed using the "quantum" (.q) compressor. The archive is
> available on garbo.

http://en.wikipedia.org/wiki/Quantum_compression

> The archive contains two programs. A dos program, and a windows compressor
> I had some hopes for. The windows program (QWIN, NE, so older win16)
> failed, and just to be sure I ran the dos version, and it RAN.
>
> So they are PE32, but for dos, probably of Borland (C++?) origin, and they
> run on win64.

PE is just an .EXE header, COFF is just an object format, Win32 is just an API. So yeah, any OS can mix and match those, and several have indeed used them. I'm not sure why you're surprised. Maybe you forgot, or maybe just the fact that it existed circa 1995 is impressive. Remember that backwards compatibility is usually due to easier transitions, tool reuse, etc. Nothing is born in a vacuum, so they try to reuse things as much as possible (e.g. 16-bit real mode compiler tools -> 16-bit pmode). Dunno why NT uses COFF, perhaps because of its architect's VMS history.

Remember EMX? It combined DOS (MZ) and OS/2 (LX) into one "family mode" (?, blended?) .EXE. (Not the same as two separate .EXEs bound together a la [DOS MZ] "STUB=blah.exe" in *.def.) And RSX.EXE was the DPMI/DOS "extender" that let it run when VCPI or raw wasn't available (e.g. Win 3.1 / 386 Enhanced mode). That guy (Rainer S.) also made RSX/NT, which was DOS + WinNT (instead of OS/2). This was all before Cygwin and MinGW got stable and popular, of course. It basically used DJGPP (COFF) "host" with a few extra things to "cross" compile for Win32 target. I think it was also a way of overcoming LFN issues in NT 4.0 (or such), since that didn't have LFNs for DOS (yet). (There's some old GCC built with that too, on Hobbes also, IIRC.)

My 7zdecode package includes an RSX/NT .EXE, which will run in either DOS (w/ RSX.EXE + CWSDPMI.EXE) or Win32/Win64 (w/ a few of his .DLLs). Unlike 32RTM, RSX/NT is open source, so you can take a look if super curious (doubt it).

Rumor has it that early Delphi beta had support for dual DOS / Win32, but they removed that at the last minute for unknown reasons. No idea about BCC itself, 5.01 had DOS support (with optional PowerPak?), but 5.5 was exclusively Win32 (though with relocations). WDOSX (PE-based DOS extender) worked with Delphi up through 6 (?) and BC55 because of that.

So I guess the moral of the story is that DOS extenders (and esp. DPMI circa 1989) first introduced 386 software to the masses, OS/2 was the big 286 behemoth, but Win95 was when 32-bit became ubiquitous. Linux or *BSD will probably claim first to support AMD64 (decently). Unfortunately, you can't use 64-bit stuff in 32-bit mode, sadly.

P.S. Nowadays, it's probably just easier to use bytecode or raw scripting files across platforms.