Apple Starts Alerting Users That It Will End 32-Bit App Support On the Mac (techcrunch.com) 267
An anonymous reader quotes a report from TechCrunch: Tomorrow at midnight PT, Apple will begin issuing an alert box when you open a 32-bit app in MacOS 10.13.4. It's a one-time (per app) alert, designed to help MacOS make the full transition to 64-bit. At some unspecified time in the future, the operating system will end its support for 32-bit technology meaning those apps that haven't been updated just won't work. That time, mind you, is not tomorrow, but the company's hoping that this messaging will help light a fire under users and developers to upgrade before that day comes. Says the company on its help page, "To ensure that the apps you purchase are as advanced as the Mac you run them on, all future Mac software will eventually be required to be 64-bit." As the company notes, the transition's been a long time coming. The company started making it 10 or so years ago with the Power Mac G5 desktop, so it hasn't exactly been an overnight ask for developers. Of course, if you've got older, non-supported software in your arsenal, the eventual end-of-lifing could put a severe damper on your workflow. For those users, there will no doubt be some shades of the transition from OS 9 to OS X in all of this.
why? (Score:2, Interesting)
To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.
Re: (Score:3, Interesting)
To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.
It's probably actually to reduce testing. It's still dumb. You're gonna have to run a VM to run 32 bit software. Even Microsoft is better at back compatibility than that. But Apple has never been shy about forcing its customers to spend more money, because they repeatedly demonstrate a willingness to do that — and they often give it to Apple.
Re: (Score:2)
You're gonna have to run a VM to run 32 bit software
What 32-bit software?
Even Microsoft is better at back compatibility than that
The first version of Windows to support 32-bit x86 applications was Windows NT 3.1. It ran on a 386. Since then, Windows has been collecting 32-bit applications and it's only recently that a large enough proportion of the installed base has been running 64-bit Windows on 64-bit processors that it's made sense to switch.
In contrast, the first version of OS X to support 32-bit x86 applications was Mac OS X 10.4, which also added support for 64-bit x86 applications in a point release.
Re: (Score:2)
The Microsoft mantra: Never remove obsolete possibly exploitable system code. Somebody somewhere might be upset if his old minesweeper game that he coded 20+ years ago and refuses to recompile or update no longer works...
Hoarding [wikipedia.org] is an illness.
Re: (Score:2)
No, so they can switch to their A-series processors in Macs without having to go through compatibility for 32-bit.
I think I still have a very small arsenal of tools that are 32-bit only from 2005(?) when the first intel Macs came out. Personally not nearly as big of a deal for me as them phasing out 32-bit apps for the iPad.
Re: (Score:2)
To save a few GB in system libs? I realize that there are arch improvements in amd64 but that's no reason to break compatibility.
It's probably actually to reduce testing. It's still dumb. You're gonna have to run a VM to run 32 bit software. Even Microsoft is better at back compatibility than that. But Apple has never been shy about forcing its customers to spend more money, because they repeatedly demonstrate a willingness to do that — and they often give it to Apple.
Huh? I am not aware of a single piece of software that I still run that requires 32 bit support which is the only way this change can affect me and cost me money. Products get obsoleted and dropped and if you are expecting eternal backwards compatibility from Apple you are out of luck.
Re: (Score:2)
If you bought Macintosh software expecting it to still work three years later, it's your own stupid fault.
Weird. All the software on the 2010 white Macbook that my Niece then my Sister and (once I upgraded it with max RAM & a SSD) has been bequeathed to my Wife, still works perfectly That includes Office 2008, Pages, Numbers, FortiClient, Calibre, VMWare Fusion, 1Password, etc.
Maybe if you bought software from Mac software from competent developers, you wouldn't suck donkey balls quite so much.
Re: (Score:2)
Apple allows developers to support iOS 8, and leave old versions of their app available for hardware that doesn't support newer versions. The App Store automatically chooses the most-recent version supported by the device.
Re:why? (Score:4, Interesting)
I realize that there are arch improvements in amd64 but that's no reason to break compatibility.
64-bit on x86 royally sucks. Beside unavoidable issues related to 64-bit in general (twice as big pointers, thus any pointer-heavy structure taking twice as much memory, thus cache lines), on x86 in particular it's a dirty hack.
To get slower than amd64, you'd need an ancient register-starved ABI that passes way too much on stack, can't use floating point efficiently, may not pass 64-bit arguments when you actually need them, etc -- ie, i386.
Compare this with a modern 32-bit ABI on x86 (ie, x32). An average program takes ~2/3 memory to run, speed depending on how much pointers you use, but +7% is typical, over 40% in certain cases.
On architecture families that were designed with 64-bit in mind, most of this benefit disappears, but on x86 sane 32-bit wins handily.
Re: (Score:3)
The x32 ABI is part of amd64, most 32bit x86 software uses the i386 abi.
Re:why? (Score:5, Interesting)
Compare this with a modern 32-bit ABI on x86 (ie, x32). An average program takes ~2/3 memory to run, speed depending on how much pointers you use, but +7% is typical, over 40% in certain cases.
I'd be very interested in where you get those numbers from. I work on a research architecture that uses 128-bit pointers and we find that in most cases your DRAM traffic increases by under 10% going from 64-bit to 128-bit. A 7% performance delta sounds about what I'd expect, but 2/3 more memory doesn't. That implies that around 2/3 of your memory is pointers - our measurements indicate that for most workloads (including most of SPEC) it's closer to 10-20% and the number goes down for more performance-critical workloads because developers try very hard to avoid pointer chasing (because it doesn't play well with modern pipelines) in such code.
With my FreeBSD hat on, I did a little bit of analysis of the x32 ABI and concluded that it is better for most systems only if you don't use the x64 ABI for anything. The performance hit from reduced cache sharing between processes for common shared libraries was greater than the performance win from x32. This was the same result that Sun Research found on SPARC 20 years earlier: the 32-bit ABI was better if everything used it, but if you use 1-2 64-bit programs then you lose more then you gain.
This is even more true on something like macOS, where there's a big shared memory region where all of the common system libraries are pre-loaded and then accessed via a per-process offset (and where the kernel is set up so that all mappings of this region share leaf page table entries and so reduce cache pressure on TLB misses).
Re:why? (Score:5, Informative)
I had a look in activity monitor and I have 3 32-bit processes running and I found 3. Two were part of novaterm, which I installed years ago to do HP TouchPad development and haven't used since HP abandoned WebOS, but which I apparently left installing some daemons. The remaining one was the Android File Transfer agent, because apparently I haven't updated Android File Transfer since 2012 and it doesn't auto-update. After a small cleanup, I am now running none.
There's actually only one 32-bit application that I do care about: WINE. There's no reason that WINE couldn't be made to launch 32-bit Windows apps as a 64-bit binary though: it already includes its own program launcher and thunks for calling from Windows libraries into host-system ones.
The benefit is not just saving a few GBs of system libs. It's not having to do QA on any 32-bit versions of software. Apple's 64-bit Objective-C ABI is very different to its 32-bit one (small objects are hidden in pointers, reference counts are embedded in isa pointers, and so on). Making sure that none of the 100MBs or so of Objective-C frameworks that they ship have different observable behaviour with the different pointer sizes is a significant testing overhead. It's also a noticeable memory overhead if you run one app that pulls in the 32-bit versions of all of the system libraries. Even just the small set that you need to link to for any GUI application that adds up to around 50MB of object code, which is not shared with any of the 64-bit processes and so consumes L1 icache and L2/L3 cache space, making everything else slower.
Re: (Score:3)
There's actually only one 32-bit application that I do care about: WINE. There's no reason that WINE couldn't be made to launch 32-bit Windows apps as a 64-bit binary though: it already includes its own program launcher and thunks for calling from Windows libraries into host-system ones.
Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out. For instance take the CreateProcess() [microsoft.com] API. It takes no fewer than 7 pointers as parameters. Not only that but 3 of those point to structures that themselves contain at least one pointer to another structure. Also every time an API returns a pointer to some data, Wine would have to ensure that pointer fits into the 4 GB address space of the 32 bit Windows process. And then you have c
Re: (Score:2)
In fairness though, any apps that are still 32-bit were probably written for much older hardware and would probably run without much difficulty with the additional pointer work.
Re: (Score:2)
Having a 64 bit Wine handle 32 bit Windows applications means converting pointer sizes on the way in and again on the way out
That's true, but in and out of what?
For instance take the CreateProcess() [microsoft.com] API.
And most of its implementation in WINE is in a PE/COFF binary that will be compiled in 32-bit mode. Only things that call system libraries will need translation.
Re: (Score:2)
I was curious too. My main culprit is WebEx/GlobalMeet - I'm assuming that Cisco can successfully do a 64-bit build at some point.
Re: (Score:3)
The rumors mill is that Apple will be releasing a new chip to replace Intel. Changing chips with new instruction sets, breaks compatibility like nothing else.
I expect if Apple to switch chips they would want to keep backwards compatibility so they will have a converter for the previous binary format. So getting people off the old 32bit format will help prep them for the switch to the new chip.
Also to note Apple only had a small time with 32bit intel CPU. About a year or so. So unlike Linux and Windows th
Re: (Score:2)
When you put this together with they Apple wants to make their own cpu line for all their HW this starts to make 'sense'. A new CPU, 64 bity only, all the old libs they dont need to convert support or shim. Again its another cog in the apple's 1 OS for all its devices masterplan.
Circular argument... (Score:2)
Applications without 64bit binaries available should be considered abbandoned or dead. Depending on this kind of software is irresponsible and should be avoided at all cost.
Yeah, its irresponsible because the OS provider might suddenly pull support for them, preventing you from applying future OS upgrades - unless you're talking about internet-facing applications that need continual security patches.
Oh, wait, that's everything now, because everything comes with with cloud-y features you don't want (usually as an excuse to turn the app into a subscription service) - which is one reason why you might want to hang on to your old 32-bit software. That and the new "worse is the n
Re: (Score:3)
Re: (Score:2)
Unfortunately, some of us still need to use those abandoned-or-dead programs.
"Depending on this kind of software is irresponsible and should be avoided at all cost." OK, maybe so. In my case, the "cost" involved building a new computer to run Ubuntu MATE. I wonder if that's what Apple intended?
Re: (Score:2)
Re: why? (Score:4, Insightful)
Yes, your company should account for that when it purchases technology. Everything gets old and dies, from people to computer programs. Not accounting for that fact is a problem in your business model. Are you still using a PDP11?
Re: why? (Score:4, Funny)
Actually, I am.
Re: (Score:2)
If it did what I was doing with it then yes, I'd still be using a PDP11. I just recently replaced a 486, and only because the RasPi can do the same with less power.
Absolutely, but .... (Score:3)
FWIW, I *do* think Apple has a tougher time justifying these changes to its users for a couple of reasons.
1. A lot of people paid a premium to buy a Mac in the first place because of the promise that they have a longer useful life than their Windows PC counterparts. Traditionally, that held true because with them "playing by their own rules", development was based around making software work with what Apple made available. (You couldn't arbitrarily decide, for example, that you didn't like how slow a whole
Re: (Score:3)
I don't know where you got this idea. Apple has a long history of breaking compatibility with older software. This happened when they moved to OSX. They did provide some support for older software but that support eventually died out. Then again when they switched to X86 from PowerPC. Again they provided some support for the switchover, but eventually t
Re: (Score:2)
Question for the group: The backward compatibility/longevity champion is.. MS Windows? I think Linux distributions might be in second place, at least for pre-compiled binaries (source code might be more durable?).
Yesterday I saw a colleague pull out a
Re: why? (Score:5, Insightful)
Frankly I wish programmers like you (who don't have respect for backwards compatibility) would crawl into a ditch and die, but I don't get everything I want in this world.
Re: (Score:2)
Games are an example of software that doesn't usually get updated, but you still want them to keep working.
True. Until I got it off of GOG.com, I built an old Mac Pro running 10.6 just to play Alpha Centauri: Alien Crossfire. I still have it to run other, older powerPC software.
Re: (Score:2)
Re: (Score:2)
Yes, everything grows old and dies but it seems that we prefer to kill than just let it die. We live in a culture of waste and we prefer to send a functioning PDP to the dump than use it.
The value of old software being nostalgia or just plainly that it does the job that is required of it is not determined by it's age. Do bits grow old?
The question is, should Apple support it? This is the question isn't it? I would say as long as Apple maintains copyright on OSX which supports 32 bit I would say yes. The obs
Re: (Score:2, Informative)
A functioning PDP costs 1-2kW to run and can be fully replaced by a Raspberry Pi using 10W. In what world does it make sense to keep running (other than nostalgic reasons).
Re: (Score:2)
A functioning PDP costs 1-2kW to run and can be fully replaced by a Raspberry Pi using 10W. In what world does it make sense to keep running (other than nostalgic reasons).
If your goal is to unplug one, and install the other simply to save hydro costs, mission accomplished. Since you haven't discussed having the Pi do what the PDP was doing, you can simply shut off the PDP for even greater savings. Assuming you DO want to replace the functionality, you're likely looking at massive development hours, re-documenting, retraining etc. just to get to that point.
Besides, if there is a PDP out there somewhere, there a BOFH who insist it shouldn't be replaced just for job security.
A
Re: why? (Score:2)
Re: (Score:2)
Re: (Score:3, Insightful)
Re: (Score:2)
Everyone who buys a Mac is paying to subsidise the continued maintenance and support of the 32-bit versions of system libraries. Very few people are actually using these libraries. You seem to want other people to subsidise your purchasing decisions either way.
Everyone who buys a mac is subsidising a lot of things.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, they dropped 16-bit support some time ago, because the CPUs required to run newer versions of Windows no longer included the 16-bit instruction sets and the operations had to be emulated; that emulation was error prone and took a load of resources to develop and maintain, on top of being somewhat slow and mostly useless. 32-bit code still runs just fine natively on m
Re: (Score:3)
Re: (Score:2)
Everyone who buys a Mac is paying to subsidise the continued maintenance and support of the 32-bit versions of system libraries. Very few people are actually using these libraries. You seem to want other people to subsidise your purchasing decisions either way.
This.
This is exactly why Apple wants to sunset all those 32 bit frameworks. The cost of ensuring all those Frameworks still work and don't cause any new vulnerabilities is nowhere near zero, and overall, does loo thing to contribute to system stability and efficiency.
But all people that absolutely need 32 bit capability need to do is make sure they install the latest version of macOS they can, and that will give them another 5 to 10 years of reasonable compatibility in both directions.
Re: (Score:3)
Everyone who buys a Mac is paying to subsidise the continued maintenance and support of the 32-bit versions of system libraries. Very few people are actually using these libraries. You seem to want other people to subsidise your purchasing decisions either way.
They aren't going to get cheaper when they drop support, you asshole, they're just finding an excuse to increase profit margins because they can
I don't want to pay to subsidize your roads or oil use when I use a bike, but I still fucking do it, you self centered man-child
"I shouldn't have to pay for anything I don't personally gain from! Waaaaah" Jesus you people are stupid
Apple obsoletes stuff all the time and they aren't even close to being the worst offenders in that category by any measure. You kind of sign up for that when you buy a macOS or iOS based product. They will also move stuff around and redesign the UI completely at monotonously regular intervals, add features that confuse the hell out of conservative users such as multiple desktops, and totally useless ones that you end up using all of the time, like spotlight and track pad gestures. They will also offend you
Re: (Score:2)
Re: (Score:2)
That, or your argument is just ridiculous.
Re: (Score:2)
Well if you bought a lemon of software then you should take it up with the software vendor. Macs only had about a year or two with 32bit intel systems there isn’t that much software of value that is still 32bit is there?
For these complaining. What software is affected what does it do? And why hadn’t it been upgraded?
Re: (Score:2)
Games almost never get new versions.
(for example)
Re: (Score:2)
If you provide the money for licensing replacement tools and training the staff to use them, we can switch over today!
What 32 bit apps are in use these days. I haven't used anything since maybe 12 or more years.
I've got a few issues with them borking perfectly good 64 bit Programs like Final cut Studio suite. https://www.imore.com/heads-th... [imore.com] .
For this reason, I picked up a nice 27 inch Core2 Duo imac that won't update to High Sierra, and still runs the fully functioning software.
When My main Mac needs replaced in a few years, I'll spend the money on the latest programs then. But again, I cant remember the last ti
Re: (Score:2)
What 32 bit apps are in use these days. I haven't used anything since maybe 12 or more years.
IIRC, the Mac Steam client for one, as shoddy as it is.
Re: (Score:2)
What 32 bit apps are in use these days. I haven't used anything since maybe 12 or more years.
IIRC, the Mac Steam client for one, as shoddy as it is.
Good lord, and it was 2010 when it came out.
Re: (Score:2)
Re: (Score:2)
If they don't force me to upgrade my machine just so I can keep using it, we're talking.
Re: (Score:2)
Re: (Score:2)
Re:why? (Score:5, Informative)
Memory space has nothing to do with it. 64-bit means a lot more general-purpose registers, 64-bit registers (x86-32 uses pairs of registers for 64-bit operations and typically requires a stack spill for each one), and PC-relative addressing (makes anything that uses shared libraries faster). Less relevant for Apple, because they never supported anything older than a Core 1, but it also typically means being able to assume SSE.
In all except for a few rare circumstances, x86-64 code is faster than x86-32 code on the same processor (the same does not apply to all other 32/64-bit architecture pairs). On top of the underlying improvements, there are a number of 64-bit-only optimisations in Apple's Objective-C implementation (and Objective-C code accounts for a very large proportion of their total code). The class pointer has a load of spare bits at the top, so reference counts are stored inline there. Small objects can be embedded in pointers (including small ASCII strings, which account for a large proportion of dictionary keys and can significantly reduce memory usage and improve performance).
Oh, and it's worth noting that there was a very small window when Apple shipped 32-bit x86 machines. For the Mac Mini, February 2006 to August 2007. For the MacBook, May 2006 to November 2006. For the MacBook Pro, January 2006 to October 2006. The last version of OS X to support the 32-bit chips was 10.6.8, released 8 years ago and discontinued (no more support updates) in July 2011.
Most people buying x86 Macs around the transition held off until the 64-bit ones, because it was pretty obvious at launch that Apple would move to 64-bit quickly (the lack of 64-bit mobile PowerPC chips was one of the reasons for their switch to Intel). XCode was able to produce 64-bit binaries and 32/64-bit fat binaries prior to the Intel switch and most Mac apps moved to being 64-bit a long time ago.
Re: (Score:3, Interesting)
Memory space has nothing to do with it.
Not quite "nothing", thank you.
64-bit means a lot more general-purpose registers, 64-bit registers (x86-32 uses pairs of registers for 64-bit operations and typically requires a stack spill for each one), and PC-relative addressing (makes anything that uses shared libraries faster).
I know. Just wrote a bit of 32bit assembly that keeps the entire program state in registers. It emulates a rather more simple stack machine CPU.
But yes, enlarging the register file is what brought the big improvement in speed. Apparently the "CISC but RISC underneath"-marketeering was so much bullshit and the register file is a big fat bottleneck on x86. The 64bit register width isn't even that important since you don't really need more for most office and other "consumer" tas
Re: why? (Score:2)
If you buy closed source software, you are at their mercy. This isn't news to anyone on /..
Re: (Score:2)
Re: (Score:2)
It makes sense to have a 32bit userland on platforms like Sparc and MIPS..
On x86 less so, there are various other benefits such as extra registers which provide improved performance even if you aren't using large amounts of memory or doing 64bit calculations.
Re:why? (Score:5, Informative)
Yeah, but x32 linux is faster for pretty much everything than amd64 or i386, so it's not the "64-bit" that makes it faster, it's the "extra registers and instructions" Ditching the 64 bit pointers makes programs faster.
A large part of the Apple software stack is Objective-C. On 32-bit platforms, every object has a 32-bit reference count, which is stored in a look-aside table (which I think is an llvm::DenseMap now). Every reference count manipulation (which happens on almost every heap assignment of an object pointer) requires locking the table (or, at least, one of the tables - I think there are 8 on the desktop builds), looking up the refcount indexed by the object, and modifying it. On 64-bit platforms, Apple stores the reference count in the top 16 bits of the class pointer. Updating it is an atomic instruction.
When you create an NSString or NSNumber instance on 32-bit Apple platforms, you are creating an object on the heap. This requires a reference count in the table if it is ever retained (i.e. a pointer to it is stored on the heap), a 32-bit class pointer and at least 32 bits for the value, typically more. This space is probably rounded up to 16 bytes, for alignment. When you create an NSNumber instance or a short NSString on 64-bit Apple platforms, the value is embedded in the pointer. Creation is some bit twiddling in a register, no memory allocation. When I profiled some desktop applications some years ago (before Apple implemented this optimisation), I found that around 10% of all object allocations were strings that could be stored in a pointer. That saving alone is worth the 64-bit switch for most Objective-C applications.
Most JavaScript implementations see similar benefits on 64-bit, though from quite different implementation techniques.
Re: (Score:2)
The fact that parties like apple like to race forward and break compatability for their own benefit does not mean it benefits anyone else. In fact, it makes them unreliable and depending on them ought to count as irresponsible.
If by Apple you also mean all of Unix (which OS X is based) practically then yes, Unix, BSD, and Linux operating systems broke compatibility with their transition to 64 bit. The end of 32 bit Linux is approaching as well. [itsfoss.com]
Re: why? (Score:4, Insightful)
Legacy unmaintained code is a significant security risk...
64bit is not a new thing, 64bit processors have been around for nearly 30 years and have been mainstream for more than 10, apple have not produced a 32bit mac for more than 10 years now, and they are just starting to deprecate 32bit support, so 32bit apps will continue to run and be supported for a few years yet.
If you're running software that hasn't been updated in such a long time then you should seriously be considering replacing it with something that is actively maintained for many reasons.
Re: (Score:2)
No, you don't. You can keep running your 20 year old software on a 10 year old OS.
What you can't do is benefit from all the super-modern enhancements for one part of your solution but continue to run older software as a second part of the solution. Nobody, however, is saying that you can't continue to use that solution exactly as it was when you validated and certified it.
Short lived (Score:4, Informative)
The 32bit x86 version of MacOS was very short lived and was arguably a mistake...
Availability of 64bit PPC hardware to run OSX predates the 32bit x86 version, so they actually took a step backwards. The only non 64bit x86 macs are the very first model laptops, IIRC even the first gen mac pro was 64bit from the start.
Apple should never have supported 32bit x86 at all, and should have moved directly from PPC64 to x86_64.
Re: (Score:2)
Availability of 64bit PPC hardware to run OSX predates the 32bit x86 version, so they actually took a step backwards.
My memory is a bit fuzzy. When they shipped the G5, they supported 64-bit processes, but didn't provide 64-bit versions of any of the GUI libraries, so things that wanted to run 64-bit code needed to do it in a separate process. Did they ship a 64-bit version of Cocoa for PowerPC before they supported it on x86, or was it released at the same time for both?
The only non 64bit x86 macs are the very first model laptops, IIRC even the first gen mac pro was 64bit from the start.
The Mac Mini was 32-bit for about 18 months. It was Mac Mini owners that were the loudest to complain when 10.7 dropped support for 32-bit CPUs.
Re: (Score:2)
The 32bit x86 version of MacOS was very short lived and was arguably a mistake... Availability of 64bit PPC hardware to run OSX predates the 32bit x86 version, so they actually took a step backwards. The only non 64bit x86 macs are the very first model laptops, IIRC even the first gen mac pro was 64bit from the start.
Apple should never have supported 32bit x86 at all, and should have moved directly from PPC64 to x86_64.
It was in 2007, right ? I find this acceptable. Hindsight 20/20, you know.
However, I can't find any good excuse to Microsoft for releasing Windows 10 in 32bit in 64bit in 2015.
Re: (Score:2)
I can't find any good excuse to Microsoft for releasing Windows 10 in 32bit in 64bit in 2015.
Dell is still selling new PCs with 2 GB of RAM. What benefit does x86-64 have over x86 on a machine with 2 GB of RAM? Does the increased register count outweigh the additional data cache misses from larger pointers, particularly on a system without the so-called "x32" ABI?
Re: (Score:2)
Enterprise usage say old hardware that needs 32 bit drivers? or some apps that only work in 32 bit mode?
Re: (Score:2)
if Apple's going to say "fuck you" to its customers, then I'll do the same to them. PCs only from now on
Until your boss asks you for a macOS or iOS version of the application that you maintain.
Re: (Score:2)
Re: (Score:2)
Despite all the brainwashing from Microsoft and Intel, it is possible to run 64-bit apps with a 32-bit kernel on a properly-designed CPU architecture. Preferably one that has a 32-bit mode worth using
The problem is with MS and how they chose to deal with 64 bit transitions [wikipedia.org]. Their model LLP64 defines "long" as 32 bit and "long long" as 64 bit. So in your app on a 32 bit kernel, "long long" isn't recognized as a data type. In the Unix and OS X LPT 64 model, 32 bit "long" is redefined as 64 bit "long" so a recompile is needed. With LLP64 backwards compatibility in ensured but not forward compatibility. The reverse is said of LP64.
Re: (Score:2)
Re: (Score:2)
They didn't do that so as not to interfere with their relationship with Intel. Intel didn't have a 64 bit product ready when they were designing the machines that got the 32 bit processor. And just look how well that's turned out! Apple could have gone amd64, and wound up looking like the geniuses that they so often claim to be
One of the main reasons Apple went with Intel wasn't so much because of x86 vs PPC debate but that of practical supply demands on the laptop CPU side and power efficiency. IBM did not and was not going to invest in a lot of R&D for Apple to have newer and newer PPC chips every year especially laptop versions as Apple did not represent a big customer to IBM in terms of CPUs. At the time, Apple's laptops lagged heavily in terms of power and performance compared to their own desktops because of the CPU. Go
about time (Score:2)
But, there is some of internal corporate proprietary applications that will start failing when this happens, I can name two of the top of my head. They all use 32 bit java and are designed to work on Linux, MAC and Windows. Until Windows removes 32 bit support, this will make it quite hard for people to use MACs in a corporate environment.
Re: (Score:3)
Re: (Score:2)
32 bit java
But muh run anywhere! There's no reason that a JRE couldn't use an interpreter compiled for 64-bit, at which point the host CPU becomes irrelevant. Apple is just trying to kick out x86, not everything that is in some way "32-bit".
Say goodbye to Games (Score:2)
I lost access to so many of my older games when they killed Rosetta-- I'm about to lose a lot more when Apple kills off 32 bit.
And I just played Company of Heroes yesterday.
Re: (Score:2)
I lost access to so many of my older games when they killed Rosetta
Yeah that was super annoying and rude.
I'm about to lose a lot more when Apple kills off 32 bit.
OK, that's your own fault, you should have known to not trust Apple backwards compatibility by now.
Re: (Score:2)
I suppose that if I really cared about backwards compatibility, I would be using "32 bit extensions and a graphical shell [on top of] a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition."
Re: (Score:2)
32 bit emulator (Score:2)
I don't understand (Score:2)
Apps that are not 64-bit are pretty rare if you are running OSX 10.13x ... most apps broke when 10.4x was released, then 10.6x, and again when 10.10x was released. You can't submit 32-bit apps to the Mac App Store (as of January this year) so anything there should be good to go.
If you have "legacy apps" that run in 32bit mode you probably have a "legacy computer" with a "legacy version of OSX" to run them on (ideally not connected to the internet). So this won't affect you at all. Go! Sneakernet!
Back Compat
Re: (Score:2)
(ideally not connected to the internet)
The modem/gateway for my Uverse does some screwy shit on the LAN that completely hoses anything running 10.4. I had a couple of old PPC computers (mostly an original Mac Mini) that I wanted to run 10.4 on, but they would go zombie after just a few hours. It does other screwy shit to my LAN (like capriciously refusing to forward packets between wired and wifi, caching ancient IPv6 temporary addresses, and applying the WAN speed limits when I talk to my static IP computers) that I'm going to go back to running my own 10.x.x.x LAN when I have the time.
Not overnight, but, (Score:2)
I'm ready (Score:2)
Bring on the 33-bit apps!
It's a at least an even bet that.... (Score:2)
I can easily imagine that announcing support for 32 bit applications will be d
Re: (Score:2)
I can easily imagine that announcing support for 32 bit applications will be discontinued will cause no small number of people to retaliate to this by simply no longer performing or accepting any system updates, because they perceive that their need for that continued functionality is more important than having the latest and greatest that Apple puts out.
And that should be fine. Considering that most 32-bit OSX apps were last built around 2006, most people who were very concerned about legacy compatibility and tested unchanging functionality won't even notice that you can't use an OS released more than 12 years after the application was built.
Re: (Score:2)
Yeah, but that's what was said about everything from DOS apps, 16-bit apps, apps built against WinG, apps which expected full permissions, etc. etc. etc.
Either you're actively developing something, or you're not. If you are, it should just be a case of "recompile" - you don't even need to provide support of bugfixes if you don't want to, just recompile the old app.
But if you're not... then it's just a timebomb anyway, and if it's at all critical you probably want active development for security etc. issue
I forgot Yuge (Score:2)
I remember the good old days when 32-bit apps that were "32-bit clean" were the happenin' cool kids.
And Apple 16 vs. 32-bit messy/clean was a breath of clarity compared to the PC's Eeny Tiny Mini Small Medium Large Huge and Gigundoid memory models (on a computer where 640k was enough ram for anybody.)
Silver Hammer (Score:2)
So I have this silver hammer that has worked nicely for years. Then my post office raised the first class stamp rate and declared that my hammers won't work anymore.
This is arbitrary and pernicious. There is no good reason that Apple doesn't offer backward compatibility. They have the computing power in all of their devices. They have the expertise. There is a lot of very useful software that is not going to get upgraded because the developers don't exist anymore.
By doing this Apple forces people not to upg
Re:What is the incentive for Devs? (Score:4, Informative)
Re: (Score:2)
Take into account that Apple is going to do the transition Intel -> ARM real soon now,.
To be fair, that's only a rumour, and could be just a tweet to tell Intel that the missiles are on the way,
On the other hand, a "purge" of old software, riddled with hardware-dependent code instead of working through the OS frameworks, will help clear the decks for an ARM transition, too. Today, we ought to be at the point where the majority of applications (obviously, drivers, hypervisors etc, may be a different kettle of fish) will re-compile for x86, AMD64 or various ARM flavours at the flick of a switc
Re: (Score:2)
Or perhaps they are planning to include an emulator on their ARM systems to run older binaries, and making it support only x86_64 instead of 32bit as well could be less work for them.
They included emulators before on the m68k->ppc and ppc->x86 transitions, and the ppc->x86 emulator only supported 32bit ppc (although there was very little 64bit ppc software available at the time).
Re: (Score:2)
They also don't want you using non apple hardware, even if it came with your Mac.
Hard drives, memory, the last OS update I did I lost the use of my SD card slot, the last "security update" my (non-apple) wireless mouse quit working right.
Try to put an SSD in your older Imac to breathe some new speed into it, the cooling system goes bonkers because apple doesn't use the temp sensor aspect of the smart drive protocol, they have a special apple only temp sensor.
Why can't they play nice with my android, because
Re: (Score:2)
Maybe they could start having a dialog pop up when you launch them a long time before they're completely unsupported?
Re: (Score:2)
The problem with your statement is that they do want you to know and they do flag your 32 bit apps. It's all laid out nice and neat in the system information in a handy, alphabetized table.
- hold down alt and click on the apple menu
- select System Information
- under the software category on the left hand side select "Applications"
- sort the table on the "64-bit" column
There you go. I've removed something that really frustrates you. Feel better now?