Hacker News Reader

Comment by derefr | Hacker News Reader

I keep seeing this statement, and it's making me wonder: how hard would it have been for Windows 10 to simply ship with a 16-bit WinAPI-binary transpiler (ala Rosetta) or emulator (ala DOSBox)?

View on HN

Pretty hard. It's not just a matter of executing 16bit assembly, you also need to handle mapping every single window message and callback between 16bit handles and the real native handles, of which there are thousands and the meaning/interpretation of parameters are unique for each one.

This guy is doing just that in .NET. While he uses a full blown CPU emulator for executing 16bit x86, the hard part is all the thunking and bidirectional mapping of handles and memory pointers and stuff: https://medium.com/@CantabileApp/implementing-window-messagi...

This seems like the harder strategy of the two. What about simply having a small Windows 3.1 or 95 VM that gets run in the background under HyperV, with fresh VXDs written for it to allow it to use paravirtualized resources, so as to allow it to do the same sort of "infinite framebuffer canvas used to back native windows for the compositor" tricks VMWare's Unity mode and the like do?

Doesn't MS already ship this as a "Virtual Windows XP Mode" based on VirtualPC?

The huge downside is of course the lack of integration with your main OS - copy&paste and drag&drop of rich/dynamic content, OLE embedding, keyboard settings, shared file systems and drive letters, printer drivers, all sorts of windows preferences, applications installing random global windows hooks, etc etc.

I doubt it would be hard, but I don't see why anyone would bother.

At my last job, we would occasionally need to dig up old code because Microsoft finally removed something they had deprecated several years before. I think it was always amusing.

One case that stands out was a utility program that would update data for our users each month. I needed to change something about the string handling. After updating the data, the program would enumerate all running software and kill any copies of our program (so that they would need to read the new data on startup). I noticed that we went through the trouble of enumerating 32-bit and 16-bit programs. Since we hadn't shipped a 16-bit version of our software since the '90s, and we had changed our data format significantly since then, I happily ripped that code out. I don't think you can find information on 16-bit Windows on MSDN anymore.

I guess, to put it another way, who's shipping 16-bit programs?

There was something called WoW, not sure it did that

But at this point I can see why MS would not bother with it

IIRC WoW just provided a layer to point 32bit binaries to 32bit libraries on 64bit systems.

So you have the ass-backwards situation where %WINDIR%\System32 is full of 64bit dlls, and %WINDIR\SysWOW64 is full of 32bit dlls.

In traditional Microsoft fashion, it's both [0]. WoW is the 16bit compatibility layer on 32bit systems, WoW64 is the 32bit compatibility layer on 64bit systems.

[0]: https://en.wikipedia.org/wiki/Windows_on_Windows

The original WOW was doing a 16-bit to 32-bit layer.

WOW64 (in 64-bit Windows OSes) does 32-bit to 64-bit.

The naming of System32 made sense back when they came up with it, but now it's a bit ridiculous. However, since there are so many incompetent Windows programs using hard-coded paths instead of SHGetFolderPath (including, BTW, literally every Java desktop app that doesn't include its own shim-- the JVM itself has this bug!), it's something Microsoft doesn't have the ability to fix.

Reply on news.ycombinator.com