Hacker News Reader

Comment by Multicomp | Hacker News Reader

> At some point in the not too distant future, old x86 applications will cease to run on Macs, as emulation support won’t run forever

One thing I can credit Android some, and Windows a lot (even 10 with all its manifold privacy and user-hostility problems) with is that they are backwards compatible.

exceptions to every rule, etc., but I can run all old versions of Android apps on an Android 11 phone, same for Windows programs going back to 1996 or so with few tweaks, and can squeeze that back to 1993 if I fuss and cuss and so on.

yes, this is arch to arch emulation, but the idea od taking that feature away in ~4 years vs Android's best effort continued compatibility or Microsoft's compatibility layers is a cost/benefit that I apparently disagree with Apple decision makers on.

View on HN

It is always a trade off. Prioritizing backwards compatibility does not come for free.

One result I see from this is that MS keep creating new APIs whole old ones languish in obscurity.

On Macs in contrast Cocoa is part of a lineage all the way back to the 1980s. I can still use Objective-C skills I learned even before macOS X was released.

The same cannot be said for Windows. Nobody in their right mind writes Win16 or Win32 apps today.

So ironically the backwards compatibility MS offers it users come at the expense of backwards compatibility for developer skills.

When you ban breaking changes in an API you also stop that API from modernizing and staying relevant.

> So ironically the backwards compatibility MS offers it users come at the expense of backwards compatibility for developer skills.

im not sure this follows necessarily: whats to prevent ms from say, writing a wrapper that packages up said legacy apps and supplies the libraries they need, so they can keep running and ms can still dump thier old frameworks and stop supportimg them in newer os's?

basically, what im saying is, for legacy apps, they can be "bottled up" and still run on newer systems without harming developer compatibility and modernizing (wine proves this imo)

but maybe im missing some important detail...

We surely do write Win32 applications, which is one of the reasons why UWP failed and now Project Reunion is bringing the best parts of UWP into Win32.

.NET 5 was also only released for Win32, Linux and macOS, UWP will get an update only later next year, if ever.

True, that's a good thing, but that's also where you get a lot of the cruft that slows things down.

For example Apple no longer has to support OpenGL and it can just cut out relevant hardware on the SoC level, leaving more room for other things.

On the smartphone front, Qualcomm can't do that, since it sells its chips to a broad base that have variable requirements.

I guess it's a tradeoff.

> Apple no longer has to support OpenGL and it can just cut out relevant hardware on the SoC level, leaving more room for other things.

Just for everyone who is scared by this statement - macOS on Apple Silicon still supports OpenGL and OpenCL, but it is emulated on top of Metal now.

Can you give a source for this? Also, is it still stuck at 4.1/1.2?

Yep, still OpenGL 4.1 and OpenCL 1.1. It goes through AppleMetalGLRenderer on Apple Silicon Macs.

You might want to look at: https://www.phoronix.com/scan.php?page=news_item&px=Zink-mac... though. Maybe there'll be more interest for a direct OpenGL to Metal layer not built by Apple in the future, for having a newer feature set.

There is a cost to that though, the reality is Windows has become rather bloated because MS can't let anything go. It doesn't help that they have never been able to say no to anything and everything getting included.

> because MS can't let anything go.

To be clear, this isn't really up to them. It's what market forces have dictated.

Tons of old corp apps exist all over the place that necessitate this level of backwards compatibility.

One crazy thing I read about, was of a bug from some 3rd party company’s application.

On some Windows update, the application no longer worked. But since Microsoft wanted to ensure a seamless transition during upgrades, they changed their OS code to perpetuate the bug from that application, to allow it to continue working.

Kudos to them for doing so.

That's nice of them, but it does needlessly bloat OS code, specification, and tests.

In the long run, clear specification and implementation is a lot more desirable, than needing to support various hacks and workarounds for 3rd party software.

It's totally up to them. If Microsoft wanted to, they could say tomorrow that Windows 11 will no longer maintain backwards compatibility with X, Y, and Z ancient technologies.

This would anger some of their corporate customers. Possibly even enough that they could get together and fund some kind of Windows Legacy effort. But realistically, if Microsoft decided to stop being backwards-compatible, where are their customers who are stuck with ancient Windows software going to go? Macs? Linux? Neither of those will have the kind of guarantees their purchasing departments require for compatibility.

Maybe, just maybe, if Microsoft stopped supporting everything ever written for one of their OSes, some of the godawful legacy cruft would actually have to be replaced by new software, and some poor corporate IT people's lives would improve immensely...

They tried that with WinRT, and despite many of us actually liking those efforts, it failed as those customers did not accepted it, now there is Project Reunion to unroll the path taken since Windows 8 introduction.

> this isn't really up to them. It's what market forces have dictated.

This is a symmetric process. Microsoft chose its marker and set its customers’ expectations. That influences both who buys its products and how they structure their own dependencies.

That said, they are moving in a direction; they've stopped trying to make IE work in favor of a rewrite, keeping IE around for older apps.

Honestly wouldn't be surprised - actually I AM surprised this isn't a thing yet - that they would run older Windows apps in a VM / emulator. Actually they may already do this but I'm just not aware of it.

One thing they have been doing is turn Windows into an evergreen operating system (together with Edge), so that few people will still be running older versions of their operating system.

In Windows 7, they had "XP Mode" which was just a VM for running Windows XP. (I do not recall if it was available in Vista - they did not include it in Windows 10.)

https://www.microsoft.com/en-us/download/details.aspx?id=800...

> It uses virtualization technology such as Windows Virtual PC to provide a Virtual Windows XP environment for Windows 7.

> ..rather bloated because MS can't let anything go.

Ah. This comment seems off the cuff and not well thought out.

I think you may be underestimating the scope and scale at which Windows OS operates[0]. Outside of cool techie agencies and SV type companies, the default OS for any organization from churches to charities to governments to schools, the world over, is Windows. MacOS may be sleek and shiny apex predator but our world would grind to a halt, an absolute standstill if WindowsOS suddenly got wiped. It's not a whale. It's the ocean itself.

[0] https://en.m.wikipedia.org/wiki/Usage_share_of_operating_sys...

Ah. This comment seems off the cuff and not well thought out.

I know how pervasive Windows is, I've made my living writing software for it for the last twenty five years. That is why I know that it is a bloated and over complicated mess.

The reality for most corporates is the only software they want on their desktops is Office and a web browser. This has been the case for a long time. There are laggards of course but taking too much notice of them has crippled the system.

I really applaud Microsoft for their backwards compatibility efforts and I'm sure organizations love it. But I personally don't need to run Windows software from 20 years ago.

For me, there is no reason to use Windows over any of the more modern lean and mean operating systems available, and I know a ton of blue collar workers in the U.S. who only have a smartphone and maybe a tablet.

Windows is just not very easy to use by 2020 standards because of all its baggage and consumers care a lot more about that kinda thing compared to organizations. Most of Microsofts attempts to modernize (Microsoft Store, UWP, sandboxing, etc.) seem to have stalled or failed unfortunately.

Honestly, at this point it might make more sense for Microsoft to just milk Windows for as long as possible while minimizing costs and investing in their other businesses (like Azure). Trying to modernize Windows would be like trying to modernize Edge to be competitive with Chrome.

I started developing iOS apps for iOS 5, and me my first apps still run on iOS 14 unchanged. Not sure what you are on about?

32 bit apps don't run on iOS 14.

Not being backwards compatible is a huge pain, but Apple can (somehow) afford to put that burden on developers.

They added 32 bit x86 support to Rosetta apparently just to get CrossOver to work. This could be a reason for them to never remove Rosetta. Maybe they'll just remove the x86 userland.

> but I can run all old versions of Android apps on an Android 11 phone

Mostly. They've done a pretty good job of maintaining backwards compatibility but it isn't perfect. E.g. there's no way to access the old hardware options button anymore. You also get a warning popup if you try to run old apps.

I just tried running an old app I wrote and it freaked out a bit with the layout, jittering all over the place initially. But other than that it mostly worked.

Reply on news.ycombinator.com