Hacker News Reader

Comment by gerdesj | Hacker News Reader

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.

View on HN

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 extraordinary (backwards) compatibility.

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.

historically

You're not wrong but we're in a whole new game these days.

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.

'Recently' meaning about the past 10 years or so. Windows 8 broke a lot of software for me that runs in Wine.

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.

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.

[[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.

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.

https://www.joelonsoftware.com/2000/05/24/strategy-letter-ii...

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.

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.

Yeah, 3D games using DirectX 8- are a shitshow on Windows Vista+...

Direct Draw games can be slow as hell unless you use a wined3d wrapper.

Interesting, maybe I'll be able to play Space Empires 5 again ?!

Any pointers towards how to use this wrapper ?

https://fdossena.com/?p=wined3d/index.frag

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...

You can try boxedwine too https://github.com/danoon2/Boxedwine

"Games after the year 2000 have limitted success at running", but still thanks, I'll take any potential solution at this point, I'll check this out !

Most of what I've read by Raymond Chen is about Windows 95. Does he contradict what people are saying about backwards incompatibility since Windows 8?

> 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.

The MS of Chen no longer exists. Or may have never existed... https://en.wikipedia.org/wiki/AARD_code

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)

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/

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.

I've run Diablo 2 just fine using Wine on various machines - the only issue being the inability to play fullscreen.

I feel like I had issues with the original Diablo, however. Maybe that's what you meant?

>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 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.

Makes sense to me: Exactly, that's why they're not shipped with recent Windows.

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.

> Old games require being run as Administrator.

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.

> 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.

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.

I'd just like to mention that at least for Windows 10, this specific problem [0] is solved. I love RA2, and still play it.

[0]: https://cnc.community/red-alert-2/how-to-play

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?

What's inaccurate about it? You don't think MS is motivated by profit?

> 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:

  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.

Is it your contention that businesses only started being motivated by profit after this law got passed?

I'm saying it's not "by definition" of a business that it's purely profit driven. You could imagine people starting businesses for other reasons.

Some people are not aware that this was not always taken for granted, but has been the topic of court cases in the past.

> MS are profit motivated (by definition) and Wine is functionality motivated (again by definition).

What definitions are you using here?

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.

> Nobody remembers CodeWeavers?

Haven't they been contracted by Valve to work on Proton?

Transgaming and Cedega. At least you could build Cedega from CVS...

Reply on news.ycombinator.com