> 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 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!
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. Instead it's a win for them AND for the community, an example that should be followed by other companies.
All the more reason for praise; usually that license is understood by corporations to mean "don't even think about it". Not only did Valve get what they needed out of it, the community benefited as well. Seems commendable to me.
Yes, because their business profited from that. It's an example in favour of GPL licenses: the interests of the public and of a for-profit venture aligned to produce value for both.
So capitalism functioned how it should, and a company wasn't a greedy douchebag. Still seems commendable to me. They had a choice. Their choice was to do what most companies do, and ignore barely-enforceable licensing; or to give back. They chose the better route.
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.
I believe the vast majority of people who work in Open Source graphics are actually employed to do so. There are very few people working without compensation, and once they do a handful of meaningful contributions they get offered jobs. We should be actually thankful to the for-profit companies sponsoring those people instead of investing in more closed-source stuff (Intel, AMD, Collabora, Igalia, Red Hat, Code Weavers, VMware, and a few dozen of others I am missing, heck even NVidia contributes to Open Source graphics, although not as much as we would like them to).
> 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.
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.
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 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
MS are profit motivated (by definition) and Wine is functionality motivated (again by definition).
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.
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 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.
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. When Microsoft changed the UI of the desktop (shuffled the menu items around) the app broke and people immediately blamed Microsoft, even though the app is to blame because the exact location of the menu item was never supposed to be a public contract. If an app is a widely used one, Microsoft usually used to create "shims" which detected funky behavior like that and corrected it to make the app work again. I think they don't do it anymore after Windows 8, that's why apps started breaking more frequently.
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.
It's a question of priorities. Microsoft must have realised these edge cases were slowing development down and how many people really want to run a game or a CD burner software from 1998?
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.
You can run 16 bit code in long mode just fine. It's just a different GDT entry like 32 bit code is. Windows didn't cut 16 but mode because of the processor ut because they took the opportunity to increase the max HANDLE table size greater than 16 bit code can address.
Just want to point out that not all 16-bit code can run unhindered in long mode. You can run 16-bit protected mode code. But long mode dropped the V8086 mode that made easily emulating 16-bit real mode possible.
But you can switch in and out of long mode, so it is also possible to basically do whatever you want. And you also have hardware virtualization. It is a political decision to drop compatibility for 16 bit Windows and DOS (i.e. it was too much programming effort), don't blame the hardware.
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.
> According to Raymond Chen, this usually happens when software relies on undocumented APIs or undefined behavior.
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.
DirectDraw has been deprecated for a long time, but it's still there, and it still works. I regularly run games using it on Win11, e.g. https://triumph.net/ageofwonders (1999)
Most old games do not work because of old graphics apis. Wine emulates these apis on top of modern graphic apis. Windows users usually need to use wrappers, or wined3d from wine.
Thanks a lot, but d3d8 and d3d9 seemingly have no effect, while ddraw fails with "The procedure entry point DDKMTOpenAdapterFromLuid could not be located in the dynamic link library gdi32.dll.", then game's mandatory launcher does open, but then an access violation when trying to launch the game itself from it...
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/
>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 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.
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 that having to fish for libraries), it still means Linux is _not_ backwards compatible.
> 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.
>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.
> The current situation is a good compromise between compatibility and bloat.
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.
>By this logic, any operating system has perfect backwards compatibility, since you just have to fix whatever's broken
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.
> 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,
> 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.
> 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.
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.
No; the point is that if a USER SPACE library can compromise the security of Windows the operating system _in any way_ then that by definition is a Windows issue, not an issue of the library.
E.g., Wine ships other implementations of the same libraries and this causes zero extra security problems in Linux.
>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.
Why would be sideloading an "unmaintained library" be a security issue for Windows ?
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.
Old games require being run as Administrator. In addition, user/kernel isn't the important security boundary you think it is. My tax returns, my pictures, my passwords, all of the data I actually care about is stored in files accessible in user space.
> 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.
> 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?
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 read somewhere (probably Raymond Chen's blog) that there were different camps at Microsoft. One recognized that backwards compatibility was a very powerful feature. The other thought that there had to be a limit, infinite compatibility was too great a tax to pay forever. The camps have traded power and influence over the years.
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?
And the pendulum will swing back. In a few years MS may go back to its old tricks. Nothing that company does has ever been consistent from one decade to the next. For anything expected to "just work" for more than a handful of years, MS is not a reliable partner.
Linux will shortly remove support for DECNet. That's deprecating something responsibly.
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.
I'm saying this as someone who does not care about Windows (or Microsoft) at all, and hasn't been using Windows besides maybe in a vm once a year for at least a decade now:
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.
Moreover (replying to myself here), compatibility was explicitly stated as a goal. Keeping existing software running got people to upgrade to the new OS (at a time where almost every major OS version had to be bought), and to not abandon the OS line for another incompatible one. Back when there was no "web" as a unifying platform.
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.
Even Apple, who is notorious for not caring about backwards compatibility, does these kinds of backwards compatibility fixes in the OS https://worthdoingbadly.com/appkitcompat/
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.
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."
That case probably (it's been a while since I checked) still shows up in most business law casebooks, but it doesn't really help much in understanding modern judicial thinking about the role of "profit motivation" in corporate decision-making.
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.
Michael J. Vargas, Dodge v. Ford Motor Co. at 100: The Enduring Legacy of Corporate Law’s Most Controversial Case, The Business Lawyer, Vol. 75, p. 2103 (2020).
I think it definitely needs to be considered when it comes to corporate charters and especially in cases of IPO and investor on-boarding. Spelling out that a company's responsibility to long term stability and community at/above shorter term profits to investors in order to prevent certain paths in decision making that is all too common.
Wine has been affected by profit too. Nobody remembers CodeWeavers? Let alone plenty of distros are for-profit and use it as a means to advertise their game-playing capabilities.
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.
There's WineD3D to map old Wine functions to ones from DLL's reimplemented from the Wine project, but without under Windows as there's no need of a loader, OFC.
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).
One big thing for games is that Microsoft swapped out older DirectX libraries to be fairly poor emulations/translations instead of being handled directly by the graphics card.
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.
Yeah, software using DirectX8- is a crapshoot on Vista+ Windows, and often is too heavy (because 3D) to emulate. I haven't had much luck with Wine either...
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 to run Office 2003 without a hitch than Win 12 does. Same for older popular games.
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.
To wine's biggest "stakeholder" at the moment(Valve), I'd argue that running modern applications is actually more important - but then again, that is with a focus on games, so apps like Office or Photoshop don't necessarily benefit that much from the improvements that the Codeweavers people work on for them.
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 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.
Seems crazy that progress has been so slow. I was playing games at 1080p, 72Hz/fps, literaly 21 years ago. The only games with a lock were games with hilariously broken physics engines.
> The point of Wine is to run older Windows software.
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?)
I've had older windows software require _extensive_ compatibility profile tuning to make it run at all, including disabling some device drivers, using the legacy scheduler to stop race conditions in IPC, etc.
I imagine GP conceived Wine as such because Wine has tended to have a greater chance of running older software than brand new software. This might be because Wine hasn't had the time to catch up with the latest APIs.
But in short, no. Wine has a goal of running all Windows software, old and new.
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.
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.
Most of the compatibility issues I've seen around Windows apps that fail to work seems to be changes/updates around security. A big one that I saw in the past around XP or 7 was that your general applications could no longer write to their Program Files location by default... there are many others over the years. MS has made a fair effort to maintain compatibility, but don't underestimate the power of developers to hard code something out of convenience that bites them in the rear once security contexts change from under you.
Windows APIs have a whole operating system to support, including all the new features. Microsoft rarely breaks backwards compatibility (so no 'sacrificial' APIs), but that doesn't mean there couldn't be some performance regressions or the like under newer versions. Windows went as far as changing COMMCTL32.DLL and similar just because of new Office versions.
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.
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.
Will old NT4 drivers work in Win11 compatibility mode? In another life I was a prepress operator. The RIP software only reliably ran on Windows NT4 on Alpha... can almost remember the... ah, yes, AGFA Apogee. Hardware replacement problems like this[1] were not uncommon (wow 2008! I was out of commercial printing by 2001.) But with NT4 on Alpha, once the software was installed, it never needed rebooted; it would just run until it died. Almost never hear about crazy uptimes with Windows, but, of course, RIPs only do one thing, but a lot of one thing.
> 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).
Is it? I fail to see a justification for accepting the premise of your question.
That's an odd failure. The justification is in the second half of the paragraph.
If you think this is non-representative or that the poster is a liar, fine, but their reason for asking the question is right there.
> 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
> In the last year I’ve spent quite some time working on a debugger capable of debugging both the Wine layer and the Windows application running with it.
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've been trying to follow their progress, but they haven't been updating their blog in 3 years. And they seem to just communicate using discord. So there isn't much publicly accessible visibility.
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.
> 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.
Just to let you know: The pirated version works just fine with PlayOnLinux.
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.
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:
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.
Not sure it helps now, but I believe there's a (buried) setting to keep a game from updating in steam. Of course the vestigial Origin launcher may not really respect it. And you can force a specific proton version.
I actually kind of loath constantly updating single player games. It usually breaks my working install.
I must say, this is expertly well written and paced for newbies to learn about Wine. It's not just that the content is cool, the style is on point. Kudos!
tl;dr: WINE can be considered to be more like an API translator. The opposite is also possible (Linux binaries on Windows), the most recent attempt being WSL from Microsoft itself, but there were a few other attempts before that: http://cowlark.com/lbw/index.html is one example I just found.
...and as an aside, the comments about the alcoholic beverage really suggest that they should've kept it named WINE (all uppercase).
Still a bit sad that Microsoft went the hypervisor way with WSL2, rather than the Windows Subsystem way in WSL1. It makes perfect sense that they did, but I'm still a bit sad.
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 think GP just meant that it can be ambiguous which one is meant (especially in the context of headlines like this); I'd imagine that even if it were always cased WINE it would still be pretty easily associated with the drink.
The only annoying part of the name is getting beverage-related search results when looking up error messages; but upper-casing it would probably not help much there.
One incredibly cool thing about Linux is you can install the qemu-user-static package and run binaries intended for other architectures. They install as new binfmt handlers. Got an executable that was compiled for ARM and want to run it on your X86 box? No problem, just go ahead and run it, - it'll be seamlessly emulated and, if needed, syscalls with architecture-specific quirks will be automatically translated to your host kernel (the rest being passed on verbatim). It's like the opposite and the complement of Wine, in a sense.
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.
The choice of compilers in the godbolt screenshots is odd. First, GCC is the default compiler for Linux and what most is compiled with. But using Clang would make sense if it was also used for the Windows side to Limit the differences to OS details instead of irrelevant compiler differences like Clang optimizing printf to puts while MSVC doesn't.
Also, why link to wine-mirror on GitHub instead of Wine's own gitlab instance?
The vast majority of commercial Windows software (the stuff most Wine users care about) is compiled with MSVC, so those details end up mattering a lot.
How did you generate the screenshot of the Windows/Linux call stack? It seems to be running on Windows, from the GDI-style font rendering and Visual Studio-style appearance; is it Visual Studio or a custom program, and can you run the debugger on Linux?
This is Visual Studio with the Stadia debugger extension (https://github.com/googlestadia/vsi-lldb). It runs LLDB on Windows and attaches to a process running on a remote Linux machine (Wine in this case). We have a couple of custom patches to LLDB to support Wine, which are not open source yet, unfortunately. The Wine support is not perfect, but most things work (call stacks, breakpoints, stepping though the code, etc).
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.
To me, grape juice is divine and wine is, at best, tolerable. Some of us are pretty sensitive to the taste of alcohol. Even in small quantities in mild drinks like wine.
No need to attribute it to malice. Just community members following community guidelines to keep comments relevant, thoughtful, and substantive. Most of the low hanging “jokes” don’t really adhere to that ethos and are typically treated accordingly.
I think the joke is good here, because the title is ridiculously ambiguous, and a technical article about how wine is made would suit HN as much as one about WINE.
But when people try hard to make a pun that isn't so good.
I look at it the other way: with the title worded and capitalized as it is, the joke is so obvious that I just can't find it funny at all. Immediate eye-roll and downvote from me when I clicked on the comments and saw that the top comment (at the time, at least) was a joke.
Heh, I just reloaded the page, and it looks like that comment wasn't even a joke after all! The commenter did not read the article, but honestly believed it was about the alcoholic beverage, and has since updated the comment to reflect that.
This is the other thing about this, too: sometimes it's hard to distinguish a joke for someone actually just making a mistake.
Sometimes titles are all-first-caps though. It is not obvious it doesn't mean the drink. If it is first-caps for first words and proper nouns, then why has
"Works" got a capital?
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!