How Wine works 101
werat.dev
werat.dev
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 tried running something in Wine and it just wouldn't work which made me a little annoyed.
But reading how complex and difficult it is to make such things happen I am surprised the amount of effort it takes to even make Notepad.exe work!
I think it's reasonable to expect both, even if indirectly. Participating in a well-organized open source project confers extremely rich experience, and employers do take notice. In my company, the folks who spent time in the community generally noticeably out-perform the ones who grew up exclusively in industry (which should trouble industry) at similar years of experience. If you want to end up highly-compensated, it's a great way to spend your time.
The real challenge for the open source community is how hard it still is to make a living sticking to the original open source work, instead of taking your talent and leaving one day. Wine is one of a few exceptions with some companies in its ecosystem, but generally speaking there's not enough upstream-work jobs for a lot of important open source software infrastructure.
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. Instead it's a win for them AND for the community, an example that should be followed by other companies.
What a time to be alive indeed!
The outcome is still good for the community, but it doesn't mean Valve did it out of the kindness of their hearts.
Is Valve still just a company with profit as its main motive? Yeah, that's the point. But it can do helpful things as a side-effect.
The main sponsor of WINE is CodeWeavers, who have been paying folks that work on WINE for a very long time, and are involved in Proton development:
They sell a supported version of WINE for Linux, macOS and ChromeOS, as well as providing engineering services to clients like Valve.
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 to run Office 2003 without a hitch than Win 12 does. Same for older popular games.
Is this really true? What “newer” Windows software would not run under Wine “in principle”? (And, for that matter, what older Windows software wouldn’t run on Windows itself?)
But in short, no. Wine has a goal of running all Windows software, old and new.
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 popular software, period. Because that's how contributions normally work. The more people interested, the more likely a patch will land. It can take significant effort to run some software. That takes time. By the time it's running perfectly, it's "old" software.
It just needs effort. One of the bad things about the Stadia demise is that some of the work done on the titles themselves benefit Wine. For example, Cyberpunk was perfectly playable on launch day.
Might be incidental in your case, but not in general:
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 Windows natively, but that's sort of moot since it hits the cap at 60 fps either way. I've used Wine regularly for about 15 years. I used to be surprised when new software (especially DX-based) worked under Wine. These days, I'm more surprised when it doesn't.
MS are currently hell bent on getting you onto a cloud subscription for Windows as a service (WAAS) because that is their current business model. The Wine project is hell bent on delivering functionality that you want and they think you might want.
Wine is less about shuffling the start menu to the middle of the taskbar because ... err wankery that makes it harder to find and actually click or poke at and making copy/cut/paste into really odd little icons on right click menus (no idea what sort of poke gets the right click menu).
... Sorry, I'm not a fan of the W11 UI.
MS could not give a toss about you or your app (say an ancient db or a ancestor app). They need to generate profits and your old app ain't a profit centre.
Anyway, wine is able to do what you actually want your machine to do - keep an old treasured app alive and more.
Microsoft has historically put a huge amount of effort in (backwards) compatibility. Here's a famous example: https://arstechnica.com/gadgets/2022/10/windows-95-went-the-....
Related (sub) discussion on HN: https://news.ycombinator.com/item?id=13450160.
It's possible that they changed strategy recently, but there is a very long history of extraordinary (backwards) compatibility.
Your SimCity example was an easy win and yet more wankery. They have not put a huge amount of work in compatibility. MS have done just enough always and only enough. That is precisely what a large commercial business would do and they did.
To say they have done "just enough always and only enough" is massively underselling it to a level where it's basically wrong.
Everyone who has been following Raymond Chen's The Old New Thing blog for some time knows the massive, quite impressive, and at times even "unreasonable" seeming work to keep things compatible. Especially, but not exclusively, in the Windows 95 days. Quite possibly that has changed in the last few years or even decade (I wouldn't know), but at least the claim that they never put a huge amount of work into compatibility is just not true.
Here is just one of many articles that outlines some insanity that Windows did for compatibility, stuff where other OSes (including Linux, at least outside of the kernel) would have rightfully said that this software needs to be fixed instead: https://devblogs.microsoft.com/oldnewthing/20160404-00/?p=93... - I found this one randomly after a cursory search, there were other articles that may prove the point even more.
Raymond Chen did also state that the more things shifted to be "online", the more reasonable it became to let vendors fix issues with patches (often with MS's guidance) instead of doing insane tricks in the OS, but still: Credit where credit is due.
So yes, of course that was based on business and likely no other reason. People after all will certainly argue that at lot of the cruft makes things worse, not better; it took a long time to get rid of most of MS-DOS for one thing, and I bet there's still mountains of other ancient remnants that get in the way.
But to say that MS has not put "a huge amount of work [into] compatibility" is just distorting history. For better or for worse, compatibility seemed to have been one of the core principles for quite some time.
But the lengths to which Microsoft has historically gone to for backwards compatibility have been legendary - if decades-old internal corporate apps for which the source was lost 10 years ago don't work on the latest Windows, they don't get all that sweet upgrade license revenue. It's their bread and butter.
You're not wrong but we're in a whole new game these days.
There was (and is) a lot of shit which developers did wrong (including writing directly to C:\WINDOWS). Yet if they did stick to the basics (GDI output and so on) that worked for decades. I abandoned Corel PhotoPaint 3 (with (c) 1992) only after moving to Vista in 2008.
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.
Of course, this could all have been avoided with a proper universally understood spec like POSIX but it's too late for that now. (And POSIX never had graphics or sound support, which shows how big that project would be, with the churn of the PC hardware from 2D to 3D &etc)
The hardware is also starting to protest - no way to run 16 bit instructions in x86_64 mode on a 64 bit processor.
I think this is the price they are(were?) willing to take. If they don't take backward compatibility seriously. Windows won't exist now at first place.
Any pointers towards how to use this wrapper ?
This may have been the case, but it no longer is. DirectDraw and other _official_ APIs have been removed from Windows, providing no official replacement (other than the ones coming from Wine itself!), and leaving hundreds of programs in the dust.
The MS of Chen no longer exists. Or may have never existed... https://en.wikipedia.org/wiki/AARD_code
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/
I feel like I had issues with the original Diablo, however. Maybe that's what you meant?
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 and reddit posts explaining how to run it on modern Windows.
You can't expect modern Windows to ship 20+ year old DLLs that allow running Windows 98 APIs as that's a major security vulnerability since older APIs had direct hardware/memory access without any kind of checks and balances. But if you Google a bit, the workarounds for compatibility are available.
Also, a lot of games and apps in those days would basically "hack" Windows and hook into various process and drivers in non standard ways and use various undocumented APIs so it's no wonder they don't work in later versions of windows anymore regardless of the compatibility setting you use.
That doesn't make sense. If those old DLLs could bypass some security protections in Windows than that would be still a major vulnerability in recent Windows itself.
E.g., Wine ships other implementations of the same libraries and this causes zero extra security problems in Linux.
Because Windows malware can't infect Linux, so why would that be a security issue for Linux? But if you run Windows, you definetly don't want to sideload and use unmaintained libraries and APIs that are 20 years out of date.
To put it simply, it doesn't really matter what libraries you ship, they _cannot_ cause _new_ security issues in the operating system, by simple definition of user space.
And Windows malware can definitely infect Linux. That was not my claim.
Not really, search for UAC virtualization.
> My tax returns, my pictures, my passwords, all of the data I actually care about is stored in files accessible in user space.
So are the passwords of everyone logging in to this very website (stored in user space). I think you are confusing user/privilege separation with kernel-userspace separation.
You have not yet made a point. How can distributing a user-space shared library, no matter how fully loaded with ancient security holes, decrease the amount of security of your system?
We literally have this on Chen's today: https://devblogs.microsoft.com/oldnewthing/20221011-00/ Totally sure malware authors are going to compromise the files of an ancient game in order to trigger some bug in a library to get to your tax returns. No way they will not just change the game exec or something.
They probably want to put pressure on publishers to use newer libraries that don’t need administrative permission, so hopefully eventually getting a version of the program that doesn’t need admin. Encouraging better security hygiene.
I agree that user-space compromise is still really really really bad.
> I had to copy some missing deprecated Direct Draw DLLs that don't ship with modern Windows anymore and everything worked.
You literally had to copy the ddraw DLL from the Wine project, thereby solidly proving the OP's point: Wine has these days better compatibility than Windows.
> You can't expect modern Windows to ship 20+ year old DLLs
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.
By this logic, any operating system has perfect backwards compatibility, since you just have to fix whatever's broken ... even when the compatibility shims come from 3rd parties! Linux has perfect backwards compatibility, you just have to download this patched Gtk+ binary from this guy, etc.
Whatever the excuse is, they have dropped their backwards compatibility story. It was part of their official, published ABI, and now it isn't. All the excuses are as bogus as they are on any operating system. Apple also claims they drop backwards compatibility to avoid "bloat", but it is just that, an excuse.
And "bloat" is quite a bogus excuse, too, since it could for example offer to auto-download the required components like it does for previous .NET framework releases. Or even put an updated version on their download site (e.g. as with winhelp). Or just made it a Windows-independent redistributable (e.g. CRTs). One could have an argument if this was the case. (Apple did auto-downloads at some point). Yet here they just didn't care and 3rd parties like Wine had to come in fill the holes.
Not to mention this is not what people have in mind when they think "bloat"; after all, Wine manages to provide all these APIs and sizes at significantly less than a barebones Windows installation.
The issue with your logic is you only see things as black or white while, while backwards compatibility is various shades of gray, depending on factors that are mostly beyond Microsoft's control.
Modern Windows cannot account for all possible APIs, DLLs and hacks/workarounds that were used by every developer 20+ years ago, including non standard libraries and APIs, so of course you might need to download some missing DDLs regardless. Even if you use Wine, you could still have to do that to run Red Alert 2 or other such apps. That doesn't mean backwards compatibility does not exist, it means it's not a guaranteed 100% success rate out of the box, depending mostly on what libraries, APIs and hacks the original app developer employed.
And the excuses are not bullshit, but are a matter of money and return on investment and ratio of bloat plus freedom the app developers took at the time which isn't available on Modern windows for security reasons (Windows till and including XP was unsecure as f*ck, I don't think you want to have all those functions the developers of the time exploited, for better or worse, exposed in your modern installation of Windows just for 100% backwards compatibility).
Microsoft can't be expected to ship every single outdated and insecure 20+ year old DLL and undocumented API with every copy of Windows, which is a non issue as the last fifteen F-500 cooperate sys-admins in the world who still need to run 20+ year old corporate apps on modern windows will definitely have the knowhow to copy some DLLs they trust to C:/System32 so their crusty corporates app will work. It's not too hard, to copy some files, is it?
The 32 bit C++ executables I wrote in highschool for windows 95, still run right now on Windows 11 out of the box without any patches or issues. So backswords compatibility exists on windows live and well against your opinion that it doesn't. End of story.
> Microsoft can't be expected to ship every single outdated and insecure 20+ year old DLL and undocumented API with every copy of Windows,
This is not the point. The point is software using the _official API_ of that operating system. It's not about software which was using undocumented or 3rd party libraries. That's a strawman.
> And the excuses are not bullshit
They may not be bullshit, but they are literally valid for every operating system. I don't care what the argument is when my complain is that Windows is becoming worse in backwards compatibility than literally Wine itself.
> The 32 bit C++ executables I wrote in highschool for windows 95, still run right now on Windows 11 out of the box without any patches or issues. So backswords compatibility exists on windows live and well against your opinion that it doesn't. End of story.
And you started your argument about "black and white" vs "shades of gray"....
"My C++ executables run" is quite the low bar. I can also run my a.out executables from the 90s in Linux, and I'm assuming a similar level of compatibility with macOS . The Tcl files from my thesis in the 90s still work without a problem, too, even the GUI...
But I complained loudly when my Loki games stopped working on my Linux DE, and I complain loudly when my 2000s games stop working on Windows 8/10, and trying to justify this by saying "Security! Bloat! Tradeoffs" is as absurd on Windows as it is for a Linux desktop.
Personally I think compatibility has been a huge boon for Microsoft. If you need to throw everything away and start over, why would you stick with Windows?
Not by definition, but by "Dodge v. Ford Motor Co." [1] the Michigan Supreme Court case that held "A business corporation is organized and carried on primarily for the profit of the stockholders."
Here's the abstract from a fairly recent paper in the principal journal of the ABA's Business Law Section in which the case and its relevance today was discussed in detail:
This article examines Dodge v. Ford on its 100th anniversary. In Dodge v. Ford,
the Michigan Supreme Court held that a business corporation is organized for
the profit of its shareholders, and the directors must operate it in service to
that end. Despite the fact that Dodge v. Ford is rarely cited in judicial
opinions, the case continues to spark controversy in legal scholarship. There
is little justification for this scholarly attention because the factual basis
is little more than a caricature of Henry Ford, and subsequent developments in
corporate law have all but eviscerated the precedential value of the case.
Rather, the legacy of Dodge v. Ford may simply be that it serves as a
convenient talisman, standing for the one sentence anyone actually cares about
and rolled out with each new battle in the war between shareholder profit
maximization and corporate social responsibility.
Some people are not aware that this was not always taken for granted, but has been the topic of court cases in the past.
What definitions are you using here?
Haven't they been contracted by Valve to work on Proton?
Wine "only" has to run apps and nothing else. The older APIs are the most battle-tested and optimized. On the other hand, you may find suboptimal behavior on newer APIs that weren't exercised enough.
When the compatibility mode doesn't help, then what's a mere mortal to do?
[1] https://printplanet.com/threads/can-apogee-works-on-windows-...
You can get better translation/emulation libraries that you can swap in to an application, like dgVoodo2 that can improve things hugely (but unfortunately buggy with some games). I think Wine's translation is also much better than Microsoft's for these older DX versions.
Is it? I fail to see a justification for accepting the premise of your question.
> Like I use Windows every day and have no problems at all. And I use Linux every day too for work. But by my experience if I come around an old Windows application (Vista, XP, 2000 or before) then I probably have a better chance to run it as it meant to be on Linux w/ Wine than on Windows 10/11
https://liliputing.com/wine-on-windows-lets-you-run-windows-...
I wonder if you can run Cygwin on it.
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.
https://gitlab.winehq.org/jhol/wine/-/commits/msys2-hacks-7/
There's a few low level issues to solve, but also theres bunch of patches around that never made it upstream that just need some love to get them up to standard.
At this point Msys2 installs, we can run bash and install software using pacman (- with workabouts for varies janky problems).
... perhaps Win32 is a more stable ABI/API by design.
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.
https://news.ycombinator.com/item?id=24120066 (August 2020, 64 comments)
looking forward to this. every attempt i've made to debug a misbehaving program in wine has left me extremely frustrated with the debugger
I like to play old games. And I like to drink old grape juice.
I thought I remember hearing about the project a long time ago. First commit of README is 2012.
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.
PS. I downloaded the cracked copy, and deleted it before 24 hours, which makes it legal where I live (Poland). Also I own a physical copy of that game, but I couldn't be bothered to get Origin to run.
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:
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.
I actually kind of loath constantly updating single player games. It usually breaks my working install.
Please somebody make wine-making 101
...and as an aside, the comments about the alcoholic beverage really suggest that they should've kept it named WINE (all uppercase).
Worth noting that this only applies to WSL1; WSL2 works in a completely different way.
I was very glad when they announced WSL2 and while still using WSL1 for running socat for port forwarding, not missing it lack of further development much. Could be I'm missing some productivity stuff there?
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.
Also, why link to wine-mirror on GitHub instead of Wine's own gitlab instance?