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

How Wine works 101

werat.dev

Post reply on HN
Print view View original

71–80 of 188 posts

Re: How Wine works 101

#71

Post by smoldesu »

monocasa wrote: post #67
Arainach wrote: post #64

Earlier quoted context omitted.

[[Citation Needed]]. Other than 16-bit software on 64-bit Windows, do you have an example?

A lot of games, Red Alert 2 off the top of my head. Never got it running even in compatibility mode and changing the bit depth.

I hate to be the "works on my machine" guy, but there seem to be multiple reports of it running perfectly fine: https://appdb.winehq.org/objectManager.php?sClass=applicatio...

However, I sympathize with the general funkiness of running old games. It's very difficult to play the original Diablo 2 through Wine unless you emulate a virtual desktop, which is frustrating to set up. If you're willing to give it another try, the Lutris script should handle almost everything needed to configure it right: https://lutris.net/games/command-conquer-red-alert-2/

Re: How Wine works 101

#72

Post by nomel »

retrac wrote: post #28
nine_k wrote: post #15

Earlier quoted context omitted.

The point of Wine is to run older Windows software. Who needs the most modern versions, just pays for MS Windows. Windows, like DOS before it, adapts to run certain apps more efficiently, to sidestep their bugs, or to fulfill their assumptions which generally do not hold. I suppose Wine does a lot of the same. It pays a lot of attention tp running old(er) popular software smoothly. I suppose Wine has more adjustments…

Basically, I don't want to run Windows. But I do want to run some current Windows software -- mostly games and design tools. I don't think I'm a major exception; I wonder if there have been any surveys. Linux users who want to run current Windows software are likely much of the user base. Lately I've been playing a recent DirectX 11 game via Wine. Worked out of the box. I think it might be a bit slower than under Win…

What game is this? I haven’t seen a modern title, or monitor, capped to 60fps in over a decade. I think most mobile games go higher, these days.

Re: How Wine works 101

#73

Post by smoldesu »

amelius wrote: post #8

Any WINE-like projects out there but for MacOS/iOS (as opposed to Windows)?

There's probably not that much interest in getting MacOS software running on Linux, especially now that they're going the ARM route. Windows was always a promising platform because it was ludicrously stable and had loads of crazy software and games on it. The risk/reward was high, but relatively low compared to doing this with Apple software. Plus, all this would be a whole lot of work to get a janky version of a non-native program. Most people who already daily-drive Linux probably don't miss the MacOS version of Twitter, or some weird native git client.

Re: How Wine works 101

#75

Post by monocasa »

smoldesu wrote: post #71
monocasa wrote: post #67

Earlier quoted context omitted.

A lot of games, Red Alert 2 off the top of my head. Never got it running even in compatibility mode and changing the bit depth.

I hate to be the "works on my machine" guy, but there seem to be multiple reports of it running perfectly fine: https://appdb.winehq.org/objectManager.php?sClass=applicatio... However, I sympathize with the general funkiness of running old games. It's very difficult to play the original Diablo 2 through Wine unless you emulate a virtual desktop, which is frustrating to set up. If you're willing to give it another try…

All of your citations seem to be Wine focused. I said that it works well enough under Wine; it's later Windows versions that don't run it well.

Re: How Wine works 101

#76

Post by aargh_aargh »

outworlder wrote: post #25
nine_k wrote: post #15

Earlier quoted context omitted.

The point of Wine is to run older Windows software. Who needs the most modern versions, just pays for MS Windows. Windows, like DOS before it, adapts to run certain apps more efficiently, to sidestep their bugs, or to fulfill their assumptions which generally do not hold. I suppose Wine does a lot of the same. It pays a lot of attention tp running old(er) popular software smoothly. I suppose Wine has more adjustments…

> just pays for MS Windows. Paying for MS Windows is not a problem. If I could just throw money at Microsoft and have all the apps I need running on Linux, I would have. I suspect many people (and specially orgs) would have done that too. Incidentally, I have a copy of MS Windows. I just _don't want to boot Windows_ > It pays a lot of attention tp running old(er) popular software smoothly. Nah. It pays attention to p…

> Incidentally, I have a copy of MS Windows. I just _don't want to boot Windows_

Might be incidental in your case, but not in general:

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

Re: How Wine works 101

#77

Post by tarsinge »

spoonjim wrote: post #34

I thought I was going to get an explanation of why so many guys pay tons of money for fermented grape juice that tastes worse than just regular grape juice.

Paying tons on money is indeed silly, but if you think it tastes worse you have a sugar dependency problem.

Re: How Wine works 101

#78

Post by LtWorf »

keithnz wrote: post #32
haunter wrote: post #6

What I'm curious about (and probably there are some good write ups about this somewhere) that how come modern Linux and modern Wine is better to run old Windows applications than modern Windows (7 to some extent but mostly 10&11). Did MS "intentionally" "left behind" certain APIs and system calls to sacrifice it for some greater good? Like I use Windows every day and have no problems at all. And I use Linux every day…

what old windows programs from Vista/XP/2000 can't you run on Windows 11? It has "compatibility mode", just select properties on the program and select compatibility, and select the OS you want.

Anything with directx won't work (or will work so slow to be unplayable).

Re: How Wine works 101

#79

Post by signaru »

bee_rider wrote: post #55
haunter wrote: post #6

What I'm curious about (and probably there are some good write ups about this somewhere) that how come modern Linux and modern Wine is better to run old Windows applications than modern Windows (7 to some extent but mostly 10&11). Did MS "intentionally" "left behind" certain APIs and system calls to sacrifice it for some greater good? Like I use Windows every day and have no problems at all. And I use Linux every day…

It is apparently possible to run Wine on WSL. https://liliputing.com/wine-on-windows-lets-you-run-windows-... I wonder if you can run Cygwin on it.

Wine on Windows is technically interesting, even if others might argue that it's pointless. At the very least, these are also good tests of how much compatibility the layers provide.

There's also WineVDM that actually solves a "need" to run 16bit Windows programs on 64bit Windows. I've considered using it for retro programming without leaving a modern OS, although DosBox may be a more reliable option. Now, if Win32s can get to work on top of WineVDM, that would be funny.

Re: How Wine works 101

#80

Post by rcoveson »

kgeist wrote: post #70
monocasa wrote: post #67

Earlier quoted context omitted.

A lot of games, Red Alert 2 off the top of my head. Never got it running even in compatibility mode and changing the bit depth.

According to Raymond Chen, this usually happens when software relies on undocumented APIs or undefined behavior. When Windows removes undocumented APIs or changes behavior not covered by the documentation, such apps break and people blame Microsoft. For example, I remember one app used to programmatically find some kind of "Print" menu in Windows' desktop environment and call it to implement printing functionality. W…

If your plan is to maintain decades of backwards compatibility with software from thousands of third parties, it's going to involve maintaining some originally-undocumented behaviors that people exploited. That's what the wine developers got themselves into willingly, and it's what the Windows devs are increasingly shirking.
Post reply on HN