Linked by Thom Holwerda on Sat 3rd Feb 2018 14:15 UTC, submitted by Drumhellar
Mac OS X

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.

This is good. I would prefer other companies, too, take a more aggressive approach towards deprecating outdated technology in consumer technology.

Thread beginning with comment 653523
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Comment by ssokolow
by fmaxwell on Mon 5th Feb 2018 12:18 UTC in reply to "RE[4]: Comment by ssokolow"
fmaxwell
Member since:
2005-11-13

But your analogy is a bit off. 8 track->cassette->CD is replacing one technology with a new & incompatible technology. This doesn't match the situation for x86 hardware, since 32bit->64bit is largely the same technology with new extensions (like larger registers).

That's like contending that x86 Linux binaries should run on x86 Windows computers because they use the same hardware "technology." This is about the OS, not the CPU. It's about Apple deciding to retire a lot of code in their OS by dumping support for 32 bit apps. You can talk in vague terms about how things are "largely the same technology," but the 32 bit apps can't run any more and it's not because Apple incorporated something in their OS to block execution of 32 bit apps that would otherwise run without a problem.

P.S. Thanks for the link, but I've been developing in assembly since 1980.

Reply Parent Score: 1

RE[6]: Comment by ssokolow
by Alfman on Mon 5th Feb 2018 14:40 in reply to "RE[5]: Comment by ssokolow"
Alfman Member since:
2011-01-28

fmaxwell,

That's like contending that x86 Linux binaries should run on x86 Windows computers because they use the same hardware "technology."


Or, to stick with your analogy: a car stereo manufacturer choosing to support MP3 & WMA, but not OGG.

I'm not sure if you knew this but MS actually does support Linux binaries on Windows 10:

https://docs.microsoft.com/en-us/windows/wsl/interop


This is about the OS, not the CPU. It's about Apple deciding to retire a lot of code in their OS by dumping support for 32 bit apps.


Yes, exactly. Obviously the hardware still supports 32bit code.

You can talk in vague terms about how things are "largely the same technology," but the 32 bit apps can't run any more and it's not because Apple incorporated something in their OS to block execution of 32 bit apps that would otherwise run without a problem.


Hypothetically users could provide their own 32bit libraries even if apple does not, however this could only work if apple did not take steps to block 32bit software from the application loader.


IMHO there is a more fundamental problem for users than 32bit versus 64bit, which is being dependent on proprietary software that cannot be updated/ported to new architectures in the first place.


P.S. Thanks for the link, but I've been developing in assembly since 1980.


Awesome, I'm always happy to meet other assemblers ;)

Reply Parent Score: 3

RE[7]: Comment by ssokolow
by fmaxwell on Mon 5th Feb 2018 20:33 in reply to "RE[6]: Comment by ssokolow"
fmaxwell Member since:
2005-11-13

Or, to stick with your analogy: a car stereo manufacturer choosing to support MP3 & WMA, but not OGG.

True. And not including code to debug and play .ogg, .au, .ape, .flac, .tta, and so on makes sense because each implementation is yet another place for bugs to creep in and more code to support.

And, unlike a computer, a car stereo head unit generally doesn't have issues with remotely exploitable security flaws exposing your valuable data and personal information, so my analogy is getting stretched thin.

I'm not sure if you knew this but MS actually does support Linux binaries on Windows 10

My fault for being sloppy. I was referring to GUI apps rather than command line, character-based. But good link.

Hypothetically users could provide their own 32bit libraries even if apple does not, however this could only work if apple did not take steps to block 32bit software from the application loader.

We could have 32 bit dynamically linked libraries, or DLLs, that app installations could place in system directories! No need to worry about namespace collisions or versioning, since we can trust the app developers to 'do the right thing.' I think we have a winner!

IMHO there is a more fundamental problem for users than 32bit versus 64bit, which is being dependent on proprietary software that cannot be updated/ported to new architectures in the first place.

My first personal computer (disk-based) was a CP/M-80 system. Although I had source for most of the software on it, I can't think of any that I've ported to my current system or even the systems in-between. To cite one example, I don't really need the source code to the programmer's text editor I use -- I just need a viable alternative on the platform on which I will be working.

I suspect that's the case for many people. If the elimination of 32 bit app support on MacOS means that they can't play the Donkey Kong knock-off that they bought from some kid in Latvia in 2007, I'm okay with that.

Reply Parent Score: 1