|Apple prepares macOS for discontinuation of 32-bit app support|
|By Thom Holwerda, submitted by Drumhellar on 2018-02-03 14:15:01|
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.
|Comment by Kroc|
|By Kroc on 2018-02-03 14:48:33|
|I'm certain this is one step toward moving away from Intel chips. A chip that has no 32-bit hardware at all is going to require a significantly less number of transistors and therefore less heat / more room to do something else. It's also much easier to emulate or transpile the Intel code if you're only dealing with one (much cleaner and newer) arch.|
|- Score: 3|
|RE: Comment by Kroc|
|By Kochise on 2018-02-03 14:58:37|
Well, if you delete 32 bits from 64 bits, you actually get... 32 bits. I bet these legacy 32 bits are the foundation of the current 64 bits architecture. So you better not ditch it out just because to woke up on a left foot. |
Btw, if you're really into going to get rid of such "nuisance", you also better get rid of all these useless emulation layers. Out DOSBox, out Mame, out 32 bits Qemu, out old and retro tech. Welcome all new shiny 64 bits God !
|- Score: 7|
|RE: Comment by Kroc|
|By Brendan on 2018-02-03 15:25:19|
> I'm certain this is one step toward moving away from Intel chips. A chip that has no 32-bit hardware at all is going to require a significantly less number of transistors and therefore less heat / more room to do something else. It's also much easier to emulate or transpile the Intel code if you're only dealing with one (much cleaner and newer) arch.
For 80x86, the only major difference (for user-space code) between 32-bit machine code and 64-bit machine code is that 64-bit machine code is allowed to have "REX prefixes". In other words, deprecating 32-bit apps wouldn't make any difference for application emulators - they'd still need to emulate all 32-bit instructions to make 64-bit code work (excluding an extremely small number of instructions that were recycled to make room for REX prefixes - mostly one "inc" and "dec" group of opcodes).
The reason Apple is deprecating 32-bit applications is much more likely to be related to the cost of maintaining a compatible kernel API and shared libraries.
|- Score: 9|
|RE: Comment by Kroc|
|By teco.sb on 2018-02-03 15:47:50|
As someone who has done both x86 and x86-64 assembly programming, I can tell you that is not the case. Even in long-mode, the AMD64 additions still seems to favor 32-bits operations over 64-bits ones. |
Instructions are shorter (a function of x86's variable instruction size) when you work on 32-bit registers and instructions referencing the extended registers (r8-r15) require an extra byte, making them awkward. As an example, in long-mode adding 2 32-bit registers is only a 2-byte instruction, but requires 3-bytes for the same operation on 64-bit registers. That's a 50% increase in code size for something you may or may not need.
I think the problem with supporting 32 and 64-bit applications is in the syscall mechanism. If you take a look at Linux's syscall numbers, you will notice they are completely different for each architectures. This is true for every kernel (as far as I know). So in order for the kernel to be able to run a 32-bit compiled program in a 64-bit kernel, it first needs to identify that the application is going to be making 32-bit syscalls, and then translate those calls to the equivalent 64-bit syscall every time.
I will also add that the syscall convention for x86 and x86-64 are completely different. So it really is a translation for every kernel call.
|- Score: 12|
|Comment by ssokolow|
|By ssokolow on 2018-02-03 16:31:04|
> This is good. I would prefer other companies, too, take a more aggressive approach towards deprecating outdated technology in consumer technology. |
This is yet another reason I'd never use a Mac.
Heck, one of many reasons I prefer Linux over Windows is that I can still run the 16-bit Windows 3.x games I paid for like Lode Runner: The Legend Returns inside 32-bit Wine on 64-bit Linux.
To legally do that on 64-bit Windows requires a valid Windows 3.1 license that can be installed inside DOSBox or some other emulator.
|- Score: 3|
|Comment by ebasconp|
|By ebasconp on 2018-02-03 17:07:57|
> I would prefer other companies, too, take a more aggressive approach towards deprecating outdated technology in consumer technology. |
Thom, why do you think 32-bit technology is outdated?
I understand we need databases to have access to more than 4gb (2^32) of RAM, animation rendering software, graphical software, etc. that needs to have huge amounts of RAM.
But our Angry Birds, a Sudoku game, our calendars, YouTube, all social media apps, etc. DO NOT need to address 4gb or RAM and in such cases, they are good staying as 32-bit apps.
64-bit apps can access more RAM and have more CPU registers available, BUT, the memory footprint of most applications is larger too because of pointers size being used intensively.
So, getting rid of 32-bit support is, IMO, only a way of saving money having less architectures to maintain.
Java 7+ has a nice workaround to have shorter pointers in 64-bit tech:
|- Score: 10|
|By dionicio on 2018-02-03 18:01:39|
Patents on the open. See the pattern... |
Nowadays, Satya could easily say: thanks!
Edited 2018-02-03 18:03 UTC
|- Score: 1|
|And what about....|
|By leech on 2018-02-03 18:11:45|
|Steam and it's games. I'm going to bet that 99% of them don't have 64bit binaries. Hell, even after all of these years that 64bit processors have been the default, most games are still compiled as 32bit.|
|- Score: 1|
|Not a good thing|
|By Auzy on 2018-02-03 18:46:49|
For a lot of applications, 32 bit only has small benefits. |
Users have very little to gain from this. All it will do is needlessly break apps, and save Apple a bit of money. In the meantime, some programs you'll never get an update for. Only Apple has something to gain.
|- Score: 4|
|Needs to be done...|
|By codewrangler on 2018-02-03 19:11:06|
OS software, must evolve with the hardware changes. It sucks that some software won't be updated, because the developer is out of business or loses interest in the product, but thats life. One thing that's always the same, is change.... |
For those that still want to stick with old software, because they like an old game or other software, there is emulation/simulation available. It sucks, for those that need to use old software, but that's life...
Of course, you can always continue to run old platforms on the old hardware as well, as long it keeps working...
Personally, I'm still bummed that MiniDisc is no longer a current product...:-(
|- Score: 2|