
Apple starting to alert users that it will end 32-bit app support on the Mac - bbrunner
https://techcrunch.com/2018/04/11/apple-starting-to-alert-users-that-it-will-end-32-bit-app-support/
======
bonoetmalo
Could somebody point me to a technical explanation of why it's sometimes non
trivial to just compile your app against x86-64 and call it a day?

For example, something I encounter every day is Visual Studio and it's helper
processes being 32 bit. Because Visual Studio regularly, even on the latest
15.7 preview shits the bed with OutOfMemoryExceptions on our large solution,
I'm inclined to rage "why don't they just make it 64 bit? If it could just
load more into memory it could get past this indexing hurdle and give me back
the UI". But I also understand that if it was that simple they would have done
it by now.

Something else, that I understand more, is the LabVIEW RT and FPGA modules
only working on 32 bit LabVIEW. I would assume it's related to the compiling
and deploying to the 32 bit ARM/x86 RT target.

~~~
makecheck
The main issue would be that 64-bit may _cause_ an app to use more memory.
Every pointer doubles in size, the alignment of a structure containing a
pointer may grow, etc. Basically, if you needed a lot of structures allocated
and they all grew, your memory use becomes noticeably bigger.

Sometimes legacy code can make assumptions about pointer size. These hacks
were more common in the days of porting older systems to 32-bit but it could
still happen moving to 64-bit.

If there’s code that tries to manually populate the bytes of data structures,
sometimes bugs appear when the target field size changes (e.g. somebody ends
up not initializing 4 of the 8 bytes in a now-wider field).

In the case of Apple, the huge pain will be their decision to not port all of
Carbon to 32-bit (despite Forstall getting on stage years ago and stating that
Carbon was going to be 64-bit “top to bottom”, it never happened). This can
mean addressing a whole pile of nothing-to-do-with-64-bit-whatsoever problems
before even _starting_ to solve 64-bit problems.

~~~
microtherion
> despite Forstall getting on stage years ago and stating that Carbon was
> going to be 64-bit “top to bottom”

This is the second time I've seen you make that claim. Can you, by any chance,
recall on which occasion he said this (or dig up the exact quote)? AFAIK the
plan was always to use the 64 bit transition as an opportunity to shed
deprecated APIs, so to imply otherwise in public would have been rather
irresponsible.

~~~
wlesieutre
I don't know about that particular quote, but this has a photo of the WWDC
side claiming 64-bit Carbon and Cocoa, so that was definitely the original
plan

[https://www.wired.com/2007/06/leopard-won-t-
support-64-bit-c...](https://www.wired.com/2007/06/leopard-won-t-
support-64-bit-carbon-apps/)

~~~
microtherion
Hmm, that is plausible. I stand corrected.

------
wheels
This is particularly heinous for those of us that do music production. A lot
of plugins are orphaned at some point (meaning the developers no longer update
them), and if you created a piece of music with those plugins (instruments,
effects), if you can't load those plugins, you can't open old files.

I often open up sketches from several years prior and consider working more on
them. I keep a full 32-bit stack of music stuff left installed exactly for
that reason. Usually, if I open them up, then I'll go ahead and move them over
to 64-bit semi-equivalents, but that's difficult if you can't even hear what
you were doing with the old one.

~~~
beedogs
Yep. I'm not excited about the prospect of moving back to the PC for making
music, but it looks like that's what Apple want me to do.

~~~
promeus
This, or go with idea that for some years ahead you can work with El Capitan
on a old hardware. Windows for me is dead end also, until someone in pro
industry realizes that its time to move to Linux. Apple is mobile and
entertainment company now. Microsoft wants AI/Cloud. The logical answer is
Linux.

~~~
SyneRyder
_> until someone in pro industry realizes that its time to move to Linux_

Some already are. When I bought my copy of Pianoteq 6 [1], I was surprised to
see they also offer a Linux version (and even a Raspberry Pi version). The DAW
I use called Renoise [2] has a Linux version, and the JUCE [3] development
framework common to many VST plugins also has Linux support.

Listening to podcasts like Sonic Talk [4], I'm mostly hearing about studios
switching from Mac back to Windows, but they have been talking a lot more
about Linux too.

[1] [https://www.pianoteq.com/](https://www.pianoteq.com/)

[2] [https://www.renoise.com](https://www.renoise.com)

[3] [https://juce.com/](https://juce.com/)

[4] [https://sonicstate.com/sonictalk](https://sonicstate.com/sonictalk)

~~~
tomduncalf
Other notable big(ish) name DAWs with Linux versions include Bitwig (quite
similar to Ableton Live) and Tracktion

------
acomjean
A lot of apps never made the switch on ios. I have some useful ones that were
orphaned. I feel like only the mac original intel chips were core2 32bit one,
and those long lost os support.

Its weird that dos (box) and old windows programs are often still runable, but
somehow mac applications just don't age nearly as well.

I really think if some linux distros can get it together and get some good
application support, now is the time for them on the desktop/laptop.

going to Apple-Menu->about this mac->system report ->software applications

will show a list of applications with the right most column indicating 64 bit
support. 95ish % of mine are currently 64 bit

~~~
npunt
Microsoft and Apple have different approaches to backwards compatibility based
on the markets they're in. Microsoft makes most of their money on enterprise,
whereas Apple makes most on consumers. Enterprise values running old apps,
consumers value running today's apps. Each makes sense for their market... and
desktop Linux doesn't make sense for either.

~~~
xenadu02
Backwards-compatibility is an interesting story on the mac. The Objective-C
ABI on 32-bit macOS is what is called the "fragile" runtime because it has the
fragile base class problem. Originally Objective-C had the same design flaw as
C++: the ivars of every class had to be in the header for all to see so the
compiler could rely on the binary layout. A subclass' ivars would be offset by
the compiler by examining the layout of every superclass, then baked into the
binary.

In the modern (all iOS and 64-bit macOS) runtime the ivar offsets are patched
up at runtime so the layout of classes (including base classes) can change
without breaking compatibility.

Working around the limitations of the 32-bit Objective-C runtime imposes
significant costs, it is far from a simple recompile with a different pointer
size. It also adds a lot to the size of the installed OS.

~~~
npunt
It's kind of sad we're in this state in 2018 because Apple launched 7 low end
machines [1] back in 2006 that didn't have 64-bit support. Even though those
are long gone, their software support legacy remains. Apple could have
transitioned directly to x64 and saved themselves the headache (afaict, maybe
these problems would have persisted?).

[1] [http://lowendmac.com/2006/core-duo-macs/](http://lowendmac.com/2006/core-
duo-macs/)

~~~
mrpippy
Apple couldn't have gone straight to 64-bit apps on Intel--the OS and
frameworks just weren't ready yet. The Intel machines shipped starting with
10.4.3, which only supported 64-bit command-line apps/daemons. Only with 10.5
(released in late 2007, 18 months after the first Intel machines) were full
graphical 64-bit apps supported (on both ppc64 and x86_64).

~~~
wtallis
Firmware was an issue, too. The first generation of Macs with 64-bit
processors still used 32-bit EFI and booted a 32-bit kernel that could run
64-bit applications.

~~~
mrpippy
True, it wasn't until 10.6 that a 64-bit kernel was available, and only newer
machines got to use it.

[https://arstechnica.com/gadgets/2009/08/mac-
os-x-10-6/5/](https://arstechnica.com/gadgets/2009/08/mac-os-x-10-6/5/)

~~~
yuhong
I had a blog article about the entire mess that was often confused (there was
actually three modes): [http://yuhongbao.blogspot.ca/2009/09/mac-os-xs-64-bit-
modes....](http://yuhongbao.blogspot.ca/2009/09/mac-os-xs-64-bit-modes.html)

------
ibiza
I suppose dropping x86 support makes for one less architecture for Rosetta II
to support.

~~~
seabrookmx
Rosetta II being the x64 -> ARM translation layer for when they start putting
the AX chips in Macbooks?

HP already has it's Snapdragon convertable out that has Windows 10 x86
emulation. But surprisingly this is only _32-bit_ not 64. Looks like
performance is understandably poor as well.

I'd expect Apple to take their usual strategy and wait a bit until chips are a
little faster/they have a more mature emulator before they make the switch.

Interesting times though!

~~~
jammi
I actually expect Apple to implement some "emulator-acceleration instructions"
into their own chips and get excellent (almost as good, as good or better)
performance once they switch, as always, because otherwise people just won't
switch en masse.

~~~
ksec
I dont think Intel will allow that to happen without some patents issues.

~~~
rsynnott
x86 is now 30-40 years old depending on how you measure it. Even "modern" x86
(post Pentium Pro) is over 20 years old. An awful lot of the patents have
expired.

~~~
ksec
X86-64, that is the most important one.

~~~
jammi
It's not even by Intel; it's by AMD and they did nothing to prevent Intel from
using it.

~~~
seabrookmx
Intel did license it from AMD IIRC.

------
gargravarr
Can't imagine why this push is necessary. One of the primary advantages of
x86_64 as opposed to other 64-bit architectures is that normal 32-bit
applications run natively with no performance hits. As others notice, this is
likely going to serve no other purpose than to make abandoned 32-bit
applications completely unusable.

Of course, it could also be related to Apple's intention to switch to ARM
chips in the near future, and getting everything on consistent 64-bit to aid
the porting effort. I can't imagine the developers are going to enjoy low-
level mapping of 64-bit x86 instructions to 64-bit ARM though...

~~~
saagarjha
> I can't imagine the developers are going to enjoy low-level mapping of
> 64-bit x86 instructions to 64-bit ARM though...

Why would the average developer even have to care?

~~~
gargravarr
I meant Apple's developers.

------
jnwatson
I recently lost a bunch of iOS apps, some 8 years old, due to the ABI cutoff.

I don't have the ecosystem tie-in that I used to have. What good is owning a
bunch of apps if you can't use them?

~~~
inapis
8 years is quite a bit of time in the technology space. There's no point
holding back the rest of the ecosystem if some developers have abandoned their
apps.

------
shmerl
Does it mean macOS users won't be able to play 32-bit games in Wine anymore?

~~~
sitharus
No, it means MacOS will no longer have a 32-bit runtime but this does not
prevent the CPU executing in 32-bit mode - just that all system calls have to
happen in 64 bit mode.

Wine will have to be a 64-bit application linked to the 64-bit libraries and
do a bunch of thunking and mode switching, but it already does this to support
16-bit applications.

I have no idea how easy this is but the the OS already does it to support
32-bit applications running on the 64-bit kernel.

~~~
shmerl
When Wine runs 32-bit application, it links against 32-bit libraries,
including OpenGL. So how would that work in pure 64-bit system? 16-bit is
really some special case, I don't know how Wine is doing it, but I suppose it
does some special translation.

~~~
sitharus
The same way those 32-bit libraries call the kernel now - they marshal the
call to 64-bit land. A lot of the user space is compiled separately for
performance and to maintain ABI compatibility so this would have to be taken
up by a third party. I would expect to see a slowdown but it depends on the
exact nature of the changes.

------
EamonnMR
There goes Ambrosia's back catalogue.

------
ersh
Well at least this time they alert. Support for Universal binaries was dropped
silently.

~~~
saagarjha
> Support for Universal binaries was dropped silently.

Since when? I have universal binaries that run fine on my computer.

------
Doctor_Fegg
This will be what finally moves me away from Adobe software.

I use one Adobe app: Illustrator CS5. My needs are fairly specialist and I
haven't needed any new features introduced since CS4 (2008; multiple
artboards, finally).

Adobe's only upgrade option is £240pa for a single-app subscription.
Fortunately, alternative drawing programs have come on a long way since CS5,
so I'll almost certainly jump ship to one of those.

------
gaius
It seems like only yesterday Macs were 24-bit and we were all busy getting
“32-bit clean”

------
beedogs
For the past few years, Apple have been doing everything they possibly can to
get creative professionals to leave their platform.

~~~
Razengan
I'm a creative professional and I, along with other people I know, still
prefer to remain on Apple platforms.

I guess now you have to argue about and form a consensus on the definition of
"professional" huh?

------
graycat
So Apple is dropping 32 bit computing? Hmm ....

Gee, I'm building, configuring a server based on an Asus motherboard and the
AMD FX-8350 processor, 8 cores, 64 bit addressing.

Surprise! I discovered that Windows XP 32 bit Professional SP2 (service pack
2) will install and run! It sees all 8 cores, and the version of Microsoft's
TASKMGR plots the activity separately on each of all 8 cores. It also sees the
full 16 GB of main memory and is willing to use 2 GB of it with 5 GB of paging
space.

And I discovered that the Western Digital (WD) Data Lifeguard Tools CD, IIRC
version 11.1, boots and runs! This is amazing since what boots is old DOS! The
DOS part will boot from a CD/DVD USB (universal serial bus) drive, but then
the WD software doesn't run. But if boot from a SATA (serial advanced
technology attachment) CD/DVD drive, then the WD software does run.

If have the Windows version running and put the WD CD in the SATA drive, then
the WD software appears to run as a Windows application!

My most important application is 32 bit editor KEdit, and I've discovered that
it runs fine on Windows 10 64 bit Home Edition on an HP laptop with a 64 bit
Intel processor with two cores and 4 threads.

So, lesson: With Windows, AMD, Intel, and ASUS, a lot of 32 bit computing
still works! Sorry Apple!

My first intention installing Windows XP was just to run some experiments on
using the WD Tools to backup and restore a bootable partition, but I've since
discovered that apparently my trusty old copy of Nero for CD/DVD
reading/writing that I long used on XP appears to install on Windows 10 on the
HP laptop but as far as I can tell won't read or write CDs or DVDs. So, for
routine reading/writing CDs and DVDs, apparently I should keep a bootable
partition with XP.

Sorry, Apple, 32 bit computing won't go away soon: The reason is standard and
old in computing -- there is a lot of old software people very much still want
to run.

~~~
gh02t
Apple is a bit special though, since their hardware and software go together.
They don't sell 32 bit Macs and have never emphasized backwards compatibility
like Windows (or Linux) has and quite often they have emphasized the opposite.
Supporting 32 bit is dead weight for them from a business perspective and has
been for a while, this shouldn't be a shock for their users.

~~~
LeoPanthera
> have never emphasized backwards compatibility

This is mildly misleading. Apple emphasizes backwards compatibility,
_temporarily_. 68k apps ran on PowerPC systems. Classic MacOS apps ran on OS X
systems. PowerPC apps ran on Intel systems.

Apple is a master of architecture shifts - they've had so many of them! But
the compatibility is always temporary. Enough for customers to get their apps
shifted over.

~~~
jammi
They also learned from their first architecture shifts, which didn't go all
that well. Apple II to Apple III flopped early. Apple II to Lisa was
nonexistent. Apple II to Mac could've been a 1984 to 1985 thing if executed
well, but instead it took until 1993 for Apple II to be killed. Lisa to Mac
was just recycling the old hardware for the new OS via MacWorks.

~~~
LeoPanthera
Don't forget that for a while you could buy an Apple-IIe-on-a-card that went
inside your Mac and let you run Apple II software.

[https://en.wikipedia.org/wiki/Apple_IIe_Card](https://en.wikipedia.org/wiki/Apple_IIe_Card)

------
bangonkeyboard
I'm not installing a version of macOS that can't run QuickTime 7.

~~~
LeoPanthera
I work with video, particularly in "legacy" formats, regularly. There's
nothing I used to do with QuickTime 7 that I can't now do with ffmpeg.

------
malkia
I haven't checked what version Visual Studio (not Code) is on the Mac, but
good heavens it might be the only 64-bit Visual Studio nowadays :)

------
ksk
What is the point of an OS if not to run the software the user has purchased?
I don't care, and more importantly don't want to care at all about the OS
beyond it being a launcher for software that allows me to make money. Such a
bizzare approach from Apple to reducing the user to an open wallet willing to
repurchase software that already works. Also with Apple forcing the user on
the rolling release treadmill, its rather annoying that one can't simply stay
on a stable version.

~~~
armadsen
There’s nothing stopping you from keeping your machine running the same
version of the OS you’re on now. It will continue to run fine indefinitely,
and should run all the software you use now.

Surely Apple is allowed to release updates to their OS that eventually break
old software at some point. Or do you expect Mac software you bought in 1984
to continue run on the current OS?

~~~
hvidgaard
> do you expect Mac software you bought in 1984 to continue run on the current
> OS?

That is to some extend how it works in Windows land. It was not until 64bit
was a thing that they removed support for 16bit programs, and there is still
many ways to run them.

Everyone that cares about backwards compatibility just needs to read this
[http://ptgmedia.pearsoncmg.com/images/9780321440303/samplech...](http://ptgmedia.pearsoncmg.com/images/9780321440303/samplechapter/Chen_bonus_ch01.pdf)
to get an idea of the history MS has of backwards compatibility.

~~~
ridiculous_fish
Microsoft's 64 bit transition was more awkward with more compatibility breaks,
compared to Apple.

Microsoft sold separate Windows 32 bit and 64 bit versions, under different
SKUs. The 64 bit version broke compatibility with 32 bit drivers, but not all
software would work on 32 bit, so it was important to know which version you
had. Many computers advertised as 64 bit were sold with 32 bit Windows, so it
was possible to download an incompatible app version. It was a confusing time.

Apple had only one SKU. Applications had 32 bit and 64 bit versions in the
same binary, so there was only one version to download. The kernel supported
64 bit addressing and 32 bit drivers, so there was no hardware compatibility
break. It was invisible to users.

~~~
hvidgaard
I agree completely, but that doesn't change the fact that non-kernel software
backwards compatibility is very high priority for Microsoft.

I find it a bit dishonest to claim MacOS did so much better without mentioning
that they have a fraction of the hardware to support, compared to Windows.
When the different hardware combinations are not greater than something you
can setup in a warehouse, it's straightforward to test them all.

------
andrea_sdl
I've got an old core duo (32 bit) iMac which is still working fine despite the
old age (I think it's a late 2009). My small brother use it to navigate the
web.

The sad thing is that it became useless with OSX. Safari couldn't be updated
nor any browser, thus leading to the inability to browse the web because of
https certificates compatibility.

I had to install (with a lot of tricks) linux and it works flawlessy.

It's sad to see that a working computer has become obsolete in only 10 years,
and while I will probably continue use Apple products I feel like there
something _wrong_ with this. That's one of the reason I am worried about
buying an apple watch. Obsolescence.

All in all I get it and I know that it'll probably pay off for them, just like
it did with the dvd player removed, but it'll take time (for me) to get used
to the fact that, at least on the apple ecosystems, things last more than
usual, but they also become useless more than usual.

~~~
polpo
On the other hand, it is a bit crazy and impressive that OS X/macOS has had to
support 32-bit x86 binaries for >12 years because they sold 32-bit Core Duo
machines from January 2006 (introduction of Core Duo iMac) until August 2007
(replacement of Core Duo Mac Mini with Core 2 Duo version). 12 years of binary
support because they sold 32-bit x86 CPUs for 20 months.

~~~
andrea_sdl
Yes. Indeed, and as I wrote I can’t blame their choice

