Slashdot Mirror
Apple Prepares MacOS Users For Discontinuation of 32-Bit App Support (arstechnica.com)
Last year, Apple announced that macOS High Sierra "will be the last macOS release to support 32-bit apps without compromise." Now, in the macOS High Sierra 10.13.4 beta, Apple is notifying users of the impending change, too. "To prepare for a future release of macOS in which 32-bit software will no longer run without compromise, starting in macOS High Sierra 10.13.4, a user is notified on the launch of an app that depends on 32-bit software. The alert appears only once per app," Apple says in the beta release notes. Ars Technica reports: When users attempt to launch a 32-bit app in 10.13.4, it will still launch, but it will do so with a warning message notifying the user that the app will eventually not be compatible with the operating system unless it is updated. This follows the same approach that Apple took with iOS, which completed its sunset of 32-bit app support with iOS 11 last fall. Developers and users curious about how this will play out will be able to look at the similar process in iOS for context. On January 1 of this year, Apple stopped accepting 32-bit app submissions in the Mac App Store. This June, the company will also stop accepting updates for existing 32-bit applications. iOS followed a similar progression, with 32-bit app submissions ending in February of 2015 and acceptance of app updates for 32-bit apps ending in June of 2015.
I can still run Windows apps originally compiled in 1992 on Windows 10.
Just sayin'.
I think it likely there's going to be a lot of resistance to this one. There are an awful lot of perfectly good apps out there where the developers have gone away - they're just not going to make the transition to 64-bit. Apple's asking a very large number of users to take a serious a hit in terms of lost investment all at once.
There's no particularly good reason for it. The existing OS support can be frozen, and new OS stuff added; it's not like we're short on memory or storage.
For some, the answer will be to simply not move to the new OS (notice I didn't use the term "upgrade.") For others, it may be a VM, unless the VM's can't run in 32-bit mode (don't know why that would be the case, but perhaps it is.)
It is Apple's habit to go with "hey, I have an idea" where for some reason, no one stands up and tells them "you know, that's not a good idea..." They did it with the PPC emulation, they did it with headphone jacks, they did it with slowing down people's phones, and now... now they're going to kill a lot of people's tools.
Interesting times for Apple.
I've fallen off your lawn, and I can't get up.
do anything useful using only numbers larger than 2,147,483,647?
I used to think the same thing, but then I out a 2006 Mac pro vs a 2005 Quad G5. The Intel cpu is way cooler, and faster. Be the G5 was a crap processor. It was good to jump out of PowerPC, but yeah it's a joke how quickly they killed OS X on PowerPC.
But the real truth is that iPod, and the iPhone, and iPad sell a hell of a lot more than any Mac.
Apple computers are effectively dead.
>Of course, there will come a time in the not-so-distant future when 64-Bit computers will get the cold shoulder.
You think? I'm not so sure. Or, at least it will take a lot longer than previous transitions.
The driving force behind bit-size increases seems to be RAM - vector processors (aka GPUs these days) and other SIMD techniques address performance issues quite sufficiently, and there's very little call for calculations to be performed more precisely than can be done in 32 bits, much less 64 (neglecting limited demand for exact calculations, which will always need to be implemented in software)
32 bit computers had been flirting with their limitations for a while - 32 bit addresses can only access 4 GB of RAM without all sorts of performance-killing jumping through hoops (pointer arithmetic is fundamental to almost everything). And unlike 16 bit computers (which can only natively address 64kB of RAM and required hoop-jumping from day one on PCs), 32 bit OSes were born in the time of the 386, when a couple MB of RAM was impressive, and 4GB was an unimaginably insane amount, so new OSes could get the performance benefit of assuming all RAM was directly addressable, with vast ranges of "this will never be used" address space that could be allocated to various non-RAM purposes (hence only being able to use ~3.5GB of your 4GB of RAM on Windows XP).
64-bit computers though are a far larger jump again. Going from the 286 (16 bit calculations, 24 bit addresses through "protected mode") to the 386 (32 bit native addresses) only introduced an extra 8 address bits - 256x times the space, from 16 MB to 4GB, or about 16 years by Moore's Law at the time. Going from 32 to 64 bits adds about 4 billion times the natively computable address space - or about 48 years by the modern accelerated Moore's Law. Meanwhile, actual uses for more memory seem to finally be slowing down - over a decade since Microsoft introduced a mainstream 64-bit OS, there's still not really much to be gained by most people having more than 8GB of RAM in a PC.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Macs haven't run my 68K {NOTE: binary} apps for years. 8088 MS-DOS 3.1 batch {text, source} files still (mostly) work in Windoze, though.
NOTE: {notes} are mine.
Which makes a great argument in favor of accessible source.
Because your batch file are human readable text-file, you can even edit what's needed to remove the "(mostly)" part of the sentence.
Much more difficult with binary 68k machine code.
If you had access to the original C / Pascal code that the 68k apps were compiled from, it would be much more easy for devs to adapts them to modern architectures/APIs.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]