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.
Using it not only any 16bit installer works, but also most 16bit applications. As an example you can play Exile by Spiderweb 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).
> 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.
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.
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.
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?
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.
 Proton is Valve's fork of Wine which ships with the Linux Steam client.
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.
What, did you want good reasons? :)
Does anyone know of a workaround?
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.
Further recursion WINE => Cygwin => WINE however will not require more nesting of hypervisors.
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.
Physics is like sex: sure, it may give some practical
results, but that's not why we do it.
- 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.
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
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
Too bad they didnt call it Windows Services Toolkit for Unix.
Am curious how an individual would get access to Windows 10 Enterprise.
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.
It's an http-only website, don't be alarmed by warnings.
The procedure to use 32-bit under WSL-1 is the following:
enable i386 architecture
$ 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
More info on this technique here: https://stackoverflow.com/questions/42120938/exec-format-err...
What's the advantage of it versus running Ubuntu in a VM and using putty?
"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.'"
Why should anyone do that? The only reason I see is possibly to use win 98, 2000, XP, ... programs under win 10.
I don't believe this is a good business strategy.
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.
My bet is on the latter.
Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform