Hacker News

points by londons_explore 3 days ago | 0 comments

I really don't understand why Microsoft didn't build this when they released 64 bit windows.

16 bit windows wasn't complicated, and a simple VM and API translation layer could have kept compatibility going back 30+ years for not many engineering hours.

Yet instead they dropped 16 bit windows support and probably spent more engineering hours to support all the ancient software trying to update, and users who held back upgrading windows because they needed said ancient software, etc

[–] xacky 2 days ago

Backwards compatibility has limits. When a piece of software has been abandoned for 30 years, there is very little commercial value in supporting it. Apple, Google and even Linux are more aggressive in dropping support. It's only IBM on mainframes with multi million contracts that is really going for backwards compatibility at any cost.

[–] my123 3 days ago

being able to transfer HANDLEs across the 16/32-bit boundary notably for COM/OLE integration becomes a lot more painful

Microsoft says at https://learn.microsoft.com/en-us/windows/win32/winprog64/ru...:

> Note that 64-bit Windows does not support running 16-bit Windows-based applications. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data. Attempts to launch 16-bit applications fail with the following error: ERROR_BAD_EXE_FORMAT.

winevdm on Windows eschews that level of integration, but perhaps MS should have shipped WoW16 with limitations instead of nothing.

[–] vintagedave 2 days ago

Naive question from someone who's never written this sort of compatibility layer: couldn't a VDM map handles? They are opaque values. Change the value, basically, keep a 16-bit table mapping to the host OS's 32/64-bit real handles?

Edit: the readme has something very similar:

    wine based Win16->Win32 conversion codes:
    BOOL16 WINAPI DestroyWindow16( HWND16 hwnd )
    {
        return DestroyWindow( WIN_Handle32(hwnd) );
    }

I would guess that's what the WIN_Handle32 method/macro is doing.

[–] my123 2 days ago

Looks like they tried some level of mapping but it didn't go too well: https://www.vttoth.com/CMS/technical-notes/?view=article&id=...

[–] lupical 3 days ago

On the other hand, I'd argue companies using 16-bit applications would be unwilling to upgrade to a 64-bit installation anyway. Microsoft decided it was better to push software developers to upgrade to Win32, given that 32-bit Windows already existed since 95.

[–] da_chicken 3 days ago

Sure, but the 16-bit program that was still being used the most had to be setup.exe or install.exe. For many years it was common to distribute all software packages with a 16-bit installer because it's (slightly) smaller and it's never doing anything that would require 32-bit processing.

So, now, it's not unusual to find software from as late as 2005 that is actually 32-bit software, but it's in a 16-bit installer.

Indeed, it might be the only 16-bit application I've wanted to run other than Castle of the Winds and Scorched Earth.

[–] masfuerte 2 days ago

Not that it matters, but the reason MS recommended a 16-bit installer was that non-Intel Windows NT variants could run 16-bit x86 software via emulation. Windows software that ran on multiple architectures (what little there was) typically had a tiny 16-bit x86 setup program that checked the architecture and launched a native 32-bit installer.

Edited to add: x86-only software had a similar tiny 16-bit setup program that launched the 32-bit installer on x86, and displayed a helpful error message on other architectures. This was done because Windows had a piss-poor error message if you ran a 32-bit exe on the wrong architecture.

[–] hypercube33 2 days ago

They already had 32bit Win32 Windows on Windows (WoW) subsystems on all machines, even ARM64 to a point - the only thing I've seen that it didnt run out of the box was OpenGL which they have a (??!) Store app for Maya3d or something that does OpenGL to DirectX translation - and that seemed to work OK. The biggest issues I had with Windows on ARM64 was the lack of cooling.

Back on track - the 16 bit DOS and Windows stack is a lot different than Win32 - totally different windowing, drawing to the screen, and memory management is involved - it was probably pulled for security reasons and the most common one at Microsoft - "the guy who maintained this left or retired"

[–] mike_hearn 3 days ago

By the time 64 bit Windows comes around the only stuff still running 16 bit is on machines that will never be updated. Embedded boxes in industrial machinery that is itself no longer supported, that sort of thing. No point making it work if nobody will ever update to it.

[–] NetMageSCW 2 days ago

I’ve used WineVDM (otvdm) to run my Fluke 16-bit application to talk to my VR101 Voltage Event Recorder on 64-bit Windows for a few years now.

It plugs into an outlet, records time stamped records of high/low voltage, power outage, surges, etc. Then you use a serial to optical cable to read the data safely.

[–] mshish 2 days ago

Yeah and I would think wanting developers to update to 32/64 bit was also part of the equation.