Apple knows better than 32-bit
-
In the latest example of Apple knowing best, the latest release of MacOS completely removes support for 32-bit programs.
Allegedly most programs from the Mac App Store should already be 64-bit because Apple has been making a push for this transition for, like, a year. How much longer do you really need? Unfortunately for actual users, reputable sources indicate that not all software is acquired through the Mac App Store.
Anyway, it is definitely true that a lot of software has been broken by this. And believe it or not, not all developers have dropped everything to bring their software to 64-bit. It's a good thing Apple is wise enough to realise that none of those philistine Luddites are worth supporting!
32-Bit Apps 'Not Optimized for Your Mac' No Longer Working on macOS Catalina
When macOS Mojave was announced, Apple warned that it would be the last version of macOS that would support older 32-bit apps. Apple has been phasing...
-
@kazitor said in Apple knows better than 32-bit:
Allegedly most programs from the Mac App Store should already be 64-bit because Apple has been making a push for this transition for, like, a year.
I'm reasonably sure it's been longer than that. The warnings started in High Sierra.
@kazitor said in Apple knows better than 32-bit:
Anyway, it is definitely true that a lot of software has been broken by this.
Is it? How much software has been broken that wasn't already old?
The article mentions Aperture but it was discontinued in 2014.My work laptop is still on High Sierra and the only apps not 64-bit are random Apple things like DVD Player which aren't current anyway. Almost nothing is from the App Store.
-
@loopback0 said in Apple knows better than 32-bit:
How much software has been broken that wasn't already old?
Why is "old" exempt from "supported"? Here's a random article:
MacOS's Catalina update has ended support for 32-bit games
The latest big MacOS is live, and it removing 32-bit support means that loads of older games will no longer run on Mac.
-
@kazitor said in Apple knows better than 32-bit:
Why is "old" exempt from "supported"?
At some point you've got to stop supporting stuff.
How many vendors still support software they made several years ago? Very few.
TF2 might be one of the very few things that are over a decade old, still 32-bit and still actively supported today.
-
@loopback0 what is the overhead in supporting 32-bit applications together with 64-bit ones for a company like Apple in the first place? What are the advantages of a 64-bit-only ecosystem? There are countless examples of stuff that has never been updated but still perfectly works and is perfectly solid even today. In the audio world, lots of plugins are still 32-bit because the company that made them has stopped trading (often, a lone developer being hired by a larger company).
-
@kazitor said in Apple knows better than 32-bit:
classic game collections
Spotted
there. It's the same argument back when Ubuntu tried to drop 32-bit altogether.
-
@_P_ said in Apple knows better than 32-bit:
It's the same argument back when Ubuntu tried to drop 32-bit altogether.
And the "counterarguments" haven't become any better in the meantime
-
@dfdub said in Apple knows better than 32-bit:
@_P_ said in Apple knows better than 32-bit:
It's the same argument back when Ubuntu tried to drop 32-bit altogether.
And the "counterarguments" haven't become any better in the meantime
True, it's like we accidentally invented time loops
-
@admiral_p said in Apple knows better than 32-bit:
@loopback0 what is the overhead in supporting 32-bit applications together with 64-bit ones for a company like Apple in the first place?
Quite a bit actually. I ran Gentoo on my desktop for over a decade, and about half that time with a "multilib" setup providing both 64-bit and 32-bit libraries, mostly for some non-free legacy shit I thought I needed. Though it mostly works fine, it's not trivial to make everything produce, link against and find the right libraries in the right places. And the Gentoo people would just rely on people testing stuff and if something broke to file a bug that may or may not get fixed in their build system or upstream, whereas if you have to provide official support and do QA on all those 32-bit shims, that's something I'd think twice about, too.
That said, of course when you bought Apple you knew you'd be at the mercy of all their business decisions, right? It's not like they haven't made quite a few unpoular ones of these in the past.
-
@kazitor said in Apple knows better than 32-bit:
@loopback0 said in Apple knows better than 32-bit:
How much software has been broken that wasn't already old?
Why is "old" exempt from "supported"?
Uh, what actually fatally changed in Catalina (god I hate these names — it’s version 10.15) which isn’t trivially easy to recompile for (IIRC if a Cocoa program can’t be directly recompiled it’s doing something actively stupid, like casting pointers to other data types) is that support for the Carbon API has been removed.
When Carbon was introduced, which was roughly two decades ago, Apple specifically said not to use it for new development. It was only meant to be a way to do fast ports of old apps from Classic Mac OS to Mac OS X. The whole shtick was: convert your old program from the Classic API to Carbon, and then rework it into the Cocoa (that is, the NextStep-ish) API. I was in the developer program at the time, watched the WWDC keynotes about it, that’s what they said all along.
So: anybody who wrote a from-scratch Mac program in the last two decades who finds it failing now was doing it wrong from the start. Yeah, it sucks if you’re a user and you’re paying for a developer’s mistake — but both you and they were warned.
-
@Anonymous-Throwaway said in Apple knows better than 32-bit:
@kazitor said in Apple knows better than 32-bit:
@loopback0 said in Apple knows better than 32-bit:
How much software has been broken that wasn't already old?
Why is "old" exempt from "supported"?
Uh, what actually fatally changed in Catalina (god I hate these names — it’s version 10.15) which isn’t trivially easy to recompile for (IIRC if a Cocoa program can’t be directly recompiled it’s doing something actively stupid, like casting pointers to other data types) is that support for the Carbon API has been removed.
So what if it's "trivially easy to recompile for"? When you recompile for a different architecture / environment, you have to retest everything. (Everything got compiled in a new way that it was never compiled in before, so everything must be assumed to be broken. When I rebuilt a pile of embedded software for the same hardware but a different compiler of the same language one time, with less than 64KiB of compiled code including the runtime library, I had to write a detailed test spec for it, which consumed 35 pages of A4.)
And this is TDWTF, where we, er, "celebrate" programs that do actively stupid things.
-
@loopback0 said in Apple knows better than 32-bit:
My work laptop is still on High Sierra and the only apps not 64-bit are random Apple things like DVD Player which aren't current anyway.
Apparently (I haven’t installed it yet), the DVD Player app has been removed from 10.15 <aside>(I agree with @Anonymous-Throwaway about the OS names)</aside> anyway, so it’s not like that’s a big loss.
However, I also think that this is not a great move: there is plenty of software for which there simply isn’t an (affordable) alternative and no way there will ever be a 64-bit version. A VM with an older OS X or macOS is the best solution I can come up with. But what do you do with that if Apple decides to change Macs over to ARM chips, as has been rumoured for a couple of years now?
-
@Gurth said in Apple knows better than 32-bit:
Apparently (I haven’t installed it yet), the DVD Player app has been removed from 10.15 anyway, so it’s not like that’s a big loss.
Seems there's a 64-bit version in Catalina but yeah wouldn't have been a big loss.
<aside>(I agree with @Anonymous-Throwaway about the OS names)</aside>
I figured when they renamed to macOS they'd give up on it being 10.whatever and have macOS 11, 12 etc like iOS but no.
-
I like to bash 64-bit incompatible software as much (perhaps more) as everybody else -- after all, it's like 2019 or something. But if you ever run into something that makes those 32-bit specific assumptions somewhere deep down, it's rather painful to port to 64-bit.
There's a link in the article by @kazitor to a small dev and they list their problems. Yeah, they might have made some dubious decisions, but it's very clear that Apple was an also-ran platform for them from the get go. So, when Apple made supporting their platform more difficult, the devs decided that it wasn't worth the effort.
-
@admiral_p I don't know the details but backward compatibility always has some downsides.
More importantly, by breaking old programs you're sending a message that you won't bend over backwards for them like Microsoft does. And maybe at some point, people will learn that when you say "don't use this API", you should not use that API.
-
@Gurth said in Apple knows better than 32-bit:
there is plenty of software for which there simply isn’t an (affordable) alternative and no way there will ever be a 64-bit version
Why is the software industry failing to maintain so many products or produce new ones? I think that's the real problem here.
-
@anonymous234 said in Apple knows better than 32-bit:
Why is the software industry failing to maintain so many products or produce new ones?
why do companies go out of business and leave their customers with products that will never again get an update, or new version, yest is critical to the customer's business so that the cost of replacing it, if there is a suitable replacement, is sufficiently high that it is not only cheaper, but safer, to leave the old piece of software intact?
Why do businesses that do not go out of business discontinue software, telling their customers to buy their new product that does only a third of what the old product does for six times the cost. Why do these companies fail to listen to their customers when they are told that the new version of the software is not fit for the purposes the original was fit for?
Why do single developer open source projects get abandoned when the developer gets a full time job, or a significant other, or an illness, or even just burns out on the entitled support demands from the people that think because they use a piece of software they are owed custom and first class support, even when they don't pay for it?
-
@LaoC said in Apple knows better than 32-bit:
That said, of course when you bought Apple you knew you'd be at the mercy of all their business decisions, right? It's not like they haven't made quite a few unpoular ones of these in the past.
Precisely. The parable of The Farmer And The Viper applies in full force here.
-
@anonymous234 said in Apple knows better than 32-bit:
@admiral_p I don't know the details but backward compatibility always has some downsides.
More importantly, by breaking old programs you're sending a message that you won't bend over backwards for them like Microsoft does. And maybe at some point, people will learn that when you say "don't use this API", you should not use that API.
Yeah, that message has been sent. For something like 30 years now, that message has been sent, and received. It's a good part of the reason why the Mac's market share has always been abysmally low compared to Windows.
-
@Mason_Wheeler said in Apple knows better than 32-bit:
It's a good part of the reason why the Mac's market share has always been abysmally low compared to Windows.
I'd say price is 99% of the reason.
-
@Vixen said in Apple knows better than 32-bit:
why do companies go out of business and leave their customers with products that will never again get an update, or new version, yest is critical to the customer's business so that the cost of replacing it, if there is a suitable replacement, is sufficiently high that it is not only cheaper, but safer, to leave the old piece of software intact?
If a piece of software is that critical then keeping using something that's unsupported and no longer receives things like security updates is a major risk to the business and it should be replaced.
-
@anonymous234 said in Apple knows better than 32-bit:
@Gurth said in Apple knows better than 32-bit:
there is plenty of software for which there simply isn’t an (affordable) alternative and no way there will ever be a 64-bit version
Why is the software industry failing to maintain so many products or produce new ones? I think that's the real problem here.
Indians and other framework cobblers that don't have any ideas or understand how anything works?
-
@loopback0 said in Apple knows better than 32-bit:
@Vixen said in Apple knows better than 32-bit:
why do companies go out of business and leave their customers with products that will never again get an update, or new version, yest is critical to the customer's business so that the cost of replacing it, if there is a suitable replacement, is sufficiently high that it is not only cheaper, but safer, to leave the old piece of software intact?
If a piece of software is that critical then keeping using something that's unsupported and no longer receives things like security updates is a major risk to the business and it should be replaced.
If we were talking about the purely theoretical state of affairs, or even just the principle of the things I would not disagree with you.
But when that unsupported system has been in place for 15 years, has integrations with 11 other systems, has tens of thousands of lines of business specific code written around and through it to make ti exactly fit the needs of the business for which it is installed.... The cost for replacing that is huge. you have to find a system that does everything the current one does, or write one that does that, or get the business to agree to change their processes. None of those options are cheap. All of those options are risky because you are replacing a system that has been built over 15 years, tested against every edge case that can be thrown against it by every user of the system over all that time, and because it was first installed fifteen years ago the odds are that no one that did the install still works at the company, and there's pretty bad odds of anyone still working in IT that worked with the people who did the initial install.
To replace that system is going to be an expensive process, at MINIMUM that's going to be a year of development, but in practical terms this is a multi-year project. and while working on it those resources can't be used to continue the normal work of the business that they were initially hired for. Which means you either have to massively decrease the normal LOB output of your IT team, which is going to endear them oh so well to the rest of the business, or you have to slow down development to a crawl which is going to make the multiyear project so long that there's literally no chance it will be a success, or even deployed, or you could hire a new development team to work in parallel to do the development, but that's super expensive, and not even expendable as a capital expense for tax benefits, and you're really not going to have work for that team after the project is over, so you're going to have to fire them after which won't be good for morale, or find work for them, but who wants that much make-work? I suppose you could bring in contractors a for a long term contract (one or two years) and sure they're cheaper than full employees, but then you have to integrate them into the team, and deal with all that contractor guff. Consultants are also a possibility, but they're consultants, do I need to say more?
So no matter what path you take to replace the system outright it's going to be expensive as fuck, and just as risky as unprotected fucking with everyone loitering on the Las Vegas Strip.
A better approach might possibly be.... Shore up the unsupported system as best you can, put protections around the system, to prevent unauthorized, external access to the system. Make damn sure your backups are up to date, regularly tested, and secure...
then piecemeal, start carving chinks out of the system. Touching the X module of the legacy system? Re-implement it in a new supported technology with better architecture and replace the X system with stubs that forward to the new system. Keep repeating, taking chinks out of the system every chance you get until the legacy system is just a shell, nothing reads from it, nothing writes to it and cares about the records that were written. They're all just writing to the system to satisfy your reporting needs. Now you can tackle those reports... rewriting them, updating them, dropping old ones, until not even the reports read from the old system and you can finally take it around the back of the barn with your shotgun and do the needful.
Now this approach is going to take years, and years to accomplish, but it smears the cost of development across those years, which lowers the per year cost (the only cost the bean-counters look at) and smears it across many different projects, and means your department is still doing LOB work, and delivering on the needs of the company without needing more resources (or if you do, they're significantly reduced which makes it easier to get them, and keep them after you're done)
You take the risk out because instead of trying to replace the whole system at once with all it's intricacies, you work on replacing it piecemeal, so you only have to get one piece of functionality right at a time, which is much easier.
-
@loopback0 said in Apple knows better than 32-bit:
@Vixen said in Apple knows better than 32-bit:
why do companies go out of business and leave their customers with products that will never again get an update, or new version, yest is critical to the customer's business so that the cost of replacing it, if there is a suitable replacement, is sufficiently high that it is not only cheaper, but safer, to leave the old piece of software intact?
If a piece of software is that critical then keeping using something that's unsupported and no longer receives things like security updates is a major risk to the business and it should be replaced.
For many applications, security is a non-issue. For instance, design and creative applications often do not even need to be aware of the internet and may be run on offline computers to start with. Lots of industrial software too. Of course you don't need to upgrade either to the latest and greatest OS version either, but for some niches, the overlap between work and leisure is broad enough that they're forced to a compromise.
-
@Vixen said in Apple knows better than 32-bit:
The cost for replacing that is huge
The cost of it breaking unrecoverably is huge too.
As you said (in far too many words) one way or another you need to suck it up and get on with it.
-
@Vixen I don't know? But I think a part of the problem is that when companies go out of business (or change business), they all seem to abandon their copyrights instead of auctioning them to the highest bidder. Which would allow others to sell updates to old products.
-
@anonymous234 said in Apple knows better than 32-bit:
@Vixen I don't know? But I think a part of the problem is that when companies go out of business (or change business), they all seem to abandon their copyrights instead of auctioning them to the highest bidder. Which would allow others to sell updates to old products.
even if the copyright is abandoned what about the codebase? were does that go? the build infrastructure/pipeline? what happens there when the company shutters and DOESN'T put those into the public domain because it just shreds its servers.
Like basically all the companies that go under do.
-
@loopback0 said in Apple knows better than 32-bit:
@Vixen said in Apple knows better than 32-bit:
The cost for replacing that is huge
The cost of it breaking unrecoverably is huge too.
As you said (in far too many words) one way or another you need to suck it up and get on with it.I'm with @Vixen on this one, and I even have a Real Life
example in my team of more or less what she describes: an old-as-fuck application that limps around as binaries copied from system to system with more and more old versions of libraries dragged along at each OS update. It's a pure desktop local application, so there is no security risk.It is still being used in a few edges cases, because it had so many weird and useful-in-edge-cases business functions (some complicated mathematical stuff) that would cost a lot to port to our new application, because the business logic is awfully hard to follow and full of quirks added along the years. As years go by, we progressively reimplement bits and pieces in other places, as the need arises, so yeah, we do "suck it up and get on with it". But we can do that incrementally and keep the old one available for when we don't have time to port a specific feature right now and business needs it right now. If we didn't, life would be harder.
Ultimately, as for many such decisions, it's a cost/benefit analysis. There is a risk (and a cost) associated to keeping that old unmaintained application. There is a cost (and a risk) associated to porting everything to a new application. Repeat for each individual feature of the application. Depending on many external factors, at each point in time some features are worth porting, some are better staying in the old application.
Hopefully by the time the application becomes irremediably unusable (because of too many incompatible system changes), all useful features will have been ported and all that will not have been are useless features. Still being able to run an unsupported application allows us to keep that fine-grained balance and better allocate our resources. It's a Good Thing.
-
What timing... Raymond talks about compatibility...
Why are timer IDs and dialog control IDs 64-bit values on 64-bit Windows? Did you really expect people to create more than 4 billion timers or dialog controls? - The Old New Thing
Anywhere it's possible to put a pointer, somebody will try to put a pointer.
-
@loopback0 said in Apple knows better than 32-bit:
@kazitor said in Apple knows better than 32-bit:
Why is "old" exempt from "supported"?
At some point you've got to stop supporting stuff.
In many cases, that's a bullshit argument. "Support" and "Don't deliberately break something for no good reason" are two entirely different things.
At home I still use Microsoft Office 2003. It works, it does everything that I need and it runs just fine with the latest version of Windows 10. I seriously doubt that anyone at Microsoft is running tests on the latest release of Windows 10 to see if Office 2003 still works. As a result, Microsoft's cost of "supporting" Office 2003 is exactly zero.
-
@El_Heffe said in Apple knows better than 32-bit:
I seriously doubt that anyone at Microsoft is running tests on the latest release of Windows 10
to see if Office 2003 still works.
-
@El_Heffe said in Apple knows better than 32-bit:
As a result, Microsoft's cost of "supporting" Office 2003 is exactly zero.
Correct, because they don't.
-
@anonymous234 said in Apple knows better than 32-bit:
@admiral_p I don't know the details but backward compatibility always has some downsides.
More importantly, by breaking old programs you're sending a message that you won't bend over backwards for them
@anonymous234 said in Apple knows better than 32-bit:
Why is the software industry failing to maintain so many products
You do see the contradiction here, don't you? Pretty ironic that you posted these two statements within two minutes.
-
@anonymous234 said in Apple knows better than 32-bit:
I don't know? But I think a part of the problem is that when companies go out of business (or change business), they all seem to abandon their copyrights instead of auctioning them to the highest bidder. Which would allow others to sell updates to old products.
The expectation that someone else would continue most of the products of a failed software companies after acquiring them is pretty naive. Maintaining and especially updating old applications, games and drivers for new OS versions usually simply isn't financially viable, let alone attractive from a business perspective.
-
@dfdub especially when in many cases the source code either
A. Won't compile on modern tool chains at all or
B. Doesn't exist any more (especially where assets are concerned).
-
@El_Heffe said in Apple knows better than 32-bit:
I seriously doubt that anyone at Microsoft is running tests on the latest release of Windows 10 to see if Office 2003 still works.
You'd be surprised.
-
@El_Heffe said in Apple knows better than 32-bit:
I seriously doubt that anyone at Microsoft is running tests on the latest release of Windows 10 to see if Office 2003 still works.
Why? I would be very surprised if they weren't, because just imagine the news articles if they broke it. "Microsoft can't even keep their own products running!"
-
@Mason_Wheeler said in Apple knows better than 32-bit:
@El_Heffe said in Apple knows better than 32-bit:
I seriously doubt that anyone at Microsoft is running tests on the latest release of Windows 10 to see if Office 2003 still works.
Why? I would be very surprised if they weren't, because just imagine the news articles if they broke it. "Microsoft can't even keep their own products running!"
If they broke a version of Office they've not supported for many years? Not sure that's the sort of news they'll give a shit about.
-
@El_Heffe said in Apple knows better than 32-bit:
I seriously doubt that anyone at Microsoft is running tests on the latest release of Windows 10 to see if Office 2003 still works.
Have you tried running tests on the 7th generation Intel CPU to see if Windows 7 still works? Because it becomes slow as fuck ever since. And even less people give a shit about it.
-
@_P_ are you sure it's not just a shitty computer?
-
@_P_ said in Apple knows better than 32-bit:
@El_Heffe said in Apple knows better than 32-bit:
I seriously doubt that anyone at Microsoft is running tests on the latest release of Windows 10 to see if Office 2003 still works.
Have you tried running tests on the 7th generation Intel CPU to see if Windows 7 still works? Because it becomes slow as fuck ever since. And even less people give a shit about it.
My Windows desktop at work is either 7th or 8th generation and it runs Windows 7 fine.
-
@Gąska Intel processors since Kaby Lake series only provides native Windows 10 support, and Windows 7/8.1 has to be run in legacy, emulation mode, which can cause ridiculous amount of slowdown.
-
@_P_ sauce?
-
@Gąska It's officially stated. It doesn't stop people trying to do that anyway, which the end result is entirely YMMV, and there are some issues that needs to be fixed (seems to be mostly USB 3.0 related stuff).
-
@_P_ that's something different. It says that it's not supported. I meant to ask for a source that it's emulated. I can't find that bit anywhere.
-
@Gąska https://blogs.windows.com/windowsexperience/2016/01/15/windows-10-embracing-silicon-innovation/
"Windows 7 was designed nearly 10 years ago before any x86/x64 SOCs existed. For Windows 7 to run on any modern silicon, device drivers and firmware need to emulate Windows 7’s expectations for interrupt processing, bus support, and power states, which is challenging for WiFi, graphics, security, and more. As partners make customizations to legacy device drivers, services, and firmware settings, customers are likely to see regressions with Windows 7 ongoing servicing."
-
@_P_ "emulate the expectations" != "running in emulation mode". It can mean thousand of different things, but you made it sound like there's live instruction rewriting going on or something.
-
-
@remi said in Apple knows better than 32-bit:
it's a cost/benefit analysis
in the real world it always is.
and the truth is that in the business world it only takes ONE piece of software failing to work on the next OS upgrade for the upgrade to be scuppered.
It's all well and good and argue for pure architecture, and punishing developers for violating guidelines or failing to keep up to date, but the reality is much less forgiving. If you break legacy support to move to a pure architecture then you just lost your install base because they want their software to work, and they don't care that running 32 bit software on a 128 bit OS is a PITA to support. they just want their software to work.
same things happens for punishing developers for not staying up tp date. you break software and users decide they don't like you anymore.
When i was in college I loved linux, it was the only OS i ran on all my PCs, and laptops, but over time i kept running into games that wine couldn't run, or upgrades that broke part of my workflow, or even just things like wanting to be able to plug and unplug monitors and have the OS just know what monitor layouts I wanted without having to do things like write custom xrandr scripts and trigger them via cron, or try and hotplug detect to run them.
So these days I run Linux on the server because that's where it's happy and i don't have to deal with the constantly changing UI that breaks features I used to enjoy, and run Windows on the desktop and laptop because they have the backwards compatibility i crave for UI focused applications.
-
@Vixen There's pretty good decompilers nowadays.
