WSL is VM. So it's pretty pointless to run application on Linux VM emulating WinAPI, indeed. But at least you don't need to care about licenses, that might be one reason.
IIRC the NT kernel can run multiple kernels-or-something side by side. It could probably be used to co-run Linux kind of like CoLinux does.
IIRC also, MS can use the Windows HyperV infrastructure to run the Linux kernel too, like they do on Xbox One to segregate games "Exclusive" OS from apps "Shared" OS. In that sense it won't be user mode either like user-mode linux is.
First and foremost, security. Also convenience - no need to mess around with shared folders, NAT-based VM networking, OS updates, user accounts/passwords etc.
It's not just for business, it's also relevant for old games fans - and will become ever more important for those of us who refuse to buy the "new" games that require a whole ssd for space, are plagued with drm and bugs and to top it off are pay2win upon paying 40€+.
But there is a reasonable motivation. Some old games and some other software often don't run well on modern Windows (or sometimes at all). It can be possible to patch them to work but not always and even this relies on motivated and talented fans.
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.
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.
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.
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.
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.
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.
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...
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).
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.
> 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 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.
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).
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.
I feel like it would be useful to add "(using WSL)" to the title.
I admit I would not have opened the link though, had the title spoiled this part of the story, and the article is funny to read.
> Running Wine on Windows has been a fever dream of those responding to the siren call of "we do what we must, because we shouldn't" since at least 2004, when someone tried compiling Wine in Cygwin and trashed the registry of the host system.
[…]
> But I want to stress again: this now works trivially. I'm not some sort of mad genius to have done this thing — I only appear to be the first person to admit to it in public.
Well, you are right but I expected to find an article speaking about Wine running on native Windows without WSL, which would make it interesting in another way.
I would not expect Wine not to run on WSL. What I learned from the article though is that WSL1 does not run 32 bit binaries (and that someone botched their registry trying to run Wine on Windows back in 2004, which I found funny).
> Well, you are right but I expected to find an article speaking about Wine running on native Windows without WSL
While it isn't all of Wine, it is a fairly well-known usecase to build certain Wine modules and run those on Windows. It's been used to support ancient games that depend on certain old quirks that have changed in more recent Windows. It's also used by graphics driver developers, because Wine's implementation works on both Windows and Linux, so they can study differences at the driver level on both platforms.
I think Wine is what solidified this belief even further when we see some elaborate Wine configs out there going on about specific versions of Wine working best with specific programs. The backwards compatibility of Windows is unrivaled at least with Wine. Not sure if ReactOS is a solid exception.
No, the funniest thing would Microsoft making Windows 11 a Linux distro with a custom version of WINE running ontop of it so that they need to maintain way fewer parts of their operating system themselves.
When people say 'Linux' in reference to WSL1, it's a Linux Kernel API emulation layer on top of the Windows kernel that ships with Windows. The user-mode stuff on top of that is regular Ubuntu or whatever, but you can argue that Wine is running on Windows, it's just speaking the Linux system call language and using some user-space linux libraries instead of win32 libraries.
The Windows kernel is a true micro-kernel, unlike the monolith of Linux, and the Frankenstein mess of Mac "OS". Different API subsystems can run on top of it. There used to be a supported POSIX subsystem.
No, WSL 1 was an actual kernel layer. WSL 2 actually is a real Linux kernel on top of a VM but with some extra bits to integrate nicely with the Windows side of things.
> Correct me if I'm wrong, but this is running Wine on Linux on Windows. Not running Wine on Windows.
Technically speaking Wine is running on a emulated Linux-kernel (WSL1), just like Windows-programs under Wine is running on an emulated Windows-kernel.
This would be awesome...I have a bunch of old games that broke when I went to 64-bit Windows. Plus, VMware support for older OSes seems to be getting worse, so that's a less and less viable route.
Have you not tried VirtualBox instead? Never really had many issues with VB. Course it depends on what games too. Windows 10 does have compatability mode as well which can be useful.
If you're not averse to "sailing the high seas", so to speak, the ISOs are readily available online and don't require activation to be fully usable (as long as you're able to tolerate the Windows activation nag watermark and the lack of theme personalization, though I'm sure there are ways to "fix" both of those).
> We currently have no plans to deprecate WSL 1. You can run WSL 1 and WSL 2 distros side by side, and can upgrade and downgrade any distro at any time.
I find it unlikely MS will keep it definitely, and with no continued development effort it will become less compatible with new Linux distros, and thus diminish in utility over time.
"The excuse is 'what about ancient applications that don't run properly in recent Windows.' But you know the real reason is 'I suffered for my art, now it's your turn.'"
There are some older apps that just work on WINE and little else. I have an old Garmin GPS simulator used in some of the planes I fly. Would run on XP64, but Window 7+ could not mimic the settings well enough to get it to work even with the compatibility mode set. Ironically, this old bit of software still runs on my Linux box as it does something legacy correctly.
Too bad Microsoft chose to name their solution "WSL". If they'd have named it Line (Line Is Not an Emulator or LINux Emulator) then we could have called this Wine onLine!
Yep. The easiest way to get some older games working on Windows 10 is already to copy the Wine version of DLL files they rely on into the game directory; this just goes all the way.
I wish I could play the old spider solitaire, not the new one. The new one is not free and has micro transactions. That's pretty sad. I'm sure it's not even possible to find the old exe. There are js equivalent but none are really worth it.
PySol is a free download with spider and about 1,000 other solitaires, including mahjong. My only complaint is the tilesets could be a bit clearer conveying height for mahjong. Surprisingly small too.
If MS is now serious about cross-platform compatibility (and they have been moving in that direction), they should consider building a bridge over the filesystem divide as well. One or more of these would be useful:
- Shipping a ext4 filesystem driver for Windows.
- Contributing to exfat/ntfs drivers for Linux/Mac OS.
Allegedly WSL2 allows you to access things in the WSL file system from plain Windows programs. In 5 minutes of experimenting I could not get a JetBrains IDE to work on a project stored in the WSL filesystem. You can at least use Windows explorer now though.
I use WSL just about every day and I'm very optimistic about its future.
134 comments
[ 2.8 ms ] story [ 183 ms ] threadIIRC also, MS can use the Windows HyperV infrastructure to run the Linux kernel too, like they do on Xbox One to segregate games "Exclusive" OS from apps "Shared" OS. In that sense it won't be user mode either like user-mode linux is.
My bet is on the latter.
https://en.wikipedia.org/wiki/Architecture_of_Windows_NT
https://en.wikipedia.org/wiki/Xbox_One_system_software
https://en.wikipedia.org/wiki/Cooperative_Linux
https://en.wikipedia.org/wiki/User-mode_Linux
I don't believe this is a good business strategy.
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.
Further recursion WINE => Cygwin => WINE however will not require more nesting of hypervisors.
https://www.linux-kvm.org/page/Nested_Guests
https://communities.vmware.com/docs/DOC-8970
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.
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-w...
https://www.redhat.com/en/blog/inception-how-usable-are-nest...
https://m.xkcd.com/1764/
https://www.betaarchive.com/imageupload/1299034742.or.31168....
Does anyone know of a workaround?
[1] Proton is Valve's fork of Wine which ships with the Linux Steam client.
[2] https://github.com/ValveSoftware/Proton/commit/d68e71bed61c8...
What, did you want good reasons? :)
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.
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
> 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.
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.
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.
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.
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?
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.
Should not be a problem, seems user has been digging for Exile since he was 12
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?
He's still making games, and they're still pretty much the same games they were--and to me that is a positive.
That would be so awesome! :)
I admit I would not have opened the link though, had the title spoiled this part of the story, and the article is funny to read.
> Running Wine on Windows has been a fever dream of those responding to the siren call of "we do what we must, because we shouldn't" since at least 2004, when someone tried compiling Wine in Cygwin and trashed the registry of the host system.
[…]
> But I want to stress again: this now works trivially. I'm not some sort of mad genius to have done this thing — I only appear to be the first person to admit to it in public.
I would not expect Wine not to run on WSL. What I learned from the article though is that WSL1 does not run 32 bit binaries (and that someone botched their registry trying to run Wine on Windows back in 2004, which I found funny).
While it isn't all of Wine, it is a fairly well-known usecase to build certain Wine modules and run those on Windows. It's been used to support ancient games that depend on certain old quirks that have changed in more recent Windows. It's also used by graphics driver developers, because Wine's implementation works on both Windows and Linux, so they can study differences at the driver level on both platforms.
What's the advantage of it versus running Ubuntu in a VM and using putty?
The procedure to use 32-bit under WSL-1 is the following:
register 32-bit elf magic to be executed through qemu-i386-static: reload binfmt: and it executes x86 elf on WSLMore info on this technique here: https://stackoverflow.com/questions/42120938/exec-format-err...
I have always thought it was some kind of "low level" VM. Based on your comment, it's more like a Frankenstein monster...
Technically speaking Wine is running on a emulated Linux-kernel (WSL1), just like Windows-programs under Wine is running on an emulated Windows-kernel.
So yeah. Turtles all the way down.
Brilliant!
not just qemu-user, but telling it the magic numbers for binfmt to work
I'll give it a spin when I get home this evening. ENCARTA 97 SHALL RIDE AGAIN, maybe
https://stackoverflow.com/questions/42120938/exec-format-err... (second answer)
sudo apt install qemu-user-static
sudo update-binfmts --install i386 /usr/bin/qemu-i386-static --magic '\x7fELF\x01\x01\x01\x03\x00\x00\x00\x00\x00\x00\x00\x00\x03\x00\x03\x00\x01\x00\x00\x00' --mask '\xff\xff\xff\xff\xff\xff\xff\xfc\xff\xff\xff\xff\xff\xff\xff\xff\xf8\xff\xff\xff\xff\xff\xff\xff'
sudo service binfmt-support start
And now we can do:
> fun@DESKTOP-7F6DU8P:~$ wine --version
> wine-3.0 (Ubuntu 3.0-1ubuntu1)
Encarta 97 doesn't install, though:
> fun@DESKTOP-7F6DU8P:/mnt/e$ wine SETUP.EXE
> wine: Unhandled page fault on read access to 0xffffffff at address 0x11df:0x00002c11 (thread 0011), starting debugger...
> 0011:err:seh:start_debugger Couldn't start debugger ("winedbg --auto 15 108") (2)
> Read the Wine Developers Guide on how to set up winedbg or another debugger
I'll leave that bit to someone who knows what they're doing.
and continues to fail in Wine 4.13 on Windows 10 with qemu doing the win32 bits
Am curious how an individual would get access to Windows 10 Enterprise.
https://docs.microsoft.com/en-us/windows/wsl/wsl2-faq
[0] http://dege.freeweb.hu It's an http-only website, don't be alarmed by warnings.
"The excuse is 'what about ancient applications that don't run properly in recent Windows.' But you know the real reason is 'I suffered for my art, now it's your turn.'"
Too bad they didnt call it Windows Services Toolkit for Unix.
Why should anyone do that? The only reason I see is possibly to use win 98, 2000, XP, ... programs under win 10.
https://pysolfc.sourceforge.io
- Shipping a ext4 filesystem driver for Windows.
- Contributing to exfat/ntfs drivers for Linux/Mac OS.
Both would be even better.
I use WSL just about every day and I'm very optimistic about its future.