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 653507
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by ssokolow
by Alfman on Mon 5th Feb 2018 05:04 UTC in reply to "RE[3]: Comment by ssokolow"
Alfman
Member since:
2011-01-28

fmaxwell,

I understand, it is good that your car manufacturer is giving you a chance to repurchase or just throw away music you've paid for on cassettes and 8-track tapes.




Apple may not wish to support 32bit software, that's their prerogative. 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). Some features like segments were removed, but these weren't generally used in 32bit code (they were used by 16bit DOS eons ago). One way to make your analogy more accurate would be for your car manufacturer to stop supporting audio CDs but to continue supporting MP3 CDs. In other words, the hardware is still physically capable of supporting the legacy format, but your manufacturer chose not to.


From an x86 hardware perspective the 32bit and 64bit components can't be fully separated because 64bit registers and mov instructions are an extension of 32bit ones and not a replacement! So even 64bit x86 compilers can still generate 32bit instructions/addresses/registers depending on the software requirements.

Here is a very brief overview:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/x...

Edited 2018-02-05 05:13 UTC

Reply Parent Score: 5

RE[5]: Comment by ssokolow
by fmaxwell on Mon 5th Feb 2018 12:18 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