Hacker News Reader

Comment by sedatk | Hacker News Reader

That and it's 30+ years (NT was released in 1993). Backwards compatibility is certainly one of the greatest business value Microsoft provides to its customers.

View on HN

If you include the ability of 32-bit versions of Windows to run 16-but Windows and DOS applications with NTVDM, it is more like 40+ years.

https://en.wikipedia.org/wiki/Virtual_DOS_machine

(Math on the 40 years: windows 1.0 was released in 1985, the last consumer version of Windows 10 (which is the last Windows NT version to support 32-bit install and thus NTVDM) goes out of support in 2025. DOS was first released in 1981, more than 40 years ago. I don’t know when it was released, but I’ve used a pretty old 16-bit DOS app on Windows 10: a C compiler for the Intel 80186)

True. I just assumed that 16-bit support got dropped since Windows 11 was 64-bit only.

Microsoft decided not to type "make" for NTVDM on 64-bit versions of Windows (I would argue arbitrarily). It has been unofficially built for 64-bit versions of Windows as a proof-of-concept: https://github.com/leecher1337/ntvdmx64

That’s okay, and if people want to test their specific use case on that and use it then great.

It’s a pretty different amount of effort to Microsoft having to do a full 16 bit regression suite and make everything work and then support it for the fewer and fewer customers using it. And you can run a 32 bit windows in a VM pretty easily if you really want to.

Or you can run 16-bit Windows 3.1 in DOSBox.

Sure, but again that’s on you to test and support.

> Microsoft decided not to type "make" for NTVDM on 64-bit versions of Windows (I would argue arbitrarily).

I recently discovered that Windows 6.2 (more commonly known as Windows 8) added an export to Kernel32.dll called NtVdm64CreateProcessInternalW.

https://www.geoffchappell.com/studies/windows/win32/kernel32...

Not sure exactly what it does (other than obviously being some variation on process creation), but the existence of a function whose name starts with NtVdm64 suggests to me that maybe Microsoft actually did have some plan to offer a 64-bit NTVDM, but only abandoned it after they’d already implemented this function.

> I’ve used a pretty old 16-bit DOS app on Windows 10: a C compiler for the Intel 80186

It’s amazing that stuff still runs on Windows 10. I’m guessing Windows 10 has a VM layer both for 32-bit and 16-bit Windows + DOS apps?

Windows 10 only does 16-bit DOS and Windows apps on the 32-bit version of Windows 10, so it only has a VM layer for those 16-bit apps. (On x86, NTVDM uses the processor's virtual 8086 mode to do its thing; that doesn't exist in 64-bit mode on x86-64 and MS didn't build an emulator for x86-64 like they did for some other architectures back in the NT on Alpha/PowerPC era, so no DOS or 16-bit Windows apps on 64-bit Windows at all.)

https://github.com/leecher1337/ntvdmx64

But only to a degree, right? Only the last two decades of software is what the OS ideally needs to support, beyond that you can just use emulators.

Maybe, but your app could also be an interface to some super expensive scientific/industrial equipment that does weird IO or something.

Software is written against APIs, not years, so the problem with this sort of thinking is that software written -say- 10 years ago might still be using APIs from more than 20 years ago, so if you decide to break/remove/whatever the more-than-20-year-ago APIs you not only break the more-than-20-year-ago software but also the 10 year old software that used those APIs - as well as any other software, older or newer, that did the same.

(also i'm using "API" for convenience here, replace it with anything that can affect backwards compatibility)

EDIT: simple example in practice: WinExec was deprecated when Windows switched from 16bit to 32bit several decades ago, yet programs are still using it to this day.

Pretty much the only 16-bit software that people commonly encounter is an old setup program.

For a very long time those were all 16-bit because they didn't need the address space and they were typically smaller when compiled. This means that a lot of 32-bit software from the late 90s that would otherwise work fine is locked inside a 16-bit InstallShield box.

> Pretty much the only 16-bit software that people commonly encounter is an old setup program.

I know quite a lot of people who are still quite fond of some old 16-bit Windows games which - for this "bitness reason" - don't work on modern 64 bit versions of Windows anymore. People who grew up with these Windows versions are quite nostalgic about applications/games from "their" time, and still use/play them (similar to how C64/Amiga/Atari fans are about "their" system).

People tend to forget that it already is 2024.

Short of driver troubles at the jump from Win 9x to 2k/XP, and the shedding of Win16 compatibility layers at the time of release of Win XP x64, backwards compatibility had always been baked into Windows. I don’t know if there was any loss of compatibility during the MS-DOS days either.

It’s just expected at this point.

On DOS, if you borrow ReactOS' NTVDM under XP/2003 and Maybe Vista/7 under 32 bit (IDK about 64 bit binaries), you can run DOS games in a much better way than Windows' counterpart.

Afaik due to POPF not trapping Reactos implemented NTVDM as a software emulator.

https://web.archive.org/web/20170723164052/http://community.... https://web.archive.org/web/20151216085857/http://community....

At this point you might as well use DOSBOX.

Intel Protected Mode POPF fail:

https://docs.oracle.com/en/virtualization/virtualbox/6.0/adm...

https://devblogs.microsoft.com/oldnewthing/20160411-00/?p=93...

I think they recently improved NTVDM a lot.

Not long ago, it was posted here a link to a job advert for the german railway looking for a Win 3.11 specialist.

As I see it, the problem is the laziness/cheapness of companies when it comes to upgrades and vendor's reluctance to get rid of dead stuff for fear of losing business.

APIs could be deprecated/updated at set intervals, like Current -2/-3 versions back and be done with it.

Lots of hardware is used for multiple decades, but has software that is built once and doesn't get continuous updates.

That isn't necessarily laziness, it's a mindset thing. Traditional hardware companies are used to a mindset where they design something once, make and sell it for a decade, and the customer will replace it after 20 years of use. They have customer support for those 30 years, but software is treated as part of that design process.

That makes a modern OS that can support the APIs of 30 year old software (so 40 year old APIs) valuable to businesses. If you only want to support 3 versions that's valid, but you will lose those customers to a competitor who has better backwards compatibility

Reply on news.ycombinator.com