www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
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.

 Email a friend - Printer friendly - Related stories
.
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-80 -- 81-90 -- 91-94
.
RE[5]: Typical Apple
By Kochise on 2018-02-06 06:13:29
Was there such matter to downvote, really ? God, tech peoples' believes are fragile these days.

Edited 2018-02-06 06:13 UTC
Permalink - Score: 1
.
RE[3]: Not a good thing
By SWC01 on 2018-02-06 11:16:29
The G5 was also never available in a mobile device, which (iirc) was one of the reasons Apple decided to switch to Intel at the time.
Permalink - Score: 2
.
RE[2]: Comment by Kroc
By bhtooefr on 2018-02-06 11:35:17
Some of this might be about ARM, where ARM has two different ISAs for 32 and 64-bit modes?

Note that the A11's cores don't even have an AArch32 decoder, just AArch64.
Permalink - Score: 2
.
RE[5]: Not a good thing
By ahferroin7 on 2018-02-06 12:30:52
Actually, that's the web browsers, not Windows (Chrome on my Windows system sits at roughly 750MB resident with the 16 extensions I use, but is still about 720MB on my 64-bit Linux laptop with the exact same set of extensions and tabs), although Windows is pretty damn bad too (about 20-50% higher memory usage than an an equivalent set of services on Linux).

The problem is that memory efficiency isn't really a developer priority unless they're working with particularly small systems, because it's not something that end users really notice in most cases (that is, if there are memory efficiency issues, they show up as performance issues for most end users). For the example I gave above with Chrome, that 30MB difference is essentially nothing as far as most developers are concerned (and TBH, with 16GB of RAM, I consider it not worth worrying about either).
Permalink - Score: 2
.
RE[6]: Comment by ebasconp
By ahferroin7 on 2018-02-06 12:54:21
Considering that the status-quo even for CPU architectures of roughly the same vintage was at least 8 GP registers? Yeah, I'd say it did need them, especially considering the other restrictions the 16 and 32-bit modes imposed on the usage of those 4 'general purpose' registers (for example, most of the math operations only output to AX/EAX, the loop instruction only lets you use CX/ECX as the counter, etc).

Quoting myself from elsewhere in the comments:
> The Motorola 68000 has 8, ARM has 15 (pre ARMv8) or 31 (ARMv8 and newer), MIPS has 32, SPARC has 31, PPC has 32, and IA-64 (Intel's now defunct Itanium ISA) has a whopping 128. More general purpose registers means you need to make fewer memory accesses when working with small amounts of data (or don't have to regularly load and store frequently used values), which is a huge performance boost in many cases.

Extending that list with further examples: HP PA-RISC has 32, DEC Alpha has 31, OpenRISC has 16 or 32, Rensas/Hitachi SuperH has at least 16, RISC-V has 15 or 31, VAX (which pre-dates the 8086) has 16, the original IBM S/360 (which also predates the 8086) has 16, Hitachi H8 has 8, TI MSP430 has 12, Atmel AVR has 32, and Microchip PIC has at least 32 as far as the ISA is concerned (specific implementations may have fewer).

In fact, the only CPU architecture of that vintage to survive to the modern day in widespread usage that I know of that has so few GP registers other than x86 is the Zilog Z80, and that's an 8080 clone.
Permalink - Score: 2
.
RE: Comment by Kroc is flat out stupid, by Klyo REN
By user78 on 2018-02-06 16:54:50
HAS NO HARDWARE LIMITATION FROM THEIR 64BIT VERSION IS BASED ON IA64 AND EM64T, SO GET YOUR FACTS RIGHT TROLL...AND PEOPLE THUMB YOU..HOW A SHAMED YOU DON'T REASEARCH FIRST BEFORE DECIDING WHEN HE IS WRONG

AND PROVED MY POINT I AM RUNNING PURE 64BIT OS ON APPLE LATELY ON MY OLD I7 INTEL CPU...IT SHOWS 64BIT HARDWARE SUPPORT IA64 AND EM64...NO AMD64 FOR SURE..APPLE DON'T SUPPORT AMD64 CODE..OR ELSE LET HACKINTOSH TRY TO EMULATE IA64 OR EM64 ON THE KERNEL

SO ITS ONE STEP TOWARD DITCHING ROOT AND 32BIT ACCESS FROM AMD HACKINTOSH USERS..ITS ILLEGAL FOR AMD USERS

Edited 2018-02-06 17:11 UTC
Permalink - Score: 0
.
RE[5]: Typical Apple
By feamatar on 2018-02-07 00:43:34
High memory consumption is due to aggressive caching strategies to get you faster reload times. Many people visit the same sites over the day, and to improve load times it is reasonable to cache whatever is possible and keep it in memory. If you load a web page that is 40MBs, the next time you visit, it can load as little as 1MB, and no, it won't use hdd cache when you have enough ram available.
Permalink - Score: 2
.
Nice boost for Adobe's rent-to-use pay model...
By Danmelbourne on 2018-02-07 02:37:52
An unfortunate side effect of this is that it will kill off the last version of the Adobe Creative Suite that was available for "one off purchase" rather than Adobe's horrid rent-to-use subscription software basis. Lots of people are still using CS6 since it works fine -- it'll be sad for MacOS to kill this off.
Permalink - Score: 1
.
RE[7]: Comment by ebasconp
By zima on 2018-02-07 19:58:12
Yes, you're saying that more-than-x86 registers is fairly standard among CPU architectures and good to have - however I wondered if ...something in AMD64 strictly needs them to work. :P

PS. While searching info on x32 I stumbled on https://wiki.debian.org/X32Port so it seems not only Gentoo that you mentioned toyed with it a bit...

Edited 2018-02-07 19:59 UTC
Permalink - Score: 2
.
RE[8]: Comment by ebasconp
By ahferroin7 on 2018-02-07 20:00:51
Ah, sorry I misunderstood you.

Strictly speaking, there isn't anything about 64-bit x86 that required them to be present (though they're established as an architectural feature now that you can't really get rid of without breaking most 64-bit code), though I will comment that the performance improvements they allow for have been a significant driving force for the adoption of 64-bit x86 systems.
Permalink - Score: 2

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-60 -- 61-70 -- 71-80 -- 81-90 -- 91-94

No new comments are allowed for stories older than 10 days.
This story is now archived.

.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?