Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wine on Windows 10

reddragdiva.dreamwidth.org

Post reply on HN
Print view View original

61–70 of 135 posts

Re: Wine on Windows 10

#61

Post by krylon »

jeroenhd wrote: post #4

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.

> 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! :)

Re: Wine on Windows 10

#62

Post by mikekchar »

kevingadd wrote: post #58
Phenix88be wrote: post #28

Correct me if I'm wrong, but this is running Wine on Linux on Windows. Not running Wine on Windows.

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.

So I guess WSL1 is a bit like linux flavoured wine :-)

Re: Wine on Windows 10

#63

Post by merubin75 »

This made me laugh out loud. Sooooo true.

"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.'"

Re: Wine on Windows 10

#64

Post by Phenix88be »

kevingadd wrote: post #58
Phenix88be wrote: post #28

Correct me if I'm wrong, but this is running Wine on Linux on Windows. Not running Wine on Windows.

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.

> When people say 'Linux' in reference to WSL1, it's a Linux Kernel API emulation layer on top of the Windows kernel

I have always thought it was some kind of "low level" VM. Based on your comment, it's more like a Frankenstein monster...

Re: Wine on Windows 10

#65

Post by hollerith »

utouq wrote: post #57
TazeTSchnitzel wrote: post #55

It's a shame WSL will be replaced soon with WSL2, which is a mere virtual machine and not native support for Linux binaries.

LTSC 2019 contains the WSL and is supported until January 9, 2029

Isn't that short for "Windows 10 Enterprise LTSC 2019"?

Am curious how an individual would get access to Windows 10 Enterprise.

Re: Wine on Windows 10

#67

Post by makomk »

julienfr112 wrote: post #6
jeroenhd wrote: post #4

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.

Does WSL work on wine ?

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.

Re: Wine on Windows 10

#68

Post by cambalache »

jeroenhd wrote: post #4

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.

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.

Re: Wine on Windows 10

#69

Post by aasasd »

Danieru wrote: post #12
cyborgx7 wrote: post #7

Earlier quoted context omitted.

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.

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

Re: Wine on Windows 10

#70

Post by Crinus »

codetrotter wrote: post #30
Crinus wrote: post #25

Earlier quoted context omitted.

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/ot…

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…

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.

Post reply on HN