Hacker News Reader

Comment by touseol | Hacker News Reader

That’s not a DOS app, it’s a Win32 console app. DOS apps (16-bit or 32-bit) or Win16 apps would not run natively.

That depends on if they are using 64 bit or not. The 16bit VDM was deprecated on that move from 32 to 64. Which is the majority of most installs these days.

What is kind of neat is every windows application/dll is a valid DOS application. The first part of all of them is a valid MZ DOS 16 EXEcutable. Windows just treats it as a skippable header and reads the real header that is about 100 bytes in and then decides which subsystem to fire up (win3x, win32, OS/2, etc). But if you take a exe compiled today with current tools and put it on a DOS 3.3 box it would run the exe and print out it can not run (the exe has that in there).

Also from that era not all DOS applications were exclusively 16 bit. Many were hybrid. Just to have better control over the memory space instead of using segmentation was usually worth the speed boost (as well as the bigger registers). Windows from that era usually had extra 'pid' file where you could basically tag the executable as 'hey you are about to run a 32 bit app get out of the way windows oh and support dpmi while you are at it'.

If that was a Windows 10 screenshot then yes there would have been the possibility of it being the 32-bit edition running a DOS app through NTVDM. But the poster says Windows 11, which does not have a 32-bit edition.

I’m not aware of 64-bit Windows being able to run 32-bit DPMI DOS apps natively, I think those still required NTVDM.

> I think those still required NTVDM

Pretty sure you are right. As I think that is what setup the interrupts for it. Win9x did it very differently and would basically just put command.com back in charge of stuff to sort of make it work with a sys file. NT with DPMI programs was usually very hit or or miss (more miss). If they did not play just right with windows the thing would just crash out.

Think there might be a win11 32 bit out there. But nothing that MS sells to normal end customers. But my brain may be playing tricks on me and I am confusing different articles I have read. But that would probably be some sort of weird kiosk ODM build. Not what most normal people would have (like in that post).

OTVDM will allow running 16-bit windows programs on modern 64-bit windows.

OTVDM is great, but it's just using Wine. Windows really ripped out the whole 16-bit compatibility layer, which is a little sad.

It’s not that Microsoft chose to rip it out. NTVDM relied on Virtual 8086 mode. X86 processors cannot transition to this mode from 64-bit mode.

https://en.m.wikipedia.org/wiki/Virtual_8086_mode

Intel is proposing to remove 16-but support entirely:

https://www.intel.com/content/www/us/en/developer/articles/t...

They were kind of forced to. WoW (classic, not WoW64) relied on the CPU being able to switch to a 16-bit context, in much the way modern WoW uses amd64's compatibility mode. OTVDM's project page directly mentions this as a core component:

> CPU Emulator

> 64-bit Windows cannot modify LDT(NtSetInformationProcess(,ProcessLdtInformation,,) always returns error)

They would have had to replace/extend WoW with an architecture emulator. Raising the development/support complexity quite a bit for little gain (few people that use Windows 11 are running DOS or Win16 applications today, beyond retro gamers who use DOSBox anyways).

Win16 got dropped at some point, probably because keeping it didn't add up financially. I have little doubt they could have kept support for much older stuff.

There's a "pirate" port of NTVDM to 64-bit Windows (from leaked NT 4.0 source) so it's certainly not technically infeasible: https://github.com/leecher1337/ntvdmx64

There's also winevdm from the Wine project.

Something that confuses me is that this states it's running a binary compiled 30years ago. How is this not 16bit?

I'm aware of win32s, I used to run it but still it seems unlikely this is a win32 console app unless there's an incredibly unlikely set of circumstances behind this.

Or perhaps it was simply recompiled after all despite what the Twitter post states?

9x wasn't the only Windows OS.

The path contains the phrase "ntbin". It was compiled for NT.

My guess is this is a PE format type windows application. Though I suppose you could get a NE format file to work correctly if the binary was compiled as 32 bit. My memory is a bit fuzzy on this but I think you did have the option to compile either way.

Correct, it's a PE file.

Windows NT 3.1 was released on July 27, 1993.

In fact looking into this further the only thing windows 11 lacks is the ntvdm which allows some dos api calls. If your binary is straightforward and not tied to msdos which this is it's fine. So I think the idea that this is a 32bit windows console application is completely untrue. It's also intuitively untrue when you consider the age of the app being run here.

The fact that there is no Windows 11 version with NTVDM is why this must be a Win32 console app, assuming the poster is truthful. Windows NT 3.1 came out in 1993. This being in a directory called “ntbin” gives another hint.

I see that makes sense. I feel it's also a little misleading from the original post. An exceptionally specific binary from 1993 works but the implication here is that the compatibility is more than this.

Author here. I've been running Windows since 3.0 and I copy my old tool folders with me whenever I change machines or upgrade the OS. This GZIP.EXE is the oldest EXE I have in my \ntbin tool folder that still works. The folder has 579 EXE files.

> that still works.

I think that is the point being made. This exe is cherry picked as the oldest working exe, it isn't like every 30 year old exe in that folder still works.

Reply on news.ycombinator.com