Apple Starts Alerting Users That It Will End 32-Bit App Support On the Mac (techcrunch.com)

An anonymous reader quotes a report from TechCrunch: Tomorrow at midnight PT, Apple will begin issuing an alert box when you open a 32-bit app in MacOS 10.13.4. It's a one-time (per app) alert, designed to help MacOS make the full transition to 64-bit. At some unspecified time in the future, the operating system will end its support for 32-bit technology meaning those apps that haven't been updated just won't work. That time, mind you, is not tomorrow, but the company's hoping that this messaging will help light a fire under users and developers to upgrade before that day comes. Says the company on its help page, "To ensure that the apps you purchase are as advanced as the Mac you run them on, all future Mac software will eventually be required to be 64-bit." As the company notes, the transition's been a long time coming. The company started making it 10 or so years ago with the Power Mac G5 desktop, so it hasn't exactly been an overnight ask for developers. Of course, if you've got older, non-supported software in your arsenal, the eventual end-of-lifing could put a severe damper on your workflow. For those users, there will no doubt be some shades of the transition from OS 9 to OS X in all of this.

Comments

why?

[Anonymous Coward]

To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.

Re:why?

[drinkypoo]

To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.

It's probably actually to reduce testing. It's still dumb. You're gonna have to run a VM to run 32 bit software. Even Microsoft is better at back compatibility than that. But Apple has never been shy about forcing its customers to spend more money, because they repeatedly demonstrate a willingness to do that — and they often give it to Apple.

Re: why?

[guruevi]

Yes, your company should account for that when it purchases technology. Everything gets old and dies, from people to computer programs. Not accounting for that fact is a problem in your business model. Are you still using a PDP11?

Re:why?

[KiloByte]

I realize that there are arch improvements in amd64 but that's no reason to break compatibility.

64-bit on x86 royally sucks. Beside unavoidable issues related to 64-bit in general (twice as big pointers, thus any pointer-heavy structure taking twice as much memory, thus cache lines), on x86 in particular it's a dirty hack.

To get slower than amd64, you'd need an ancient register-starved ABI that passes way too much on stack, can't use floating point efficiently, may not pass 64-bit arguments when you actually need them, etc -- ie, i386.

Compare this with a modern 32-bit ABI on x86 (ie, x32). An average program takes ~2/3 memory to run, speed depending on how much pointers you use, but +7% is typical, over 40% in certain cases.

On architecture families that were designed with 64-bit in mind, most of this benefit disappears, but on x86 sane 32-bit wins handily.

Re:why?

[TheRaven64]

I had a look in activity monitor and I have 3 32-bit processes running and I found 3. Two were part of novaterm, which I installed years ago to do HP TouchPad development and haven't used since HP abandoned WebOS, but which I apparently left installing some daemons. The remaining one was the Android File Transfer agent, because apparently I haven't updated Android File Transfer since 2012 and it doesn't auto-update. After a small cleanup, I am now running none.

There's actually only one 32-bit application that I do care about: WINE. There's no reason that WINE couldn't be made to launch 32-bit Windows apps as a 64-bit binary though: it already includes its own program launcher and thunks for calling from Windows libraries into host-system ones.

The benefit is not just saving a few GBs of system libs. It's not having to do QA on any 32-bit versions of software. Apple's 64-bit Objective-C ABI is very different to its 32-bit one (small objects are hidden in pointers, reference counts are embedded in isa pointers, and so on). Making sure that none of the 100MBs or so of Objective-C frameworks that they ship have different observable behaviour with the different pointer sizes is a significant testing overhead. It's also a noticeable memory overhead if you run one app that pulls in the 32-bit versions of all of the system libraries. Even just the small set that you need to link to for any GUI application that adds up to around 50MB of object code, which is not shared with any of the 64-bit processes and so consumes L1 icache and L2/L3 cache space, making everything else slower.

Re:why?

[TheRaven64]

Everyone who buys a Mac is paying to subsidise the continued maintenance and support of the 32-bit versions of system libraries. Very few people are actually using these libraries. You seem to want other people to subsidise your purchasing decisions either way.

Re:why?

[jellomizer]

The rumors mill is that Apple will be releasing a new chip to replace Intel. Changing chips with new instruction sets, breaks compatibility like nothing else.
I expect if Apple to switch chips they would want to keep backwards compatibility so they will have a converter for the previous binary format. So getting people off the old 32bit format will help prep them for the switch to the new chip.

Also to note Apple only had a small time with 32bit intel CPU. About a year or so. So unlike Linux and Windows there isn’t a mountain of software. There is just a small number that is 32bit only.

Re:why?

[TheRaven64]

Memory space has nothing to do with it. 64-bit means a lot more general-purpose registers, 64-bit registers (x86-32 uses pairs of registers for 64-bit operations and typically requires a stack spill for each one), and PC-relative addressing (makes anything that uses shared libraries faster). Less relevant for Apple, because they never supported anything older than a Core 1, but it also typically means being able to assume SSE.

In all except for a few rare circumstances, x86-64 code is faster than x86-32 code on the same processor (the same does not apply to all other 32/64-bit architecture pairs). On top of the underlying improvements, there are a number of 64-bit-only optimisations in Apple's Objective-C implementation (and Objective-C code accounts for a very large proportion of their total code). The class pointer has a load of spare bits at the top, so reference counts are stored inline there. Small objects can be embedded in pointers (including small ASCII strings, which account for a large proportion of dictionary keys and can significantly reduce memory usage and improve performance).

Oh, and it's worth noting that there was a very small window when Apple shipped 32-bit x86 machines. For the Mac Mini, February 2006 to August 2007. For the MacBook, May 2006 to November 2006. For the MacBook Pro, January 2006 to October 2006. The last version of OS X to support the 32-bit chips was 10.6.8, released 8 years ago and discontinued (no more support updates) in July 2011.

Most people buying x86 Macs around the transition held off until the 64-bit ones, because it was pretty obvious at launch that Apple would move to 64-bit quickly (the lack of 64-bit mobile PowerPC chips was one of the reasons for their switch to Intel). XCode was able to produce 64-bit binaries and 32/64-bit fat binaries prior to the Intel switch and most Mac apps moved to being 64-bit a long time ago.

Re: why?

[Anonymous Coward]

Actually, I am.

Re: why?

[Bert64]

Legacy unmaintained code is a significant security risk...

64bit is not a new thing, 64bit processors have been around for nearly 30 years and have been mainstream for more than 10, apple have not produced a 32bit mac for more than 10 years now, and they are just starting to deprecate 32bit support, so 32bit apps will continue to run and be supported for a few years yet.

If you're running software that hasn't been updated in such a long time then you should seriously be considering replacing it with something that is actively maintained for many reasons.

Re:why?

[Bert64]

The x32 ABI is part of amd64, most 32bit x86 software uses the i386 abi.

Re:why?

[TheRaven64]

Compare this with a modern 32-bit ABI on x86 (ie, x32). An average program takes ~2/3 memory to run, speed depending on how much pointers you use, but +7% is typical, over 40% in certain cases.

I'd be very interested in where you get those numbers from. I work on a research architecture that uses 128-bit pointers and we find that in most cases your DRAM traffic increases by under 10% going from 64-bit to 128-bit. A 7% performance delta sounds about what I'd expect, but 2/3 more memory doesn't. That implies that around 2/3 of your memory is pointers - our measurements indicate that for most workloads (including most of SPEC) it's closer to 10-20% and the number goes down for more performance-critical workloads because developers try very hard to avoid pointer chasing (because it doesn't play well with modern pipelines) in such code.

With my FreeBSD hat on, I did a little bit of analysis of the x32 ABI and concluded that it is better for most systems only if you don't use the x64 ABI for anything. The performance hit from reduced cache sharing between processes for common shared libraries was greater than the performance win from x32. This was the same result that Sun Research found on SPARC 20 years earlier: the 32-bit ABI was better if everything used it, but if you use 1-2 64-bit programs then you lose more then you gain.

This is even more true on something like macOS, where there's a big shared memory region where all of the common system libraries are pre-loaded and then accessed via a per-process offset (and where the kernel is set up so that all mappings of this region share leaf page table entries and so reduce cache pressure on TLB misses).

Re:why?

[Anonymous Coward]

Memory space has nothing to do with it.

Not quite "nothing", thank you.

64-bit means a lot more general-purpose registers, 64-bit registers (x86-32 uses pairs of registers for 64-bit operations and typically requires a stack spill for each one), and PC-relative addressing (makes anything that uses shared libraries faster).

I know. Just wrote a bit of 32bit assembly that keeps the entire program state in registers. It emulates a rather more simple stack machine CPU.

But yes, enlarging the register file is what brought the big improvement in speed. Apparently the "CISC but RISC underneath"-marketeering was so much bullshit and the register file is a big fat bottleneck on x86. The 64bit register width isn't even that important since you don't really need more for most office and other "consumer" tasks anyway. Certainly not since as soon as you do need more bits the task turns out to be one for which there already is some extension or other to do the heavy lifting. The many extensions in x86 don't use the general register file.

But really, that's hardly relevant. What this is about is having programs that you got as a 32bit binary that work but somehow aren't updateable. Of course, apple typically doesn't care and just tells you to "upgrade", to a competitor's application if you have to, regardless of its cost to you.

Oh, and it's worth noting that there was a very small window when Apple shipped 32-bit x86 machines.

They probably should have refrained from doing that. They could've gone full 64bit from the start and not have to slam the door later. A little thought beforehand, etc.

Most people buying x86 Macs around the transition held off until the 64-bit ones, because it was pretty obvious at launch that Apple would move to 64-bit quickly (the lack of 64-bit mobile PowerPC chips was one of the reasons for their switch to Intel).

"We can't have 64bit mobile PowerPC chips so we'll ship 32bit wintendo mobile chips instead." This makes no sense.

For PowerPC the register file argument doesn't hold, by the by. Which is really the only thing that causes a big win outside scientific computing for x86 going from 32 to 64bit, certainly if "memory space has nothing to do with it."

Anyway, all that is rationalisation to the net effect of being less responsible than they could be, and I'm saying, you don't get to shout at the users of your "ecosystem" if you created your "ecosystem" to be this way.

Re: why?

[phantomfive]

Games are an example of software that doesn't usually get updated, but you still want them to keep working.

Frankly I wish programmers like you (who don't have respect for backwards compatibility) would crawl into a ditch and die, but I don't get everything I want in this world.

Re:why?

[fgouget]

There's actually only one 32-bit application that I do care about: WINE. There's no reason that WINE couldn't be made to launch 32-bit Windows apps as a 64-bit binary though: it already includes its own program launcher and thunks for calling from Windows libraries into host-system ones.

Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out. For instance take the CreateProcess() API. It takes no fewer than 7 pointers as parameters. Not only that but 3 of those point to structures that themselves contain at least one pointer to another structure. Also every time an API returns a pointer to some data, Wine would have to ensure that pointer fits into the 4 GB address space of the 32 bit Windows process. And then you have callbacks.

For a lot of these issues you cannot just automatically generate the thunking code either. And with over 80 000 APIs, not counting COM APIs, and not counting Windows messages (e.g. WM_CREATE comes with a pointer to a structure which itself contains 3 other pointers) you have literally tens of thousands of reasons why WINE can't be made to launch 32-bit Windows apps as a 64-bit binary without a huge undertaking.

Oh. And on OSX Apple also decided to overwrites a CPU register that Win64 applications expect to remain untouched. If I remember correctly, as a result support for 64 bit Windows applications assumes they will only use TEB slots that happen to not be used by OSX and Apple neither confirmed nor denied that this would remain that way, meaning Wine's 64 bit support is already hanging by a thread on OSX.

Despite these obstacles there's already pretty clever exploratory work towards running 32 bit Windows applications in 64 bit processes. But those are still a long way off and it's not yet clear if they will be viable yet.

Really, not only has Wine a huge task ahead of it reimplementing the Win32 API, but it also has to deal with all sorts of crap from Microsoft competitors: Apple not lifting one finger to help with 64 bit support, Apple dropping 32 bit support, Apple letting OpenGL just die, Debian having shitty multiarch support, Linux distributions talking about dropping 32 bit support, Nvidia and AMD producing crappy Linux and OSX GPU drivers. With all these obstacles it's a miracle Wine has gone as far as it has. And in the meantime everyone, governments included, depends on a single supplier, Microsoft, to run all their in-house (Windows) applications.

Re: why?

[Freischutz]

Everyone who buys a Mac is paying to subsidise the continued maintenance and support of the 32-bit versions of system libraries. Very few people are actually using these libraries. You seem to want other people to subsidise your purchasing decisions either way.

They aren't going to get cheaper when they drop support, you asshole, they're just finding an excuse to increase profit margins because they can

I don't want to pay to subsidize your roads or oil use when I use a bike, but I still fucking do it, you self centered man-child

"I shouldn't have to pay for anything I don't personally gain from! Waaaaah" Jesus you people are stupid

Apple obsoletes stuff all the time and they aren't even close to being the worst offenders in that category by any measure. You kind of sign up for that when you buy a macOS or iOS based product. They will also move stuff around and redesign the UI completely at monotonously regular intervals, add features that confuse the hell out of conservative users such as multiple desktops, and totally useless ones that you end up using all of the time, like spotlight and track pad gestures. They will also offend you to the core of your being by aggressively deleting obsolete or bulky connection ports like RS232, USB-A, DVI, Displayport, etc... and going off on wild and not always successful experimental tangents like Thunderbolt. If you don't like that kind of environment and yearn for hardly ever changing stability you should buy a Windows PC, Microsoft only intermittently confuses or offends you with new features whereas this is a constant state of affairs with Apple and the engineers at Microsoft are true masters at backwards compatibility (and that's not a snide jab and MS, they really are good at pretty seamless backwards compatibility).

P.S. you might want to consider dropping the profanity from your posts in the future, it ads no weight to your arguments, at least not here where most people tend to value logical argumentation over potty mouth. The only thing you achieve by using the word 'asshole' is making everybody around here who reads your post think you are the asshole.

Re:why?

[TheRaven64]

Totally irrelevant. Windows ran on 32-bit x86 systems since 1993 (NT 3.1) and 32-bit was the most common version of Windows since late 1995. Mac OS X shipped 32-bit x86 on laptops for about 6 months, low-end desktops (Mac Mini) for about 18 months and on high-end desktops never. The last version of OS X to run on 32-bit processors was released in 2009 and reached EOL in 2011. Mac OS X never ran on a Pentium 4 and it shipped on Core 1 (the only x86 processors that it ever shipped on) for a very limited period.

Re:why?

[TheRaven64]

Yeah, but x32 linux is faster for pretty much everything than amd64 or i386, so it's not the "64-bit" that makes it faster, it's the "extra registers and instructions" Ditching the 64 bit pointers makes programs faster.

A large part of the Apple software stack is Objective-C. On 32-bit platforms, every object has a 32-bit reference count, which is stored in a look-aside table (which I think is an llvm::DenseMap now). Every reference count manipulation (which happens on almost every heap assignment of an object pointer) requires locking the table (or, at least, one of the tables - I think there are 8 on the desktop builds), looking up the refcount indexed by the object, and modifying it. On 64-bit platforms, Apple stores the reference count in the top 16 bits of the class pointer. Updating it is an atomic instruction.

When you create an NSString or NSNumber instance on 32-bit Apple platforms, you are creating an object on the heap. This requires a reference count in the table if it is ever retained (i.e. a pointer to it is stored on the heap), a 32-bit class pointer and at least 32 bits for the value, typically more. This space is probably rounded up to 16 bytes, for alignment. When you create an NSNumber instance or a short NSString on 64-bit Apple platforms, the value is embedded in the pointer. Creation is some bit twiddling in a register, no memory allocation. When I profiled some desktop applications some years ago (before Apple implemented this optimisation), I found that around 10% of all object allocations were strings that could be stored in a pointer. That saving alone is worth the 64-bit switch for most Objective-C applications.

Most JavaScript implementations see similar benefits on 64-bit, though from quite different implementation techniques.

Short lived

[Bert64]

The 32bit x86 version of MacOS was very short lived and was arguably a mistake...
Availability of 64bit PPC hardware to run OSX predates the 32bit x86 version, so they actually took a step backwards. The only non 64bit x86 macs are the very first model laptops, IIRC even the first gen mac pro was 64bit from the start.

Apple should never have supported 32bit x86 at all, and should have moved directly from PPC64 to x86_64.

Re:What is the incentive for Devs?

[TheRaven64]

Any macOS dev who is actively developing their code will already be developing a 64-bit version. XCode has defaulted to fat binary (32/64-bit) builds since 2006 and on all versions of OS X since 2011 and any older version on a 64-bit chip the system will launch the 64-bit version in preference. You have to explicitly opt out of 64-bit support. It's far more common for developers to not bother with the 32-bit version.

Absolutely, but ....

[King_TJ]

FWIW, I *do* think Apple has a tougher time justifying these changes to its users for a couple of reasons.

1. A lot of people paid a premium to buy a Mac in the first place because of the promise that they have a longer useful life than their Windows PC counterparts. Traditionally, that held true because with them "playing by their own rules", development was based around making software work with what Apple made available. (You couldn't arbitrarily decide, for example, that you didn't like how slow a whole series of graphics cards had become and set your hardware requirements higher. If Apple didn't BUILD a new Mac with a better graphics card, you were stuck coding for the ones already out there.) This did have the advantage that it often led to a better quality of programs, since developers had more time to focus on fixing bugs and optimizing the code for the available hardware.

2. In recent years, I think there's been a pretty strong market for trying to breathe more life into the last few generations of Macs. As Apple has switched to a practically non user-serviceable, non-upgradable design across the board, there's some backlash from the community. After all, from 2006-2012, Apple sold the VERY expandable Mac Pro workstations, which can now be bought for as little as $100 or so each. In other cases, like the MacBook Pro laptops? It's been a long time since Apple offered one with a 17" screen -- but some people still really want that feature. So they hang onto to the last of the models that had one.

Granted, all of those Mac Pro workstations were 64-bit capable, as were the 17" MacBook Pro laptops and any older iMac going back as far as the Core 2 Duo CPU in them. But there's at least the FEAR that Apple is accelerating its intentions of obsoleting everything that's not a current model. (The 2006 and 2007 Mac Pro workstations were arbitrarily cut off from OS X support for versions newer than Lion, even though with some hackery - they can run the much more recent El Capitan version just fine.)

Re:Absolutely, but ....

[CastrTroy]

A lot of people paid a premium to buy a Mac in the first place because of the promise that they have a longer useful life than their Windows PC counterparts

I don't know where you got this idea. Apple has a long history of breaking compatibility with older software. This happened when they moved to OSX. They did provide some support for older software but that support eventually died out. Then again when they switched to X86 from PowerPC. Again they provided some support for the switchover, but eventually that died out as well. While not all older Windows software will work on newer machines, there is quite a good history of being able to run older software on new machines in the Windows. I have a PC from 2005 that still runs modern versions of Windows completely fine. You won't fine any Macs from 2005 that are still supported in any way.

Re:Circular argument...

[nctritech]

The cloud integration into everything drives me insane. I don't want Pocket in Firefox, OneDrive in Explorer, iCloud on Apple EVERYTHING, or whatever trash can privacy violating thing Ubuntu has decided is a good idea to force in the OS and turn on by default this week. Why does every music player need to have a remote control HTTP server inside of it? Why do TORRENT CLIENTS have remote control HTTP servers in them?! Even worse are the so-called "IoT" devices that are all "normal object except Bluetooth-connected" that will stop receiving firmware updates and will never even be opened up, sometimes rendering them merely insecure while other times rendering them 100% non-functional. I can understand some of the functionality but it seems like we're rapidly moving towards a future where our toilet paper will have Bluetooth and report on the fiber content of your freshly wiped ass butter in real time.

When I explain to non-technical people that "cloud means you store it on someone else's computer and trust them to not lose it" and tell them about the T-Mobile Sidekick data loss disaster they tend to agree with my rationale for having a local backup on an external hard drive and not just shoving everything into Dropbox or Carbonite like they're magic bullet backup solutions. Hell, even Carbonite has a built-in "do a local backup too" function.

Re:about time

[enjar]

I was really hoping they would have taken 32-bit out behind the barn and ended it with Windows 10, but they didn't. My company dropped support for 32-bit Windows a few years ago. Even with PAE and other tricks it was consuming an inordinate amount of people's time and resources in terms of regular build failures due to resource limitations, and our customers had largely moved on since the work they used our software for would rapidly exhaust win32's limits, anyway. Microsoft introduced a 64-bit variant for Itanium in 2001 and a 64-bit XP/Server 2003 x86_64 variant in 2005. Drivers were a bit patchy to find, but by the time Vista came around and certainly 7, 64-bit on Windows was just fine. So at this point we are well into a decade past Vista ... please kill 32-bit Windows ... please. Set up a memory garden and build a monument to it in Redmond ... but dear God let it become a happy memory.