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…
How Wine works 101
161–170 of 188 posts
Re: How Wine works 101
#162Earlier quoted context omitted.
> 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 b…
>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 d…
> 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.
Re: How Wine works 101
#163Earlier quoted context omitted.
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.
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.
Re: How Wine works 101
#164What 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.
Re: How Wine works 101
#165Earlier quoted context omitted.
> MS are profit motivated (by definition) 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." [1]: https://en.wikipedia.org/wiki/Dodge_v._Ford_Motor_Co .
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: Thi…
Re: How Wine works 101
#166Earlier quoted context omitted.
>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.
Re: How Wine works 101
#167Re: How Wine works 101
#168Earlier quoted context omitted.
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.
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.
Re: How Wine works 101
#169Earlier quoted context omitted.
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.
Elden Ring, for one.
Re: How Wine works 101
#170Earlier quoted context omitted.
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…
I'm no Windows fan, but this is not an accurate portrayal (d'oh!). 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 extraordin…