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[3]: Not a good thing
By ahferroin7 on 2018-02-05 20:21:28
Again, as I said in the second half of my comment, you get 8 more general purpose registers when running in Long mode (64-bit mode) on an x86 CPU, which can be pretty damn significant in terms of performance. For reference, 16 and 32 bit x86 have 4 GP registers (which aren't even entirely general purpose in the original ISA, as they have odd hardware level restrictions on which instructions use them for what), while 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.

You also get a measurable boost in performance for math operations involving potentially large numbers (which is also pretty big, as a lot of I/O calls use 64-bit numbers so they can deal with files bigger than 4GB), and moving data to and from memory becomes a bit more efficient in some cases (this really depends more on the memory controller and how the memory modules are connected, but in general a single 64-bit load from RAM is going to be more efficient than two 32-bit loads, even if it's just because the CPU only has to execute one instruction instead of two).

There's also the fact that many of said 64-bit laptops support more RAM, they just don't ship in such a configuration, and while 32-bit x86 can handle a larger hardware address space through PAE, handling of that is a pain in the arse for OS developers and actually can hurt performance pretty significantly relative to not using it, and more importantly that purely 32-bit x86 consumer CPU's aren't really produced anymore beyond some Intel options that are more solidly targeted at ultra-compact embedded designs but for some reason still get used by laptop manufacturers.
Permalink - Score: 2
RE[7]: Comment by ssokolow
By fmaxwell on 2018-02-05 20:33:15
> 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.
Permalink - Score: 1
RE[4]: Not a good thing
By Kochise on 2018-02-05 22:34:20
Well, the 32 bits memory barrier is also dependent not only on PAE but also the BIOS's ability to offer memory remapping, which not everyone allows. My AMD A8 x64 get stuck at 2.25GB of RAM under Windows XP, not matter what, because of this stupid BIOS limitation, even though it features 8GB of memory.

I also understand your register concern, I'm a 68k and SH-4 assembly coder, and I know too well how much these ISA are vastly superior to x86, which despite its flaws bred pretty well its retard architecture at rabbit pace. AMD64 only closes a little bit the gap.

I've made quite challenging graphic processing using byte/word register swapping to avoid as much as possible memory access, abused 64 bits registers to do fixed point color scale dithering, with the expected throughput increase, so I can confess it works.

But the memory consumption, God, Windows x64 is just such a resource hog, Chrome or Firefox with ten tabs open will make any PC with "just" 4GB crawl like a dry snail. How can it be possible, how can it be just acceptable ?
Permalink - Score: 1
RE[6]: Comment by ssokolow
By BluenoseJake on 2018-02-05 22:51:21
Where did I say "Any"? Either way, it's more of an option than macOS, which won't run any apps from that era.

Edited 2018-02-05 22:52 UTC
Permalink - Score: 2
RE[3]: Is 32-bit architecture that out-dated?
By zima on 2018-02-05 23:42:20
> Classic didn’t make it to Intel, but I suspect that was more due to technical issues
Apple had MacOS Classic running on top of x86 DOS in the early 1990s ( https://en.wikipedia.org/wiki/Sta... ), so it's probably unlikely that any technical issues stopped them a decade+ later...
Permalink - Score: 3
RE[4]: Comment by ssokolow
By zima on 2018-02-05 23:45:19
Performance? Games typically end up with higher system requirements under macOS. Stability-wise there's no diff between OSes for a long time (and when there was a difference, MacOS was often worse than Windows). And as for security... RDF is strong with you, you already forgot howjust last year macOS provided full password hint or allowed admin logins without a password? Windows wasn't nearly as bad security-wise since the times of 9x (and MacOS Classic...)
And Apple had untill few months ago exclusively only a cruft of a filesystem, still has it as only option for HDDs...
Also curious how you "forgot" about iTunes bloatware.
Permalink - Score: 3
RE[5]: Comment by ebasconp
By zima on 2018-02-06 01:24:06
> x86 is the only arch that was stupid enough to begin with that it needed extra registers in 64-bit mode
Did it really "need" them or was that simply a nice bonus that AMD threw in?
Permalink - Score: 2
RE: Comment by ssokolow
By sydbarrett74 on 2018-02-06 01:55:31
'Heck, one of many reasons I prefer Linux over Windows is that I can still run the 16-bit Windows 3.x games'

You're certainly free to use legacy equipment for as long as you like. However, the rest of the world is under no obligation to accommodate you.

Edited 2018-02-06 01:57 UTC
Permalink - Score: 1
RE[2]: Comment by ebasconp
By sydbarrett74 on 2018-02-06 01:59:05
> Hm, and IIRC there was some ~Linux effort to have system/apps which can use additional "64-bit" CPU registers but without the memory overhead of "full" 64-bit apps...
Permalink - Score: 1
RE[6]: Comment by ebasconp
By Kochise on 2018-02-06 06:11:33
Not really a bonus, the original x86 register set was a legacy of the 8 bits era that had just a couple accumulators. While the 68000 ditched the 6800/6809 past out and provided coders with 8 full orthogonal data registers, 8 more address registers and a bunch more system registers, all of this in 1979, the x86 continued providing only a handful of weird registers used either for math, or for memory access, or for system configuration.

AMD just tried to par with "normal" cpus.
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?