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

141–150 of 188 posts

Re: How Wine works 101

#141

Post by _piif »

goosedragons wrote: post #116
G3rn0ti wrote: post #95

> Wine has been in development for many years and came a long way. And still my daughter can't play "Sims 4" on her Linux laptop ... not because of the game itself but because of EA's pathetic program starter "Origin". Even Steam's Proton environment stopped working. So sad and frustrating. Isn't there a way to play this game without "Origin"? The mileage you get with Wine is highly dependent on the individual game.

Is this a recent change? I did have Mass Effect Legendary Edition (which was also through origin) up and running a few months ago thanks to Lutris. And I did get NFS Heat through Steam and it also boots up Origin and seems to work okay. I would check out Lutris if you haven't. The Sims 4 is popular and so someone helpfully created an install script to get it running with Lutris: https://lutris.net/games/the-sims-4/

I recently installed the Steam version (which in turn also installs Origin inside the prefix to run the game) and it ran just fine. Not sure what issue OP is hitting.

Re: How Wine works 101

#142

Post by inktype »

dt2m wrote: post #115
Underphil wrote: post #74

Earlier quoted context omitted.

I can only speak for myself, but I use it for loading VST plugins in Linux.

How do you do this specifically? Do you use some kind of bridging software or do you make a shim for each plugin that loads Wine on the fly?

Yabridge [1] uses wine to seamlessly load VST plugins into a host. It pretty much just works.

[1] https://github.com/robbert-vdh/yabridge

Re: How Wine works 101

#143

Post by G3rn0ti »

_piif wrote: post #141
goosedragons wrote: post #116

Earlier quoted context omitted.

Is this a recent change? I did have Mass Effect Legendary Edition (which was also through origin) up and running a few months ago thanks to Lutris. And I did get NFS Heat through Steam and it also boots up Origin and seems to work okay. I would check out Lutris if you haven't. The Sims 4 is popular and so someone helpfully created an install script to get it running with Lutris: https://lutris.net/games/the-sims-4/

I recently installed the Steam version (which in turn also installs Origin inside the prefix to run the game) and it ran just fine. Not sure what issue OP is hitting.

After my PlayOnLinux setup stopped working a long time ago after some Origin update (and several retries afterwards), we tried running the Steam version of the game using Steam's Proton environment and we could start the game only once and then it stopped working again. If you check protondb there seems to have been a regression two weeks ago.

The frustrating part is the game itself would be working like charm in Wine but the stupid launcher app keeps getting updated and is doing all kinds of complicated DLL and system calls although all it really needs to do with respect to "Sims 4" is to check your license and start the game.

So even if you get the game running for some time, ultimately, "Origin" will stop working one time or another.

Re: How Wine works 101

#144

Post by dontlaugh »

mgarstecki wrote: post #139
ghoomketu wrote: post #88

> Fifth, oh, did you want to run a game? Not just a hello world? Then you need to deal with DirectX, audio (hello PulseAudio, my old friend), input devices (gamepads, joysticks), etc. It’s a lot of work! These last paragraphs just made me realise how grateful I am to people who work on these open source projects without expecting any compensation or even praise for their work. It has happened once or twice that I tri…

And let's not forget to be grateful towards for-profit companies that contribute to open source. A lot of the work required to get games working transparently on Wine was thanks to Valve, who released Proton as open source, along with heavy work on DXVK to simulate DirectX, etc. Of course they did it because it benefits them, but still they could have kept it private and it would have boosted only Steam sales. Instea…

They couldn't have kept it private easily, since Wine is licensed LGPL.

Re: How Wine works 101

#145

Post by justsomehnguy »

BlueTemplar wrote: post #104
justsomehnguy wrote: post #52

Earlier quoted context omitted.

In 2016 I was asked to install some software on a WinSvr2012R2. I was forced to install it on my Win8.1 tablet first, because the 16-bit stub didn't work on x64 2012R2. After install I copied the files to the server and the software brazenly showed "XXX for Windows 95" in the Help->About. On a 2012R2 x64 server. In the year 2016. There was (and is) a lot of shit which developers did wrong ( including writing directly…

Yeah, I have Windows 98 in a VirtualBox for those 32 bit programs using a 16 bit installer...

Hah!

That's even better (and you can have snapshots and all benefits of VM), but in case you don't know - for InstallShield stubs there are replacements which allows the installer to run on WOW64 systems.

Re: How Wine works 101

#146

Post by arminiusreturns »

ntauthority wrote: post #113
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…

A more interesting variant of your question would be 'how come Wine is better at running decades-old Windows software (on systems such as Linux) than Linux is at running decades-old Linux software on Linux?' ... perhaps Win32 is a more stable ABI/API by design.

It may be time to reconsider recompiling from source as the preferred method over binary distribution.

Re: How Wine works 101

#147

Post by asveikau »

Matl wrote: post #128
asveikau wrote: post #66

Earlier quoted context omitted.

> but it's very early I thought I remember hearing about the project a long time ago. First commit of README is 2012.

Sorry, I meant early as in much is still not implemented, no GUI support etc. not as in the project is new.

It's just a little strange because GNUstep had a good chunk of AppKit already implemented before they even started. Why didn't they use more of that?

Re: How Wine works 101

#148

Post by ChuckNorris89 »

AshamedCaptain wrote: post #130
ChuckNorris89 wrote: post #83

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. Mate, I played Red Alert 2 off the original 1999(?) ISO last month on my Windows 11 installation. I had to copy some missing deprecated Direct Draw DLLs that don't ship with modern Windows anymore and everything worked. If you would have Googled the issue, you would have found tons of forum…

You just can't claim that Windows has "backwards compatibility" if you have to "Google" for it. In a recent article about Linux backwards compatibility, I pointed out that OSS support was terrible, which meant that many games would no longer run out of the box even if statically linked (actually, static linking made the problem harder). It doesn't matter that lack of OSS is a trivially fixable problem (much easier th…

>You just can't claim that Windows has "backwards compatibility" if you have to "Google" for it. [...] One can excuse it however one sees fit but this shows that Windows has lost the backwards compatibility edge that it may once had.

I completely disagree with your line of thinking. If modern Windows would have shipped with all possible legacy DLLs, ancient visual C++ libraries and DirectX versions needed for running every possible 20+ year old piece of software, then everyone would claim windows is unnecessary bloated. Would you even want such bloat by default on all installations just for the handful of users who need to run 20+ year old software?

The current situation is a good compromise between compatibility and bloat.

Windows 11 can run 20+ year old software natively without virtualization but it's up to you to separately download the deprecated legacy DLLs that your 20+ year software requires. Also, looking at it relative to competition from Apple, it's incomparably better at backwards compatibility than MacOS. And Xbox is also better at emulating the 360 era games on the modern systems than Sony is at emulating the PS3.

Re: How Wine works 101

#149

Post by Shared404 »

pansinghkoder wrote: post #35

Counterstrike represent! I'd love to see popularity breakdown of applications run by wine. What else do people use it for?

When gaming, I've been convinced to pretty much live in Steam/proton. I also use a few games through Lutris.

I don't use it much for productivity tools, as I've been full time on Linux long enough that I generally prefer the native tools. On the rare occasion I need a windows only software, I usually just spin up a VM.

Re: How Wine works 101

#150

Post by ntauthority »

arminiusreturns wrote: post #146
ntauthority wrote: post #113

Earlier quoted context omitted.

A more interesting variant of your question would be 'how come Wine is better at running decades-old Windows software (on systems such as Linux) than Linux is at running decades-old Linux software on Linux?' ... perhaps Win32 is a more stable ABI/API by design.

It may be time to reconsider recompiling from source as the preferred method over binary distribution.

This would be fine if not for even the canonical C/C++ compiler on GNU/Linux having issues building older versions of itself without patches, let alone other applications.

As with older Windows binaries on newer Windows versions, when it doesn't work outright, there's always fixes - but that's not the point this subthread tries to discuss.

Post reply on HN