Hacker News Reader

Comment by jeroenhd | Hacker News Reader

This can be very helpful in the future for playing games with strange 16-bit-mixed-with-32-bit installers that fail to run properly on modern Windows, even 32-bit versions. I hope WSL2 comes out soon.

Now that installing wine in Linux on windows is possible, the next step becomes clear. We must compile and run cygwin on wine in Linux on Windows.

View on HN

You can already do that with OTVDM: https://github.com/otya128/winevdm

Using it not only any 16bit installer works, but also most 16bit applications. As an example you can play Exile by Spiderweb[2] on your Windows 64 PC.

It even contains a .reg file that allows it to be installed system-wide so that you can run a 16bit .exe just by double clicking it in Explorer (or any other file manager).

[1] https://github.com/otya128/winevdm

[2] http://www.spiderwebsoftware.com/exile/winexile.html

Looking at the install.inf file, I saw that they first remove a key from the registry with the name VDM in it. So I wondered what VDM means.

> Virtual DOS machines (VDM) refer to a technology that allows running 16-bit/32-bit DOS and 16-bit Windows programs when there is already another operating system running and controlling the hardware.

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

So how come otvdm is needed I wondered.

Same Wikipedia article explains it.

> NTVDM is a system component of all IA-32 editions of the Windows NT family since 1993 which allows execution of 16-bit Windows and 16-bit / 32-bit DOS applications. It is not included with 64-bit versions. The Windows NT 32-bit user-mode executable which forms the basis for a single DOS (or Windows 3.x) environment is called ntvdm.exe.

But why did Microsoft not include VDM in 64-bit systems? I thought MS was all about that backwards compatibility.

MS is already running a similar system to translate 32-bit applications to 64-bit mode (WOW64). Keeping compatibility with 16-bit would have big consequences for the NTVDM. The alternative would be to run NTVDM on top of WOW64 but such a system would be a recipe for disaster.

I don't think the compatibility with 16-bit systems is worth the headache/expense. As long as 32-bit Windows exists, you can still run the few relevant and compatible DOS applications so I doubt anyone is missing much aside from a few nostalgic gamers.

>I doubt anyone is missing much aside from a few nostalgic gamers.

There's tons of 16-bit SCADA stuff in the world that it would be nice to not have to run on a ~20yo version of windows.

Aren't there still 32-bit versions of Windows 10? AFAIR only the server versions are 64-bit only by now.

Installing 32-bit OS on a 64-bit UEFI system can be a problem.

I hope those scada systems aren't running on regular Windows. If they are, they should be running on Win10 LTSB on 32-bit so they should keep working till at least 2025 if XP's level of compatibility was good enough to run them.

If they can't be run on that, there's still MS-DOS licenses being sold and FreeDOS might also serve them in a pinch. If a system is not maintained for long enough that it's still running in compatibility mode, you might ask well just disconnect the network cable and run Windows 3.11/95/98. Microsoft is not at fault for the manufacturer not maintaining their systems.

What if the manufacturer doesn't exist anymore?

Or you're using hardware from the 70s that they dropped from software support in the 90s and the software version you need won't run on anything newer than Win2k.

In that case you either were aware of the risk of your device breaking down in the future and have started looking into migrations or workarounds the moment the news hit, you took the risk that didn't happen and now have to deal with the consequences or you just didn't plan ahead enough.

Just keep running the older version of Windows that worked with the device. Add a couple of layers of configurations, firewalls, VPNs, traffic monitoring and whatnot inbetween to reduce the risk and don't connect the device to the internet. Your solar panel farm doesn't need to access Gmail or run Windows 10.

Your obscure SCADA device is your responsibility. The switchover to 32bit had been announced 20 years ago and the switchover to 64bit 10 years ago.

Also, if the manufacturer doesn't exist anymore, where are you going to source replacement parts?

Virtual 8086 mode isn't available when running a 64-bit OS, so the virtual DOS machine code simply won't work there. This is less of a problem with most 16-bit Windows applications since the limited 16-bit functionality they need is still possible under a 64-bit OS but making this work requires some extremely hairy kernel code.

You could just run it in an emulator. And microsoft has written a virtual 8086 emulator for virtual PC. Virtual 8086 mode was just a virtual machine anyway.

NTVDM used to contain an x86 emulator included for running DOS programs under Windows NT on non-x86 platforms (Alpha, MIPS, PowerPC). There is no reason in principle why they couldn't have used that existing code on x86-64. But, I assume they decided that the cost of doing that (in developer time/etc) wasn't worth the benefit. (Running DOS programs has little commercial relevance any more, and the small minority who still have a need for that are better served by more fully-fledged virtualisation solutions such as Hyper-V, VMware or VirtualBox.)

AFAIK including the full VDM wasn't technically possible due to amd64 architecture limitations (no real mode support when in long mode - at least not without use of virtualization but that wasn't a thing at the time). They probably could have implemented partial support but i guess they wanted to keep the full VDM for 32bit versions of Windows (which were the majority for a good number of years anyway and thus more important for backwards compatibility).

OTVDM emulates a 386-ish CPU so it isn't affected by that (i think there is also some code to use virtualization instead but i'm not sure). It is much slower though, but it should still be much faster than the target hardware that 16bit Windows applications had. Perhaps it might be an interesting project to port DOSBox' more advanced JIT CPU emulation code to this.

Playing Exile 2 is exactly why I want to run 16 bit applications. I basically learned English from that game! I remember being frustrated being locked into the shareware version by Shareware Barriers, figuring out how to edit maps by using Norton Disk Edit on the game files, and digging new tunnels into the cave wall. I was about 12 and I still consider this my greatest hacking achievement...

You are in luck then, all three Exile games are free from the site :-) (you need to dig a bit to find them, go to the games, then old games then click on the icon for the windows version).

> you need to dig a bit to find them

Should not be a problem, seems user has been digging for Exile since he was 12

Now I just need to find the old tileset that looked like it was hand drawn in MS Paint to maximize the nostalgia!

> As an example you can play Exile by Spiderweb[2] on your Windows 64 PC.

How is this of all things the go-to example?

It's exactly what I want to do! Were these games more popular than I thought?

For the time, yes. They were free, and they were Ultima-alikes, and those were popular. JV has always also had a knack for writing, which helped make them stick.

He's still making games, and they're still pretty much the same games they were--and to me that is a positive.

This project is only completed when you can recursively keep doing this forever, without it ever breaking.

Any CPU can only have one hypervisor running at a time. Thus the recursion stops pretty quick.

Cygwin and Wine don't use virtualization. And even if they did, most hypervisors support nesting these days.

Because, of course, its not a emulator

Why? There's only one hypervisor involved for the initial "wine" environment.

Neither WINE nor WSLv1 use virtualisation. WSLv2 does use virtualisation however; but WINE still isn't a VM.

I was referring to WSLv2 here, so technically there is a hypervisor involved at the root level hosting the first WINE instance in the chain.

Further recursion WINE => Cygwin => WINE however will not require more nesting of hypervisors.

Actually most modern hypervisors allow nested virtualization.

https://www.linux-kvm.org/page/Nested_Guests

https://communities.vmware.com/docs/DOC-8970

Not even just modern hypervisors. The IBM mainframe hypervisor z/VM (and its predecessor VM/CMS) has supported nested virtualisation for decades. It was an important tool to support its own development (especially considering that mainframes were expensive and not even IBM could afford to give every mainframe OS developer a whole mainframe to themselves.)

Well, yes and no. On modern enough hardware you can do nested virtualisation, so you can run kvm in esxi on hyper-v if you want. Not that it's very usefull, but it is a fun weekend project nonetheless.

I use nested virtualization for Windows Desktop -> Linux VM -> minikube. Works great.

Obviously you could just run minikube under Windows, but then from the Linux VM you can't "minikube ssh" and whatnot, so nested virtualization makes everything a lot simpler.

You can even do nested virtualization without hardware support, it's just super duper slow and not a lot of hypervisors think it's worth the complexity increase.

Intel and AMD CPUs have supported hardware-accelerated nested virtualisation for quite some time now.

https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w...

https://www.redhat.com/en/blog/inception-how-usable-are-nest...

WSL1 is not a "real" VM. https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process...

Aside from all the other corrections, hardware virtualization support isn't necessary for virtualization.

We know how it would look like! Here is a nice illustration:

https://m.xkcd.com/1764/

That's a thing already: http://git.annexia.org/?p=supernested.git;a=summary

I tried following those steps and got this error:

https://www.betaarchive.com/imageupload/1299034742.or.31168....

Does anyone know of a workaround?

To tie this back to Wine, here is what we actually do during some parts of the Proton[1] build process: Run a Debian 9 VM, inside of which we run an Ubuntu 12.04 Docker container (the Steam runtime), which runs an Arch Linux chroot in order to gain a modern cross-compiler. It's a doozy[2]!

[1] Proton is Valve's fork of Wine which ships with the Linux Steam client.

[2] https://github.com/ValveSoftware/Proton/commit/d68e71bed61c8...

May I ask why you need that many distributions? It really looks interesting.

Debian 9 for the Vagrant VM, because it was modern at the time (probably upgrading it to Debian 10 soon). Ubuntu 12.04 because that's what the Steam runtime uses, because it was modern at the time and upgrading while maintaining binary compatibility is Hard. Arch Linux because building a modern cross-compiler on Debian/Ubuntu is Hard.

What, did you want good reasons? :)

Out of curiosity, since you might know: is Proton upstreaming changes or are they going their separate ways?

I'm not informed enough to say whether the fork made sense or not, but my immediate reaction was that using a OS project with immense man hours and effort behind it for commercial gain without contributing back would be very ... questionable.

Yes, of course. Valve is a very good open source citizen. The fork was necessary because we have a fair number of changes that are not appropriate for upstream Wine. As a single example, we integrate closely with the Steam for Linux client for stuff like achievements and multiplayer, which obviously can't go upstream. I'm actually the guy who does the rebases, so I'm very motivated to keep the diff as small as possible :) You might find this article from March interesting: https://www.codeweavers.com/about/blogs/aeikum/2019/3/27/how...

Thanks, that's great to hear!

Thanks for the amazing work you guys are doing! I'm keeping an eye on the progress and it's amazing to see: https://boilingsteam.com/proton-keeps-making-its-way-in-comp...

Have you seen The Birth and Death of Javascript? https://www.destroyallsoftware.com/talks/the-birth-and-death...

> Now that installing wine in Linux on windows is possible, the next step becomes clear. We must compile and run cygwin on wine in Linux on Windows.

That would be so awesome! :)

If you are a desperate bastard like me, you can install it with Windows build 18917 as described here : https://devblogs.microsoft.com/commandline/wsl-2-is-now-avai.... Caveat: I have not done it, but hopefully will do it during the weekend.

Exactly. I used a similar approach to install Space Empires III on a Windows 10 x64 machine which would not run its 16bit installer but would run the 32bit game itself just fine.

Does WSL work on wine ?

Maybe by using qemu? (Windows on qemu on Wine on Linux on Windows)

No. WSL is a part of the NT kernel (part of their modular architecture, quite cool to read about) and can't be replicated with an alternative program loader like Wine. You'd need to run a whole new copy of the kernel to get a second instance of WSL, which can already be done through virtualization.

Nope. WSL is basically a reimplementation of the Linux kernel's syscall layer (or at least the original version of it was - WSL 2 is an actual Linux kernel running in a VM). If you do a Linux syscall from within a Wine app it calls into the actual underlying Linux kernel and Wine itself makes heavy use of this within its libraries. WSL on Wine isn't possible and doesn't really make sense. I guess it might be possible to add support for WSL 2 since that's just a VM, but I'm not sure why you'd ever want to since it is just a VM.

This is why I think we will always be able to run all software ever, just keep on piling up older virtualizers (or api translators).

Reply on news.ycombinator.com