Apple Starts Alerting Users That It Will End 32-Bit App Support On the Mac (techcrunch.com)

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.

Comments

why?

[Anonymous Coward]

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:why?

[Anonymous Coward]

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.

Re:why?

[drinkypoo]

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:why?

[Opportunist]

If you provide the money for licensing replacement tools and training the staff to use them, we can switch over today!

Re:why?

[Anonymous Coward]

> Apple has never been shy about forcing its customers to spend more money

Actually the opposite would be more accurate with this. If you deppend on some old app that doesn't have 64 bit binaries you can't upgrade your system since it won't be able to run an older macOS version. You would be forced to keep your old computers until you find a substitute or the developer decides to release new binaries.

It's like when Apple went from PPC to Intel. Photoshop performance was worse on Intel computers so you had to keep your "old" PowerMacs until Adobe decided to release a Intel native version of their software.

Re: why?

[guruevi]

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?

[Anonymous Coward]

This is quite a bit of typical neophiliac bullshit. Plenty of applications will not ever need more than, say, a gigabyte of memory, or even far less. Then it makes zero sense to insist on 64 bit pointers everywhere.

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.

Re:why?

[KiloByte]

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:why?

[TheRaven64]

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: why?

[Anonymous Coward]

And why is that? Have you ever worked in the industry? Hell, have you ever had a favorite program you wanted d to hold on to?

Re:why?

[TheRaven64]

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.

Re:why?

[jellomizer]

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 there isn’t a mountain of software. There is just a small number that is 32bit only.

Re:why?

[jellomizer]

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:why?

[Anonymous Coward]

Planned obsolescence.

Re: why?

[Anonymous Coward]

Tell us how much you are spending on it.

Re:why?

[Anonymous Coward]

Did you not read the terms and conditions of the software you bought? I'm not a big fan of Apple, but there's no reason any OS developer should stay in the dark ages just because of third party app developers who have chosen not to maintain their software.

Re:why?

[TheRaven64]

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: why?

[Anonymous Coward]

Actually, I am.

Re:why?

[Bert64]

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?

[TheRaven64]

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. It originally ran on Core 1 processors. With the exception of the Mac Mini, most Apple product lines included 32-bit x86 processors for about six months (about 18 for the Mac Mini). The last version of OS X to support 32-bit x86 processors was 10.6, which shipped in 2009 and was EOL'd in 2011.

Microsoft is pretty good at backwards compatibility in general (take a look at the contortions that they go to so that old ATL apps don't break with their control-flow integrity protection), but in this case they have much more need to be. 32-bit x86 apps were the main thing that Windows ran for 20 years. They were the main thing that OS X ran for about a year.

Re:why?

[Anonymous Coward]

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.

The words of someone with no real world experience.

I have software that works well and does exactly what I need, but, the company that produced it no longer exists, or, they have discontinued this particular product. And, more importantly, there is no software i can get to replace it, that is just as good. Only inferior crap.

So I have to throw out perfectly good software and use inferior crap.

Fuck You.

Re: why?

[Bert64]

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:why?

[Bert64]

The x32 ABI is part of amd64, most 32bit x86 software uses the i386 abi.

Re:why?

[drinkypoo]

In contrast, the first version of OS X to support 32-bit x86 applications was Mac OS X 10.4, [...] 32-bit x86 apps were the main thing that Windows ran for 20 years. They were the main thing that OS X ran for about a year.

People were still creating 32-bit applications well after they could create 64-bit applications, for back-compatibility. Also, having to mention x86 in there makes me laugh, because of course you're eliding the entire architecture that they adopted and then dropped while people were still getting work done with it. Some of those machines are still useful for getting work done (for DTP if not for video editing) but Apple cut them off and abandoned them, and now you can't even find a browser for them because nobody is making a JS engine for PPC.

Re:why?

[TheRaven64]

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?

[Anonymous Coward]

Next thing he'll be complaining because his floppy disks wont work.

Re: why?

[WatchMaster]

Code for IBM360 still runs great. If it does the job why change it? Why not keep a few GB of libraries around to make life easier.

Re:why?

[Anonymous Coward]

I've got just 1: ipcserver which is apparently part of the Steam client.

Re: why?

[Anonymous Coward]

Theyre also talking about making their own cpus at some unspecified time in the future. If they went 64 bit intel instructions only, cheaper, simpler, more secure without the legacy, right?

Re:why?

[Anonymous Coward]

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" tasks anyway. Certainly not since as soon as you do need more bits the task turns out to be one for which there already is some extension or other to do the heavy lifting. The many extensions in x86 don't use the general register file.

But really, that's hardly relevant. What this is about is having programs that you got as a 32bit binary that work but somehow aren't updateable. Of course, apple typically doesn't care and just tells you to "upgrade", to a competitor's application if you have to, regardless of its cost to you.

Oh, and it's worth noting that there was a very small window when Apple shipped 32-bit x86 machines.

They probably should have refrained from doing that. They could've gone full 64bit from the start and not have to slam the door later. A little thought beforehand, etc.

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).

"We can't have 64bit mobile PowerPC chips so we'll ship 32bit wintendo mobile chips instead." This makes no sense.

For PowerPC the register file argument doesn't hold, by the by. Which is really the only thing that causes a big win outside scientific computing for x86 going from 32 to 64bit, certainly if "memory space has nothing to do with it."

Anyway, all that is rationalisation to the net effect of being less responsible than they could be, and I'm saying, you don't get to shout at the users of your "ecosystem" if you created your "ecosystem" to be this way.

Re: why?

[Opportunist]

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.

Re:why?

[Opportunist]

If they don't force me to upgrade my machine just so I can keep using it, we're talking.

Re: why?

[Anonymous Coward]

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

Re:why?

[Zobeid]

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:why?

[phayes]

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 is an illness.

Re:why?

[Anonymous Coward]

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.

Re: why?

[evultrole]

Because they care far more about making an extra couple of dollars than they do about keeping you happy. I thought that was obvious by now?

Re:why?

[phantomfive]

Apple completely sucks donkey balls on their backwards compatibility policies, but they've been this way for years. If you bought Macintosh software expecting it to still work three years later, it's your own stupid fault.

Apple doesn't make their software backwards compatible. Don't commit to their platform. You can't eve say they are screwing you because they are clear about it in advance.

Re:why?

[stealth_finger]

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: why?

[phantomfive]

Games are an example of software that doesn't usually get updated, but you still want them to keep working.

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: why?

[Anonymous Coward]

It's just good business! Smart! This is one of the first things taught at Trump University. Only Apple has the COURAGE to make this significant advancement in technology thanks to the fine leadership of our stable genius Trump.

I, for one, welcome our x64 only future and embrace it with open arms. That wall needs to be built to keep those 32 bit bad hombres out.

Make Apple Great Again!

Re: why?

[drinkypoo]

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

Poor example. Your bike didn't get to the place you bought it from on a bike, it got there on a truck. You use a truck by proxy every time you use your bike.

Re:why?

[drinkypoo]

64-bit on x86 royally sucks.

That's amd64 to you.

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.

No dirtier than x86 itself.

To get slower than amd64,

x86-64 systems dominate the Top500, but please do go on

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.

Pretty much all of which has been solved in various extensions, or with register renaming.

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.

Sure, but just recompiling for 64-bit can provide a speed improvement of as much as 15%, if you're doing enough shoveling of data. And while RAM isn't exactly cheap, it's cheap enough to where that penalty doesn't matter to most users.

On architecture families that were designed with 64-bit in mind, most of this benefit disappears, but on x86 sane 32-bit wins handily.

Unless you care about performance.

Re:why?

[Anonymous Coward]

I was an engineer for an Apple-focused IT consultancy at the time.

It was bad in 2006 when studios were purchasing Intel Macs while PowerPC-only CS2 was the only option. It was worse in 2007 when studios were purchasing Intel Macs while PowerPC-only CS2 hung around -- to avoid the cost of upgrading the entire studio to Intel-compatible CS3.

Wow, Adobe forcing everyone onto Creative Cloud might have an advantage.

Re:why?

[drinkypoo]

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.

It doesn't take any longer to use a 64 bit pointer than a 32 bit one, it gets you out of having to do stupid tricks to access your entire address space, and any application that's shoveling a lot of data will shovel it twice as fast since it's shoveling twice as much at a time. A handful of tasks that don't take very long got slower, and a lot of tasks that do take a long time got faster. This is an ideal tradeoff.

Re: why?

[reanjr]

If you buy closed source software, you are at their mercy. This isn't news to anyone on /..

Re: why?

[drinkypoo]

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.

The average home user runs precisely two kinds of apps: a web browser, and games. Games get updates for a while, and then those updates stop. They can't just be replaced with another game; if you like playing a certain game, you like playing that game. For corporate users, your attitude is completely justifiable, but not for home users.

Re:why?

[fluffernutter]

I have no problem paying extra pennies if it makes someone's life easier.

Re: why?

[Merk42]

Games are an example of software that doesn't usually get updated, but you still want them to keep working. 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.

Frankly I wish people like you (who think developers are beholden to lifetime support software in any future OS) would crawl into a ditch and die, but I don't get everything I want in this world.

Re:why?

[Joce640k]

Games almost never get new versions.

(for example)

Re: why?

[Anonymous Coward]

To save maintaining binary compatibility with ancient deprecated libraries that all need effort to maintain.

Re: why?

[MeNeXT]

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 obsolescence is artificially maintained by laws which protect the creation of trash. If copyright and patents would expire with the abandonment of technology then someone who has a use for it would be able to maintain it.

IP laws were intended to bring things to market not protect those who didn't wish to share.

Re:why?

[Anonymous Coward]

Im sure the price of a mac will drop when 32 bit support is removed. After all thats the apple way. Pass the savings on to the customer. Hell they will probably send out a rebate to all the current users.

Re:why?

[aaarrrgggh]

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: why?

[phantomfive]

I truly admire your originality. Your power of creativity must have been granted to you by the devil himself. Quite the way with words you have there.

Re:why?

[Megane]

Guess what, you can still install older versions of the OS to run on older machines to run your older software. You might have to set the clock back to 2014 during the install (*cough*10.10*cough*) because of digital certificates, but it still works.

Re:why?

[TheFakeTimCook]

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: why?

[guruevi]

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: why?

[Anonymous Coward]

Next thing he'll be complaining because his floppy disks wont work.

My floppies are still working fine, thank you. At least, the ones that I didn't convert from LD to HD with a drill. My Sony and 3M disks are working fine. Now, those floppies from Microsoft, Origin, EA and Microprose are another matter entirely. Microprose especially - who else made games that you had to reboot the computer with the game disk in A:. Backups were not allowed due to custom sector/track layout.

Re:why?

[Ol Olsoc]

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... .

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 time I used a 32 bit app, only that it was over a decade ago.

Re: why?

[Zorpheus]

But floppy discs do work, when it is needed. All you need is a cheap USB drive.

Re: why?

[Gr8Apes]

You could have replaced that 486 a long long time ago with a much smaller system using much less power and paid for itself probably 2 or 3 times over.

Re:why?

[TheRaven64]

Personally, I'd rather that they invest their finite developer resources in something that affects 99% of users, rather than something that affects 1%.

Re: why?

[Gr8Apes]

old games move to VMs. Problem solved.

Re:why?

[fgouget]

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() 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 callbacks.

For a lot of these issues you cannot just automatically generate the thunking code either. And with over 80 000 APIs, not counting COM APIs, and not counting Windows messages (e.g. WM_CREATE comes with a pointer to a structure which itself contains 3 other pointers) you have literally tens of thousands of reasons why WINE can't be made to launch 32-bit Windows apps as a 64-bit binary without a huge undertaking.

Oh. And on OSX Apple also decided to overwrites a CPU register that Win64 applications expect to remain untouched. If I remember correctly, as a result support for 64 bit Windows applications assumes they will only use TEB slots that happen to not be used by OSX and Apple neither confirmed nor denied that this would remain that way, meaning Wine's 64 bit support is already hanging by a thread on OSX.

Despite these obstacles there's already pretty clever exploratory work towards running 32 bit Windows applications in 64 bit processes. But those are still a long way off and it's not yet clear if they will be viable yet.

Really, not only has Wine a huge task ahead of it reimplementing the Win32 API, but it also has to deal with all sorts of crap from Microsoft competitors: Apple not lifting one finger to help with 64 bit support, Apple dropping 32 bit support, Apple letting OpenGL just die, Debian having shitty multiarch support, Linux distributions talking about dropping 32 bit support, Nvidia and AMD producing crappy Linux and OSX GPU drivers. With all these obstacles it's a miracle Wine has gone as far as it has. And in the meantime everyone, governments included, depends on a single supplier, Microsoft, to run all their in-house (Windows) applications.

Re: why?

[Gr8Apes]

The run cost of that old PDP is orders of magnitude higher than replacing it with a Rasp Pi.

Re: why?

[Freischutz]

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 to the core of your being by aggressively deleting obsolete or bulky connection ports like RS232, USB-A, DVI, Displayport, etc... and going off on wild and not always successful experimental tangents like Thunderbolt. If you don't like that kind of environment and yearn for hardly ever changing stability you should buy a Windows PC, Microsoft only intermittently confuses or offends you with new features whereas this is a constant state of affairs with Apple and the engineers at Microsoft are true masters at backwards compatibility (and that's not a snide jab and MS, they really are good at pretty seamless backwards compatibility).

P.S. you might want to consider dropping the profanity from your posts in the future, it ads no weight to your arguments, at least not here where most people tend to value logical argumentation over potty mouth. The only thing you achieve by using the word 'asshole' is making everybody around here who reads your post think you are the asshole.

Re:why?

[Anonymous Coward]

update your steam client?

Re:why?

[fluffernutter]

Personally I like to include as many people as possible and not just think about my uses. I find eventually I will find myself in the 1% for something and I like when those 99% think of me.

Re:why?

[phayes]

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:why?

[Freischutz]

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: why?

[Mordaximus]

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 good example of why you would want to reconsider is the Phoenix pay system in Canada (as an analogy, I don't believe the previous system ran on PDP,) It has cost tens of millions of tax payer money, not to mention what the federal employees who have had to deal with maybe getting payed regularly have suffered. And it STILL doesn't accomplish what the old system did.

Re:why?

[Mordaximus]

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: why?

[Anonymous Coward]

Hardware interface to in house developed instruments (in research labs, some people are using ~30 years old hardware and perhaps even more, some could not be made much better these days, and the investment for a new design and build from scratch would stop the operation for years).

Re:why?

[fluffernutter]

Uh, maybe I paid for software long ago that I want to keep using? It just goes to show you where Windows tends to shine.

Re: why?

[fluffernutter]

You are also at the mercy of the platform you run it on and you would hope your platform works for you as long as possible. Apple is putting themselves ahead of users, as usual. This is nothing different then removing a headphone jack.

Re:why?

[rjstanford]

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.

Re:why?

[MrLint]

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.

Re: why?

[Anonymous Coward]

Except it's not the app developers in this case.

Windows has provided exceptional backwards compatibility at the OS level, ensuring the vast majority of older 32-bit software works perfectly fine.

If you want to justify your more pricey purchase by saying that you'd like fewer options, you've chosen your platform well.

Re:why?

[rjstanford]

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:why?

[rjstanford]

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:why?

[Anonymous Coward]

http://news.softpedia.com/news/Microsoft-Explains-Why-Windows-10-32-Bit-Is-Still-Needed-469563.shtml

Over 70 million installs of 32bit, and that's what Microsoft could find presumably due to windows update.

I myself am using a Pentium 4 that I recovered as a backup / local email server. I have no extenuating reason why I should spend more.

Re: why?

[Anonymous Coward]

Except ypu are not allowed to have virtual macs

Re:why?

[Anonymous Coward]

Have you actually checked which ones are 32bit? On Windows, there's no obvious difference between 32 and a 64 bit software if you don't go in deeper. You might be surprised.

Re:why?

[Anonymous Coward]

So continue using it, you dickwad. Apple doesn't force-update old OSes to drop their support for 32-bit software.

Re: why?

[Anonymous Coward]

In your world VMs have direct access to the video card? That fatal flaw is the only thing keeping me from virtualizing my Windows box and my Mac box with a real OS base.

Re:why?

[Anonymous Coward]

not true, I use a living, breathing, under active development app. It's a mission critical app for me.

Re: why?

[Anonymous Coward]

Apple doesn't need to justify anything, you entitled pile of shit.

Re:why?

[Ol Olsoc]

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: why?

[BronsCon]

And the Intel CPU in your Mac wasn't designed on a Mac, it was designed on a Windows PC. You use a Windows PC by proxy every time you use your Mac.

That, or your argument is just ridiculous.

Re: why?

[BronsCon]

And you just used the word, yourself... does that make you one, too?

Re: why?

[Anonymous Coward]

You stupid bitch, some of 32bit apps were developed well above quality control and attention to detail of today's stupid fart apps.
Kill yourself.

Re:why?

[BronsCon]

If something affects 1%, that means you're sure to know at least a handful of people affected by that thing. How would you feel if 1% of the people you know kicked you in the balls? Because that's what you're metaphorically doing to 1% of the people you know; and turnabout should be fair play.

Re: why?

[Anonymous Coward]

You are an idiot if you world revolves around a stupid minesweeper.

Re:why?

[BronsCon]

No, but they do stop providing security updates. Maybe someone wants to continue using 32 bit software and receive patches for newly discovered vulnerabilities?

Re:why?

[Anonymous Coward]

Steve Jobs said it was because Intel had a roadmap and actually agreed to work with Apple going forward to being low-cost, low-power x86-64 as part of the product evolution.

IBM was just like 'you take what we give you'

Re: why?

[Anonymous Coward]

Although they have a reputation for not doing so, IBM *does* break old code. They removed support for OS/VS COBOL (a.k.a COBOL 1) from CICS/TS a while ago, and there was still a lot of it about, some with missing source. You have to buy a 3rd party (non-IBM) product to run this code now.

Re:why?

[TheRaven64]

Totally irrelevant. Windows ran on 32-bit x86 systems since 1993 (NT 3.1) and 32-bit was the most common version of Windows since late 1995. Mac OS X shipped 32-bit x86 on laptops for about 6 months, low-end desktops (Mac Mini) for about 18 months and on high-end desktops never. The last version of OS X to run on 32-bit processors was released in 2009 and reached EOL in 2011. Mac OS X never ran on a Pentium 4 and it shipped on Core 1 (the only x86 processors that it ever shipped on) for a very limited period.

Re:why?

[TheRaven64]

If you have unlimited developer resources, by all means spend them making everything better. If you have finite developer resources, you need to prioritise. Supporting 32-bit applications, when the last version of Mac OS X that couldn't run 64-bit ones was EOL'd 7 years earlier and the standard Mac toolchain has built 64-bit binaries by default for over 10 years is not likely to affect very many people.

Re: why?

[Anonymous Coward]

I would like to find a usb drive for a 5-1/4" floppy.

Re:why?

[TheRaven64]

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: why?

[Anonymous Coward]

You don't have any idea at all what the cost of conversion would be. Let alone what that cost has to do with the cost of operating a Raspberry Pi.

Re: why?

[painandgreed]

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:why?

[BronsCon]

Apple has way more money and developer resources than Microsoft, yet Microsoft has no problem supporting 32-bit applications. Try again.

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 modern x86 CPUs, though, so there is no emulation layer being maintained. To add to that, Apple does very little, if any, assembly development, even at the the kernel and driver level, so the difference between a 32- and 64-bit version of a given library is literally a compiler flag in the vast majority of cases.

Do you really think every developer who releases 32- and 64-bit versions of their software (or fat binaries, for that matter) writes and tests it twice? No. It's a damn compiler flag. They could hire one guy part-time to maintain the 32-bit libraries, pick up everyone's lunch orders, and detail clean the break room twice a day.

Re:why?

[UnknowingFool]

Yes but Windows uses a completely different 64 bit model as Macs and all of Unix so this is not surprising as Windows chose to maintain backwards compatibility over forward compatibility.

Re:why?

[UnknowingFool]

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.

Re:why?

[Anonymous Coward]

My copy of Microsoft Office 2011 on my 2009 iMac 27" running High Sierra works fine. As well as High Sierra can (which is crap).
Office 2011 will not run on 64-bit OS.
I look forward to the warnings.
The 2009 iMac will not run the next 64 bit only macOS.
Yes, I should spend money on a new computer and the latest from Microsoft.
This user will probably upgrade to a Windows laptop, Apple software has really been shit since El Capitan.
I don't need the headaches from Tim Cook. I give up.
Don't suggest I use Linux and Open Office. I develop software on Linux. It ain't that great. Open Office ain't good enough.

Re: why?

[TheRaven64]

I, too, would like to find one. Last time I looked, someone had a design for one that you could make at home, if you could source the parts, but I don't really know if my 5.25" floppy disks still work so I'd rather not have two variables to test at the same time.

Re: why?

[TheRaven64]

In 2005, I spent £100 on a PC-Engines WRAP. That machine outperformed the fastest 486 ever produced and used 7W under load. Most 486s used at least 50W, but let's be generous and say 30W. Electricity cost, to a rough approximation (which was still roughly valid back then) around £1/WYear, so if you'd done the same you'd have saved £276 in power (probably more, but I'm being very generous in my estimations) for an up-front cost of £100. That's roughly equivalent to investing the money in something that's earned 10% interest per annum, compounded over the entire term. I hope you invested the money that you saved by not upgrading the 486 very well!

Re: why?

[TheRaven64]

Except in the case of games. A lot of Windows 95 games never made it over the transition to the NT kernel. I have a few games from that era that run well on a Mac or other *NIX box under WINE, but don't work on a modern Windows system.

Re: why?

[TheRaven64]

Yes you are, the EULA explicitly permits you to run macOS in a VM, but only on Apple hardware. VirtualBox will boot macOS on macOS out of the box, but you need to patch it to work on other host systems.

Re: why?

[TheRaven64]

In your world VMs have direct access to the video card?

Depends on the host / guest pair, but yes, often. Well, not quite direct access, but paravirtualised (so they can do 3D acceleration, which is what I think you actually want). Most modern GPUs do user-mode command submission, so the kernel is responsible for setting up the memory mappings in the MMU and IOMMU and then userspace communicates directly with the GPU. This kind of setup is very easy to support in virtualised environments.

Re: why?

[guruevi]

There is an ever increasing cost associated with keeping it running. That's what I mean by having a business plan, if a small shop still runs a PDP-11 they would probably be out of business by now, why do we allow our governments to keep things running that badly?

I've been involved with mainframe transitions, the problem is generally not that we can't duplicate the program exactly as it is right now or improve it for a fraction of the cost they paid IBM to keep it running, the problem is generally bad management that doesn't want to move. If you get rid of redundant loops in a business, you're eliminating a whole layer of management.

Re:why?

[Anonymous Coward]

I assume he means on every API call and worse, on every bit of IPC with the messaging and object subsystems.

A really nasty piece of work, even it could be made to work, I expect you are going to peg a single core with pointer thunking.

Re:why?

[TheRaven64]

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: why?

[TheRaven64]

How much does a System/Z (sorry, apparently it's IBM Z this week) machine cost compared to a Mac? I actually have no idea, but the fact that IBM doesn't have a price list - or even a product list - and instead has a 'Request a consultation' button for people interested in buying one tells me that it's not going to be cheap.

If you want long-term support and are willing to pay for it, then there are platforms available and whatever OS/360 is called this week is the absolute gold standard for this. If you aren't willing to pay for it, don't be surprised when it goes away.

Re:why?

[kelemvor4]

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.

Except that there's no good reason to do that. Luckily, mac users will continue to have the option to stick with their older version of MacOS or to load Linux or Windows on the hardware.

Re:why?

[Anonymous Coward]

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...

Most Microsoft users don't code their own software or have the source code, and the vast majority of it out there have EULAs that prohibit users from any kind of work necessary to patch the program themselves or reverse engineer it and make another program that's compatible with the original's data.

So yes, many people would be upset if their software that they are legally forbidden from updating suddenly stopped working.

Re:why?

[Jeremy Erwin]

Which tends to mean that all those 64 bit Steam games will break as well. AT least there's an incentive for Valve to update the client.

Re: why?

[Rewind]

Oh well look at Lord Reginald Fancypants von Moneybags III over here with his PDP-11! We are still using a straight-8! If it was good enough for 1965, its good enough for me I says!

Re: why?

[Gr8Apes]

The bonus there is that unsupported GPU APIs can be virtually synthesized so your generations newer GPU appears to be whatever old clunky API supporting GPU needed for the game.

Re:why?

[OrangeTide]

I work for a hardware vendor, and it's kind of a pain in the ass to have additional columns on your test matrix.

Apple is lucky to be in a position where they can break compatibility and have it be a net positive. Sure people might bitch and moan, but more people will upgrade their systems when SW vendors drop support for older systems.

As for 32-bit versus 64-bit, it is possible to do 32-bit pointers in 64-bit long mode. Which eliminates most of the costs for application size. I don't think MacOS supports that yet, but it's been something people have been kicking around on Linux so it is theoretically possible for Apple to add something like that back in. (extremely doubtful if Apple is going to jump into ARM for everything in a few years)

Re:why?

[Anonymous Coward]

The only explanation for somone playing games on a Mac is that they are a masochist, so they should be all for this sort of thing.

Re:why?

[jellomizer]

Yea macs are known to be big Gamming platforms.

Re:why?

[KiloByte]

You're comparing with i386, which is an ancient ill-designed ABI. All that "speed improvement" you're talking about comes from extra registers (i386 is extremely register-starved), integer word width (available in 32-bit long mode, too -- only pointer size is reduced), math and vector extensions. You can get the best of both worlds without 64-bit pointers, as long as you don't need multi-gig memory per process. There are tasks that do need such memory, but most are split into pieces that run concurrently.

And while RAM isn't exactly cheap, it's cheap enough to where that penalty doesn't matter to most users.

It's mostly about cache, not RAM.

Unless you care about performance.

Please run some benchmarks. I see you're confusing x32 with i386.

Re: why?

[Gr8Apes]

A PDP-11 requires 600W min of power compared to 5W for Rasp Pi.

Re:why?

[KiloByte]

A typical C++ STL-using project has a lot of pointers. Then, you get larger struct alignment. Java is even worse.

The performance hit from reduced cache sharing between processes for common shared libraries was greater than the performance win from x32.

On not a single machine I even have x32 and amd64 multi-arched within the same container, so there'd be no cache sharing anyway. And who cares about the host if 99.99% of resources are spent by the payload?

Re:why?

[Dragonslicer]

If you have unlimited developer resources, by all means spend them making everything better. If you have finite developer resources, you need to prioritise.

If there's one company out there that has so little cash that they need to carefully control all of their costs, it's definitely Apple.

Re:why?

[pezezin]

The Linux Steam client is 32 bit too. In fact, I think it's the only 32 bit program I have installed.

Re:why?

[dgatwood]

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.

On the other hand, to play devil's advocate, if very few people are actually using the 32-bit frameworks, then there won't be very many bug reports, so the 32-bit frameworks will get very little maintenance. Mind you, they will eventually degrade to the point that they can only run a handful of 32-bit games, but if that's all people are using them for, then whatever. :-)

The funny thing is that I want 32-bit support back on iOS, and I'm okay with it going away on OS X. iOS 11 hurt badly because of the sheer number of abandonware 32-bit apps on iOS that I still used.

The problem is that iOS apps were 32-bit-only for six years (the first couple of years of which were jailbreak-only) before the first 64-bit devices came on the market. That's potentially a six-year window in which app developers could develop 32-bit-only apps, versus only a five-year window for updating those apps to 64-bit afterwards.

By contrast, OS X went 64-bit eleven years ago, and there was only about a year from when the first Intel Macs were released and when the first 64-bit Intel Macs and OS became available. That's a much narrower window in which developers could have created an Intel app and subsequently abandoned it. And that window ended eleven years ago instead of five. With the possible exception of games, if you're still running a 32-bit app at this point, there's really something wrong.

Re: why?

[Anonymous Coward]

Custom sector/track layouts never seemed to bother Photonix fast disk copier.

Re: why?

[scdeimos]

Grab your existing 5 1/4" 360K or 1.2M floppy drive and plug it into one of these USB controllers: http://www.deviceside.com/fc50...

Re:why?

[Anonymous Coward]

If you don't control your costs, then your cash will decrease until you are no longer a company with excess cash. Once you hit the brakes, it might take a few years to stabilize, at which point you could be a dying company with a high burn rate. Getting out of that is hard.

But hey, you know better with your thousand developers and billion dollar company, right?

Re: why?

[Brockmire]

I thought your CPU just needed vt-x and vt-d to support hardware pass through?

Re: why?

[Brockmire]

Sadly, the Phoenix fuck up is in the hundreds of millions. We wish it was only the regular amount of government fuckery in the tens, but this one is legendary. It's expected when the people get fucked by the government, it's unexpected when the government fucks with their own paychecks.

Re: why?

[Brockmire]

I couldn't understand his point. His second and third paragraphs are the same. He does realize he's talking about himself? Normally, I just skip fuckers who can't be bothered to use periods.

Re: why?

[Brockmire]

Uh, Apple targets itself to the 1%.

Re: why?

[Brockmire]

Apple has way more money, but I can't find anywhere that says Apple has more developers than Microsoft.

Re: why?

[Brockmire]

You're fun. It's a joke. They can't print it fast enough. At some point, someone will start measuring Apple cash in number of years it would take to burn it all.

Re:why?

[Anonymous Coward]

Apple has way more money and developer resources than Microsoft, yet Microsoft has no problem supporting 32-bit applications. Try again.

Microsoft doesn't spend much on keeping compatibility, they just keep around old stuff. And if that stops working, usually they just let compatibility lapse. Happens all the time with even small updates to dozens of applications (and even more drivers) - even the current versions of MS apps from time to time. Don't fucking pretend it doesn't. Heck, Microsoft was sued over Windows 10 because it broke so much stuff.

Re:why?

[Anonymous Coward]

Games almost never get new versions.

(for example)

Games almost always break with new Windows versions, often just with updates. If they don't get new versions - which you just pointed out they don't.

Win for Microsoft, because they claim old stuff keeps working and idiots believe them.

Re: why?

[Anonymous Coward]

I have lost about 80% of my games to an older generation of iphones and ipads now pre ios 11 (64bit only now as well)
That, in all, over a 12 yr period was a library of over a few thousand dollars worth of games and apps.
There are ways for me to play these again, but this means spending money on a yester-year product for the sole purpose of my old library.
Sad days indeed.

Re:why?

[Anonymous Coward]

tenfourfox.com

Re:why?

[Anonymous Coward]

Easy fix. DO NOT UPGRADE TO THE LATEST OS.

See. That is very simple. But idiots just want to complain about insignificant stuff.

Re: why?

[Anonymous Coward]

> Uh, Apple targets itself to the 1%.

Since Apple has sold 1 iPhone for every 10 people in the world in the last 10 years, clearly they are targeting more than the 1%.

I'm on my second.

Re: why?

[BronsCon]

Whether they're on staff already or not, Apple has the money to hire them. It's a moot point, anyway, as you'll realize if you read through to the end of my comment.

Re:why?

[Anonymous Coward]

No, but they do stop providing security updates. Maybe someone wants to continue using 32 bit software and receive patches for newly discovered vulnerabilities?

So maybe someone wants to use an ancient software that is full of security vulnerabilities, but is really scared of newly discovered vulnerabilities?

Well, they should seek the sort of help Apple can't provide.

Re:why?

[TheRaven64]

A typical C++ STL-using project has a lot of pointers.

We've measured this and found it less significant than you are implying.

Then, you get larger struct alignment.

That's the big one, though that's much more relevant for the 64 to 128-bit jump, because by now most structures are sensibly laid out for 64-bit systems, but gain padding on 128. We saw a 20% overhead in a couple of benchmarks which went down to under 5% when you rearranged a couple of struct fields.

Java is even worse.

No it isn't, because most Java implementations (including OpenJDK and ART) don't use 64-bit pointers by default on 64-bit systems, they use 32-bit pointers that are left shifted by 3 and added to the Java heap base address. The allocator is happy to 8-byte align allocations, so that gives a 64GB heap size, which is enough for almost all Java programs. JavaScript implementations, in contrast, typically use 64-bit pointers (or, rather, 64 bit gaps in object structures to store pointers in) on 32-bit platforms because they need to handle the case that someone stores a Number (represented as a double) into them.

Re:why?

[TheRaven64]

I assume he means on every API call and worse, on every bit of IPC with the messaging and object subsystems.

The only time things need thunks is when you're communicating between the 32-bit world inside the WINE environment and the 64-bit world outside. At that point, you already need thunks to get between the Windows ABI structure layouts and the host's (typically SysV) ABI structure layouts.

Re: why?

[Opportunist]

That computer ran a few hours per year. Paying for it with power savings would probably require that the work could be done by an Arduino.

I replaced it because of the space it took up.

Re:why?

[drinkypoo]

Well, I just looked, and they have a Javascript engine now, so I guess there actually is an option. But there was no option for a current browser for PPC with Javascript for some time. Thanks for the heads up, maybe I won't sell my last-generation PPC iMac.

Re:why?

[BronsCon]

You think you're arguing with me, but you're not. Microsoft does very little for backward compatibility and, yet, it mostly just works. It would be more work for them to remove that compatibility than it is for them to leave it in place until it breaks, which is probably why they do it. Like I said, one part time guy could handle it, pick up everyone's lunch orders, and detail clean the break room twice a day.

Re:why?

[BronsCon]

Yeah, I'd say that probably applies to plenty of gamers, if we're being honest. Like... and this is just an examples... any Steam users. Get off your fucking high horse, not every piece of old software is a security mess and not every piece of 32-bit software is old.

Re:why?

[fgouget]

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?

Between the 64 bit Wine code implementing the Win32 API and the Windows application calling it.

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.

This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!

Re:why?

[fgouget]

This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!

Although since we were talking about the Mac, X11 and OpenGL would in this case be replaced with 64 bit Carbon, 64 bit CoreAudio, 64 bit Metal, etc.

Re:why?

[fgouget]

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.

Essentially 100% of current 64 bit Windows applications use a 32 bit installer. That's because the 32 bit installer can then show a nice dialog to people trying to run it on a 32 bit Windows telling them they've got the wrong version. The exact same has happened before with the switch from 16 bit Windows to 32 bit Windows: for a decade afterwards all installers were still 16 bit so they could tell people to get Windows 95 or greater.

Re:why?

[TheRaven64]

This assumes you can implement a 32 bit Linux application, one that uses 32 bit pointers throughout, on top of the 64 bit system kernel ABI, 64 bit C library, 64 bit X11 library, 64 bit OpenGL library, etc. Assuming that's even possible, which I doubt, that's really not much better!

Of course you can. WINE is already handling a different ABI to the host system. Code running inside WINE is compiled using the Visual Studio ABI, which is different in a lot of ways (including the size of long on Win64) to the host environment, which typically uses the SysV ABI. WINE includes code that is responsible for loading the EXE and all DLLs, for mapping them into the address space, and for handling relocations between them. When a process all of its libraries, stacks and heap are all mapped into the bottom 4GB of the address space, any 32-bit pointer inside the WINE environment can be trivially zero extended to 64 bits when being passed to other code. You will need thunks, but these can be machine generated in all except a few cases - that's what most operating systems do at the system call layer in for running 32-bit binaries on top of a 64-bit kernel already.

Re:why?

[fgouget]

Code running inside WINE is compiled using the Visual Studio ABI

You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.

which is different in a lot of ways (including the size of long on Win64) to the host environment

This is handled in Wine's C headers. But as mentioned before regular compilers are used so in 64 bit Wine sizeof(long) is 8 (as required by the native libraries that Wine uses), and sizeof(LONG) is 4. So no. No magic! On careful coding.

[...] When a process all of its libraries, stacks and heap are all mapped into the bottom 4GB of the address space, any 32-bit pointer inside the WINE environment can be trivially zero extended to 64 bits when being passed to other code.

Trivially zero-extended or not, code like psecurity_attribute->lpSecurityDescriptor will have to be rewritten because lpSecurityDescriptor is a 64 bit pointer but the psecurity_attribute structure coming in from the application only contains a 32 bit field. If you think going through 1 million lines to fix all such instances is a week-end project then please by all means feel free to send your patch on monday!

You will need thunks, but these can be machine generated in all except a few cases - that's what most operating systems do at the system call layer in for running 32-bit binaries on top of a 64-bit kernel already.

I don't think anyone here can talk for Windows, but as far as I know the Linux kernel does not use "machine generated" code to handle thunking from 32 bit applications. Also the Linux kernel ABI is ridiculously small compared to the Windows userland API. And I'd like to see efficient thunking when the parameter you get is a pointer to a structure with pointers to other structs with pointers... The Windows API sucks in this way. but yes, _some_ can be generated automatically (but will then likely have to be maintained by hand).

That said, I mentioned that there are attempts afoot to handle this anyway. The idea is to only restrict this 32 <-> 64 bit insanity to the lowest level Windows dlls, that is ntdll, ws2_32, directx, opengl, etc. Anything above that that does not interface with native libraries, kernel32, shell32, mshtml, etc, would be compiled as 32 bit dlls. Any high level dll that accidentally uses native APIs (like malloc()) would have to be fixed to only use Win32 APIs. That limits the scope of the problem a bit but still does not make it easy in any way.

Re:why?

[TheRaven64]

You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.

And the compiler targets a specific ABI. Clang (even the Apple builds) can target the 64-bit Apple Mach-O ABI and the 32-bit PE/COFF Windows ABI. The code running in WINE is a mixture of the host platform's ELF or Mach-O binary format and PE/COFF binaries in the Windows ABI, with thunks to go between them.

This is handled in Wine's C headers. But as mentioned before regular compilers are used so in 64 bit Wine sizeof(long) is 8 (as required by the native libraries that Wine uses), and sizeof(LONG) is 4. So no. No magic! On careful coding.

These stubs can be machine generated. The fact that WINE isn't doing so tells you more about the quality of WINE code than anything else - other projects have managed it quite happily.

Trivially zero-extended or not, code like psecurity_attribute->lpSecurityDescriptor will have to be rewritten because lpSecurityDescriptor is a 64 bit pointer but the psecurity_attribute structure coming in from the application only contains a 32 bit field. If you think going through 1 million lines to fix all such instances is a week-end project then please by all means feel free to send your patch on monday!

Why would it need to? Code using that field will mostly be running in the 32-bit ABI. Only things communicating with the outside world need to be 64-bit and these will access structures via machine-generated thunks. Writing a static analyser plugin that will check for cross-ABI structures not accessed via thunks is a few hours work.

I have no interest in contributing to WINE since they changed the license though, so someone else will have to do it.

I don't think anyone here can talk for Windows, but as far as I know the Linux kernel does not use "machine generated" code to handle thunking from 32 bit applications. Also the Linux kernel ABI is ridiculously small compared to the Windows userland API. And I'd like to see efficient thunking when the parameter you get is a pointer to a structure with pointers to other structs with pointers... The Windows API sucks in this way. but yes, _some_ can be generated automatically (but will then likely have to be maintained by hand).

No idea about Linux, but on FreeBSD we do exactly that. For the project that I work on, we machine-generate all of these thunks for 128-bit pointers as well. We also handle ioctls, which have a really horrible design (type information is severely lacking and the values are passed by opaque pointers).

Re:why?

[fgouget]

The code running in WINE is a mixture of the host platform's ELF or Mach-O binary format and PE/COFF binaries in the Windows ABI, with thunks to go between them.

No. Wine is more than a collection of thunks. There is a lot more than a thunk between a Windows application calling CreateFile() and the C library's open() call. Wine has to bridge completely different APIs: CreateFile() vs. open(), Direct3D vs. OpenGL (or Vulkan/Metal/etc. nowadays), etc. That's not something you can machine-generate or call a "thunk".

Why would it need to? Code using that field will mostly be running in the 32-bit ABI. Only things communicating with the outside world need to be 64-bit and these will access structures via machine-generated thunks.

So what you're proposing is not to implement a layer of thunks between a 32 bit Windows application and a 64 bit Wine, but between a 32 bit Wine and 64 bit native libraries.

You cannot compile code using an ABI. You compile code using a compiler and the compiler used is gcc on Linux (normally) and clang on OSX.

And the compiler targets a specific ABI. Clang (even the Apple builds) can target the 64-bit Apple Mach-O ABI and the 32-bit PE/COFF Windows ABI.

And from that point of view the ABIs match, except on 64 bit OSX where, as I mentioned before, OSX uses a register that Windows applications need left untouched. But as soon as you start mixing bitness the ABIs would no longer match. You'd likely have register issues, but the obvious issues is that any time a native library returns a pointer to you you'd have no guarantee that it would be in the lower 4GB and so your native<->32 bit Wine thunks would have to do much copying.

I have no interest in contributing to WINE since they changed the license though, so someone else will have to do it.

Riiight. The thunking you're proposing would work for any 32 bit application on the platform you develop it for. You wouldn't even have to release it under Wine's license since it would be a completely independent work. But sure, blame Wine's license rather than admit it's hard.

No idea about Linux, but on FreeBSD we do exactly that. For the project that I work on, we machine-generate all of these thunks for 128-bit pointers as well. We also handle ioctls, which have a really horrible design (type information is severely lacking and the values are passed by opaque pointers).

Kernel APIs are small compared to the range of userland APIs that Wine uses.

Time

[Anonymous Coward]

In other words, it is time to stop upgrading and buying Apple. I personally have way too many 32 bit programs that I need to use.

Re:Time

[Anonymous Coward]

I haven't bought a new Mac for quite a few years now due to no new Mac Pros, not enough ports on the MacBook Pros,etc, but I'm curious; what are those 32-bit-only programs that you're still running?

Re:Time

[Anonymous Coward]

but I'm curious; what are those 32-bit-only programs that you're still running?

Mainly FOSS like KeePassX. Might be time to try the Mono version of KeePass out again to see if they've fixed AutoType on macOS yet.

Windows wins in the enterprise again

[Anonymous Coward]

Looks like lots of enterprises will be going back to Windows for that sweet backwards compatbility. Even more when Mac switches to ARM.

Re:Windows wins in the enterprise again

[Anonymous Coward]

Even less when Microsoft switches to ARM.

FTFY. Why do you think Microsoft has been resurrecting Windows for ARM again and pushing people towards the Windows 10S app store model?

Re: Windows wins in the enterprise again

[Brockmire]

Because ARM is better for low battery usage, which means fuck all to desktops and servers. You are clueless if you think Microsoft would go all ARM and drop Intel and AMD.

What is the incentive for Devs?

[Anonymous Coward]

Take into account that Apple is going to do the transition Intel -> ARM real soon now, bringing with it even deeper compatibility issues and this alert sounds like "There's no guarantee that going forward OSX will support your binary even if it is 64 bit, but please update your app now... out of pure faith in the future of the platform. Thanks!"

Doesn't seem to make a lot of sense for Devs to take their time to do anything at all at this time.

Re:What is the incentive for Devs?

[TheRaven64]

Any macOS dev who is actively developing their code will already be developing a 64-bit version. XCode has defaulted to fat binary (32/64-bit) builds since 2006 and on all versions of OS X since 2011 and any older version on a 64-bit chip the system will launch the 64-bit version in preference. You have to explicitly opt out of 64-bit support. It's far more common for developers to not bother with the 32-bit version.

Re:What is the incentive for Devs?

[itsdapead]

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 switch. If, in 2018, your application cares whether the CPU is little- or big- endian, presumes the length of an int, or relies on a particular processor's SIMD rather than calling the Accelerate framework, you're holding it wrong.

If it were just affecting new applications entering the App store and otherwise stuck at a once-per-app warning for the next few years, I wouldn't complain - if they're going to axe 32 bit with the next MacOS release well, that's a bit premature.

Re:What is the incentive for Devs?

[Bert64]

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).

Circular argument...

[itsdapead]

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 new better" design philosophy: We got away with perpetual betas, so let's see how far we can get with perpetual alphas... (a.k.a. Agile).

(PS: Kids! Get off my lawn!)

Re:Circular argument...

[nctritech]

The cloud integration into everything drives me insane. I don't want Pocket in Firefox, OneDrive in Explorer, iCloud on Apple EVERYTHING, or whatever trash can privacy violating thing Ubuntu has decided is a good idea to force in the OS and turn on by default this week. Why does every music player need to have a remote control HTTP server inside of it? Why do TORRENT CLIENTS have remote control HTTP servers in them?! Even worse are the so-called "IoT" devices that are all "normal object except Bluetooth-connected" that will stop receiving firmware updates and will never even be opened up, sometimes rendering them merely insecure while other times rendering them 100% non-functional. I can understand some of the functionality but it seems like we're rapidly moving towards a future where our toilet paper will have Bluetooth and report on the fiber content of your freshly wiped ass butter in real time.

When I explain to non-technical people that "cloud means you store it on someone else's computer and trust them to not lose it" and tell them about the T-Mobile Sidekick data loss disaster they tend to agree with my rationale for having a local backup on an external hard drive and not just shoving everything into Dropbox or Carbonite like they're magic bullet backup solutions. Hell, even Carbonite has a built-in "do a local backup too" function.

Re:Circular argument...

[Anonymous Coward]

What would be an ideal is if Apple could make a VM for 32 bit apps. That way, an app where updates are not possible will still be usable, and if one malfunctions, the damage it could do is lessened by it being separated from the main OS and filesystem.

Since Apple is going to roll their own x86 CPUs, they might as well consider having a hypervisor built in, which would provide a lot of flexibility, as well as isolation. Especially if APFS gets deduplication, so one can have a VM for web browsing, one for one client, one for another, etc., and it takes up very little drive overhead.

Re:Circular argument...

[Kjella]

Why does every music player need to have a remote control HTTP server inside of it? Why do TORRENT CLIENTS have remote control HTTP servers in them?!

Yeah, next thing you know some crazy fucker will want to do everything by remote, like a secure shell or something... madness. A lot of the other things I could agree with, but remote administration is a good thing.

Re: Circular argument...

[Brockmire]

Asking such basic usability questions just makes you look bad and a loser with no friends who doesn't leave the basement.

Re: Circular argument...

[Anonymous Coward]

You must be lots of fun at parties.

Re:Circular argument...

[Anonymous Coward]

Except that it isn't "secure shell or something," it's an HTTP server and all the added complexities and potential pitfalls that come with it. Plenty of CVEs over the past decade are related to web UI remotes in programs.

Re: Circular argument...

[Anonymous Coward]

Nice how you don't have any actual arguments. Typical person in a glass house throwing stones.

Short lived

[Bert64]

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:Short lived

[TheRaven64]

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:Short lived

[Anonymous Coward]

There were 32 bit x86 iMacs, too. I know because my praents have one, and it can't run any OS later than Snow Leopard.

Still, we've learned our lesson now - if Apple's going to say "fuck you" to its customers, then I'll do the same to them. PCs only from now on - last time I checked the latest version of Windows (release in 2015) had a 32 bit version whereas the last Mac OS to have one was released in 2009.

Re:Short lived

[Anonymous Coward]

OSX on PPC was a 32-bit OS. (Despite the shrieking that it was a THUPERCOMPUTER!!11!). So you are nuts.

And this is about running legacy 32-bit apps under a 64-bit OS. What's wrong with doing that?

Re:Short lived

[drinkypoo]

Apple should never have supported 32bit x86 at all, and should have moved directly from PPC64 to x86_64.

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. Instead, they stuck with the CPU provider which has repeatedly demonstrated its ill will in the market and are now going to make yet another architecture change which is going to again harm back-compatibility. That cost them a lot of love from the diehards last time, and they think it's a good idea to do it again? They could still remedy their current situation by just going with AMD processors.

It's spectacularly doubtful that Apple can produce an architecture competitive with AMD or Intel. They're just pissing in the wind here, and it's going to cost them again. They can afford the cleaning bills for years to come, but it's still inane.

Re:Short lived

[Pascal Sartoretti]

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:Short lived

[tepples]

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:Short lived

[tepples]

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:Short lived

[Megane]

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.

Re:Short lived

[Megane]

If I had to bet on one or the other, I think Apple would be more likely to switch to AMD than ARM, at least if the adults are in charge, which the past few years of non-phone hardware has not demonstrated.

Re:Short lived

[Joe_Dragon]

Enterprise usage say old hardware that needs 32 bit drivers? or some apps that only work in 32 bit mode?

Re:Short lived

[UnknowingFool]

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. 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:Short lived

[UnknowingFool]

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. Going with AMD meant that Apple would be in the same scenario for a few years as AMD's laptop CPUs were inferior to Intel at the time especially when it came to power efficiency. Assuredly Apple would have liked to go with the best of both worlds but if they had to pick only one supplier, Intel was the better choice.

Re:Short lived

[Anonymous Coward]

There was also the problem that Apple wanted high-end chips from IBM. From a chip fab some chips will be slow, some will be fast. If Apple is buying off the shelf chips and wants only the fastest ones off the line, the slow chips can go to commodity customers. If Apple is the only customer those surplus slow chips go in the trash. It was a terrible decision by both IBM and Apple to use the G5.

Re:Short lived

[drinkypoo]

Going with AMD meant that Apple would be in the same scenario for a few years as AMD's laptop CPUs were inferior to Intel at the time especially when it came to power efficiency.

AMD was within shouting distance of intel's power efficiency for high-performance mobile processors at the time. Intel was killing them on the low end; GEODE was more power efficient than early Atoms, but it didn't scale. However, while Apple has often used not-quite-the-latest processors in their mobile devices, they have never gone for the budget option.

Re:Short lived

[UnknowingFool]

AMD was within shouting distance of intel's power efficiency for high-performance mobile processors at the time

Describe "shouting distance". For most laptops, AMD's chips were inferior to Intel offerings at the time. These days the difference is not as much but back in 2005 when Apple made the decision for their 2006 models, it was more noticeable.

Intel was killing them on the low end;

My point was that Intel was killing AMD on power efficiency on mobile which was something that Apple (like many manufacturers including Dell) wanted.

GEODE was more power efficient than early Atoms, but it didn't scale.

And Apple didn't care about either GEODE or Atom.

However, while Apple has often used not-quite-the-latest processors in their mobile devices, they have never gone for the budget option.

For Intel MacBooks at the time
MacBook1,1: May 2006, Intel Core Duo T2400/T2500: Released Jan 2006
MacBook2,1: Nov 2006, Intel Core 2 Duo (T5600/T7200): Oct, Aug 2006
MacBook2,1: May 2007, Intel Core 2 Duo (T7200/T7400): Aug, Aug 2006
MacBook3,1: Nov 2007, Intel Core 2 Duo (T7300/T7500): May 2007

It appears that Apple at the time were using the latest processors from Intel for the MacBook line when they made the transition. Even if you look at the MacBook 2,1 models released in May 2007, Apple was still using the fastest Socket M processors Intel produced. Sure Apple could have used the T5500 launched by Intel in Spring 2007 but it was slower than then T7400 Intel released 9 months earlier.

Re:Short lived

[scdeimos]

Until your boss asks you for a macOS or iOS version of the application that you maintain.

It's an urban myth that you need a Mac desktop for macOS/iOS development. There are online services out there now that build for macOS and iOS - they even upload the resultant binaries to iTunes Connect. e.g.: Bitrise.io

Re: Short lived

[Brockmire]

Did you even fucking look? That just reflects poorly on you.

Re:Short lived

[squiggleslash]

Windows 10 isn't just a desktop operating system, it's also intended to run on tablets and phones. Non-Appledroid phones are a dead market, but Windows 10 tablets are actually pretty useful.

At the time 10 came out, the tablets were pretty low powered. My HP Stream 8 has 1Gb of RAM for example. It's hard to make a case for running a 64 bit operating system on one.

about time

[jmccue]

I think this is a good move, if only Microsoft would do the same.

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:about time

[enjar]

I was really hoping they would have taken 32-bit out behind the barn and ended it with Windows 10, but they didn't. My company dropped support for 32-bit Windows a few years ago. Even with PAE and other tricks it was consuming an inordinate amount of people's time and resources in terms of regular build failures due to resource limitations, and our customers had largely moved on since the work they used our software for would rapidly exhaust win32's limits, anyway. Microsoft introduced a 64-bit variant for Itanium in 2001 and a 64-bit XP/Server 2003 x86_64 variant in 2005. Drivers were a bit patchy to find, but by the time Vista came around and certainly 7, 64-bit on Windows was just fine. So at this point we are well into a decade past Vista ... please kill 32-bit Windows ... please. Set up a memory garden and build a monument to it in Redmond ... but dear God let it become a happy memory.

Re:about time

[Megane]

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".

Re:about time

[Anonymous Coward]

I concur - 32 bit Windows should die.

You wouldn't think it would matter from the point of view of a .NET Framework application (.NET's supposed to be a ripoff of Java afterall, like Android/Dalvik) but we had all sorts of issues with minor behavioral differences between 32 bit and 64 bit printer drivers/subsystems and networking. We got fed up with it and dropped support for 32 bit Windows when .NET 4.5 came out in 2012 (bye bye, Windows XP!).

Probably because...

[Jamz]

as they prep for the move to ARM by 2020 for the Mac they only want to write one emulator - they only want to have to emulate AMD64 on ARM64 not x86.

Seems pretty clear.

Re:why? (Oh, no, not OnMyCommand)

[FlaSheridn]

I’ve got one, but it may be a deal breaker: ShortcutObserver, from OnMyCommand (http://free.abracode.com/cmworkshop/on_my_command.html).

Future Headline: 64-bit app support ending soon

[Anonymous Coward]

The day will come when people will grumble their old 64-bit computers are still working fine and yet they are being forced to replace everything with 128-bit computers. // I was there when WOW32.exe was temporarily allowing 16-bit programs run in a 32-bit OS environment and there was the mad rush for development to recompile everything into 32-bit or be left behind.

Re:Future Headline: 64-bit app support ending soon

[Thiez]

The day will come when people will grumble their old 64-bit computers are still working fine and yet they are being forced to replace everything with 128-bit computers.

That seems unlikely, even even with a bus speed of 1 terabytes per second it would take over 200 days to visit all bytes in a 64-bit address space once, and with processor frequencies being stuck in the GHz range it seems unlikely we'll have processors that can consume terabytes of memory per second. Of course we can simply keep adding more processors, but transistors simply can't get smaller than one atom so there is a hard limit to Moore's law.

There are various annoying physical limitations that limit how powerful computers can be. There is a maximum information density (bits per volume), the minimum required energy to process information, etc. You can't count to 2^256.

Absolutely, but ....

[King_TJ]

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 series of graphics cards had become and set your hardware requirements higher. If Apple didn't BUILD a new Mac with a better graphics card, you were stuck coding for the ones already out there.) This did have the advantage that it often led to a better quality of programs, since developers had more time to focus on fixing bugs and optimizing the code for the available hardware.

2. In recent years, I think there's been a pretty strong market for trying to breathe more life into the last few generations of Macs. As Apple has switched to a practically non user-serviceable, non-upgradable design across the board, there's some backlash from the community. After all, from 2006-2012, Apple sold the VERY expandable Mac Pro workstations, which can now be bought for as little as $100 or so each. In other cases, like the MacBook Pro laptops? It's been a long time since Apple offered one with a 17" screen -- but some people still really want that feature. So they hang onto to the last of the models that had one.

Granted, all of those Mac Pro workstations were 64-bit capable, as were the 17" MacBook Pro laptops and any older iMac going back as far as the Core 2 Duo CPU in them. But there's at least the FEAR that Apple is accelerating its intentions of obsoleting everything that's not a current model. (The 2006 and 2007 Mac Pro workstations were arbitrarily cut off from OS X support for versions newer than Lion, even though with some hackery - they can run the much more recent El Capitan version just fine.)

Re:Absolutely, but ....

[CastrTroy]

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

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 that died out as well. While not all older Windows software will work on newer machines, there is quite a good history of being able to run older software on new machines in the Windows. I have a PC from 2005 that still runs modern versions of Windows completely fine. You won't fine any Macs from 2005 that are still supported in any way.

Re:Absolutely, but ....

[Gr8Apes]

FWIW, I *do* think Apple has a tougher time justifying these changes to its users for a couple of reasons.

They do? They've been pushing 64 bit since 2003. You haven't been able to buy a mac not capable of running a 64 bit OS since at least 2011.

After all, from 2006-2012, Apple sold the VERY expandable Mac Pro workstations

And as you state - all are capable of running 64 bit. Everything else is just FUD. I still have a soon to be recycled 10.6 laptop from 2006 which can't run higher than 10.7 because of Intel's crappy CPUs, maximum 3GB addressable RAM pretty much killed that series.

Re:Absolutely, but ....

[Anonymous Coward]

Your PC from 2005 is not supported either. That it still runs is testament to the fact that there really hasn't been a great deal of innovation in the PC space in the last 13 years. Just a few speed bumps really. Most of the innovation has been happening with mobile devices, and even that is reaching a head now, so I wouldn't expect to see too many big changes until the "next big thing" makes its way out. It could be VR on the desktop, since that space has died down a bit.

Apple has been pushing developers to 64 bit for over a decade. If you are still pushing out 32 bit versions of an application for Mac OS X without also providing a 64 bit version, and someone is paying you for that software, you really should just give them their money back.

If you are using a 32 bit app on a daily basis (looking at all you guys out there running really old version of Adobe applications because you don't want to feed the beast), then you should really look at alternative software. I know...Inkscape is nothing like Illustrator, and Gimp is...well...Gimp. Feed the beast. You may be surprised that the business model could actually work. Overall, I really only use 3 applications from the Adobe Creative Suite, but the worth I derive from those applications more than justifies the cost of the subscription.

Re:Absolutely, but ....

[e432776]

I was going to write something similar- Apple Inc is pretty brutal about breaking backward compatibility/ dropping features they feel you no longer need (plenty of examples, some notable ones: 68K->PPC->x86; no more optical discs; no more 3.5mm jack).

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 CDROM from 2002, install the software on his current Windows box, and successfully run it. I was impressed.

Re:Absolutely, but ....

[AvitarX]

Even within the Intel era, I've had issues with light use computers.

There's limits to how new an OS some of them can run, and the software (such as Firefox or chrome) doesn't support the older OS.

Additionally, you can't upgrade the OS to the most recent your machine can run, so there were some that I used to manage that could in theory run OSX that could run new chrome/Firefox, but the upgrade was no longer available in the app store.

We switched those computers out with PCs from a similar vintage running Windows 7.

Re:Absolutely, but ....

[AvitarX]

I've had a lot of trouble with precompiled binaries in the past.

Incompatible sound libraries, incompatible glibc, I forget what else.

Maybe that has changed, but running commercial games that didn't use wine was a mess in the first wave of Linux games (bungie era), even quite new ones.

Re:Absolutely, but ....

[scdeimos]

Maybe that has changed, but running commercial games that didn't use wine was a mess in the first wave of Linux games (bungie era), even quite new ones.

A long time ago Wine changed their virtual memory manager subsystem to support ASLR which broke compatability with software and games that required fixed memory layouts - Bungie's original HALO, for example. If you wanted to play HALO you had to use an old Wine version that didn't even support gamepad controllers. AFAIK this never got fixed.

Re:Absolutely, but ....

[AvitarX]

The bungie I meant was before MS baught them, and they released native Linux games.

They were part of the first wave as I'm calling it of commercial games in Linux (myth 2).

Another studio used binaries compiled against wine, and they were a lot easier to get running (forget the game, some toye of RTS with skeletons).

Sim City 2000 (port by I forget who, but their was a company that ported that and alpha century) and myth 2 were very difficult to get running.

But it was a time of major kernel changes and a big glibc change, so maybe everything a year later is pretty compatible.

Re: Absolutely, but ....

[joelito_pr]

Keep a copy of CS2 on a VM with Windows.

Say goodbye to Games

[Jeremy Erwin]

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:Say goodbye to Games

[phantomfive]

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:Say goodbye to Games

[Jeremy Erwin]

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:Say goodbye to Games

[phantomfive]

Or Linux. Linux backwards compatibility is good, and wine runs all the games I use, at least.

Re:Say goodbye to Games

[painandgreed]

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.

I still have an old machine running 10.6 just for that reason. Luckily I found a copy of SMACX on gog.com. It looks like I'll have another one running 10.9 sitting next to it to continue running my Adobe CS5 Suite and other software (once Apple makes a new desktop I'll actually buy).

And this is why...

[Anonymous Coward]

This is why Apple doesn't belong in the enterprise. There are many active and supported applications that are still 32-bit with no need to be recoded to 64-bit.

Re:And this is why...

[Anonymous Coward]

I am sure it is possible to build an encapsulation program, where the 32bit blob is repacked as 64bit application without even recompiling the source. Similar to a VM but with a 32bit app inside it, so that after you double click the app, the encapsulation kicks in and starts to setup/build its own environment where the 32bit is being manipulated while the VM/encapsulation talks to the 64bit API of the OS.

Re:And this is why...

[UnknowingFool]

That depends on how old your hardware is and if it hasn't been updated in a decade or so. Linux will be ending 32 bit support in the next few years and many enterprises have already made the transition to 64 bit. The day Apple stops supporting 32 bit doesn't mean existing legacy Apple apps stop working. It means newer applications have to be 64 bit.

Thats wierd

[Anonymous Coward]

I thought apple stopped supporting the mac itself years ago

HAHAH Something that will never happen on Windoze

[sproketboy]

Windoze will sill be 32 bit in 50 years. FAIL!!!!!!!!!!!!!!!!!!!!!!

32 bit emulator

[jfdavis668]

I'm sure someone will build a 32bit emulator so you can keep running your software.

Re:32 bit emulator

[Anonymous Coward]

Microsoft could just off the source code and recompile WOW32.EXE to become WOW64.EXE. Right? Oh, it's not that simple?

I don't understand

[gordguide]

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 Compatibility is assured by running OSX 10.6x Server in a Virtual Machine. Yes, the server license allows this.

Re:I don't understand

[Megane]

(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.

Just be thankful they're alerting you!

[Anonymous Coward]

If you wanted backward compatibility, the only OS you should even consider is Windows.

Aside from that, no other OS provides long-term backward compatibility guarantees, not even Linux, and ESPECIALLY Apple, who have a LONG history of giving no shits towards backwards compatibility.

They are all about the newest tech; It doesn't matter to them that you depend on some XYZ program that is no longer made or maintained to do your job - That is not their use-case. You have to stay on the cutting edge, constantly moving, constantly updating, constantly upgrading. If a program stops being made or maintained, tough, it's up to you to find a new alternative.

This is how the Apple ecosystem has always worked. You can't claim to be surprised or outraged by this.

Remember, Apple are a HARDWARE company - They don't want you sticking with old hardware because then they don't make any money from it. The software side is your problem, not theirs.

This whole story is pretty moot anyway, since they are apparently moving to ARM and so any x86 Apple hardware, be it x32 or x64, will be equally obsoleted. Old Apple users have already been through this with the PPC->x86 transition so it can't be that shocking...!

Re:Just be thankful they're alerting you!

[Grand Facade]

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 they sell apple phones for that.
Why do I have to have ITunes installed when I don't wish to use it?
Why am I forced to go through the AppStore when there are nasty bits of programming in there that no one should ever install?

If apple treated me better and allowed me free choice I would be more inclined to open my wallet without complaining.

Not overnight, but,

[ReneR]

, Apple themselves made the mistake to ship the first Intel Mac's with 32-bit only Intel Core (1) Duo, so, Also this saves only a few hundred MB, I would much prefer if they kept a copy of 32 bit system libraries so that vintage software games, and office productivity fluff would still work.

I'm ready

[PPH]

Bring on the 33-bit apps!

Re:I'm ready

[Jeremy Erwin]

Wikipedia notes that the dutch machine Zeer Eenvoudige Binaire Reken Automaat used 33 bit words.

I've never used a machine with a magnetic drum, so I don't know how fast it is :)

It's a at least an even bet that....

[mark-t]

... if a person is still using a 32 bit version of an application on a 64-bit OS, then it might just be the case that the app itself is a legacy application for which no 64-bit version was created (possibly by a company that is no longer actively developing it), and the person using the app genuinely needs the functionality provided by that application for some purpose that no alternative software has ever been able to provide.

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.

Re:It's a at least an even bet that....

[rjstanford]

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:It's a at least an even bet that....

[ledow]

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. issues anyway. Otherwise the app will be compromised and/or get switched off by someone anyway.

The decision about what the end-user does hasn't changed. You are either a) getting a new version of the app or already have it, nothing to worry about, b) using an app that's not being developed and hence may stop working / never work on any other system again at any point. If that doesn't prompt at least a warning and review of the situation in your head, then you're not doing anything important enough to care about. If it does, and you make the conscious decision to continuing using it, then you have accepted the risk of things like this.

I'm not an update-immediately guy. I think that's stupid, brash and unthinking to do so without in-house testing. But when I start to realise that I'm using an app that isn't being updated, I do start to research alternatives or worry what I'm going to do when it stops. Even if that's "Oh, it's fine, it'll run in a VM", I still have to think about it and test it.

The words "nothing of import was lost" should apply. If you care about it that much, contact the developers and pay them to continue. Suddenly not that important now that money is involved? Well, there's your answer. Can't get hold of them, can't do that, they refuse to do so? Well, there's your answer too.

I agree they should just have a backwards compatibility layer, at least for a few versions. This is something that Microsoft get right, with WOW64, etc. even if it's not ideal. At least you CAN continue to run old apps seamlessly. The trick is to obsolete them only as fast as they obsolete themselves in other ways. So it's not just "Apple have turned off 32-bit and broken my app" as "apps that were developed for an OS that's 10-year-old won't work any more for a variety of reasons of which 32-bit support is only one of them" by the time anyone notices/cares.

Aren't almost all Linux distributions 64-bit now? Aren't all the server editions of Windows 64-bit only? Did you notice? Did you care? No, because of compatibility layers and the fact that by the time they switched, all the software you wanted has been moved to 64-bit development anyway.

But hinging this on "what the user is still using" is stupid. That's their fault. You can't run modern Samba on ancient kernels or libc, for instance. It just wouldn't work. The fact is that you never noticed because it was never an issue, and anyone trying to do that would be laughed at.

Re:It's a at least an even bet that....

[mark-t]

When did I suggest that people using such applications hadn't been interested in trying or researching any alternatives to them?

My point is that it can easily be the case that no such alternative exists, because the company is not reachable or otherwise has no interest in continuing to support the platform. Is it the end user's fault for failing to be precognitive enough to realize that the application developers would not adapt to the end user's changing OS when most do?

Re:It's a at least an even bet that....

[ledow]

And if no alternative exists, and you can't get the developers to continue to develop it, NOBODY can do anything to help you. If it's not 64-bit, it'll be permissions, or a central library upgrade, or unavailability of the drivers (or hardware!), or incompatibility with new interfaces, or whatever. Something's going to die at some point and blaming the "first" thing to kill it is really disingenuous.

If you are dependent on software which has no alternative, and for which you can't negotiate with the original supplier, and which you can't cope without - your entire purpose/business is on a knife-edge anyway.

There are vanishingly few industries where you literally cannot get software to do X any more. There may be a price tag attached, but if someone sat to make the software in the first place, likely there are a dozen replacements available. The only exception is if it was bespoke. In which case, guess what kind of software you have to replace it with - yep, bespoke.

The fact is that if it's not important enough to contract the company to update, or hire a developer to replace, then it's not that important. Sure, maybe that important to YOU but nobody else on the planet, certainly not Apple etc. If it is important enough, you might have been stung and it might cost you but you have the way out.

And if you have half a brain and have such bespoke software, you would get them to make the software and give you the code such that things like this would be, say, a month of developer's wages to recompile it and fix any issues to make a 64-bit version. Every 5-10 years.

To be honest, basing ANYTHING on Apple supporting your business like this is a real stupid path to even begin down. People moved from apps running on general purpose PC's to back their businesses years ago. Back in the IE/ActiveX era. That's why ActiveX was so popular. Put all the gumph on some central system that can run on anything you like, but access it from Windows 95/98/ME/NT/2000/XP/Vista/7/8/10.

If you are seriously reliant on an Apple app that only works on Apple hardware with a certain version of Apple iOS, and you get to the stage where you have to update the iOS version for any other reason (security, other apps, etc.) then you can never, ever win. Live in perpetually-outdated systems, or have to change the software. Learn the lesson this time round (like people learned it for everything from DOS CNC milling machine apps to ActiveX controls, etc.).
  Reduce that reliance. Solve the problem. Plan for it next time so you know when and where the cost will hit you again.

Re:why? (Oh, no, not OnMyCommand)

[Gr8Apes]

You're complaining about a product that has known problems with the introduction of 10.6 and hasn't been updated in at least 3 years? Maybe it's time to look for alternatives?

The real problem

[Anonymous Coward]

What really frustrates me is that Apple doesn't tell me up front which apps I'm going to loose. They should flag my 32 bit apps with a little blue dot or something, two or three versions before they drop them. SO I could know whether or not to upgrade. The problem is they don't want you to know, because you might not upgrade your OS. And upgrading your OS is apparently a requirement for Apple users.

Re:The real problem

[rjstanford]

Maybe they could start having a dialog pop up when you launch them a long time before they're completely unsupported?

Re:The real problem

[berj]

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?

Re:HAHAH Something that will never happen on Windo

[Anonymous Coward]

Shut up, you fucking retard.

Re:my itouch4g

[Anonymous Coward]

That is something that will bite the software industry sooner or later. Once the economy hits the skids and people can't afford the cloud subscriptions, they will go back to their Office 2008 copies, which may not have bells and whistles... but do what they need. I know someone who runs Acrobat 4 in a virtual machine because it does what they need it to, and they don't care to spend the cash (nor pirate) for something newer. Right now, the economy is booming, but with the trade wars going on, and the specter of a nuclear exchange with Russia, it is only a matter of time before we have another 2008.

You don't fully understand then...

[Anonymous Coward]

The reason Apple supported 32 bit x86 applications was A. Because the original development systems were Pentium 4s running traditional bios, not UEFI. And B. because supporting 32 bit x86 applications helped make verification of 32 bit arm code easier, since the same code could be compiled on x86, x86_64, and arm in order to look for architecture specific regressions. One of the primary reasons 32 bit x86 has been supported so long is that it provided a limited way to check for architectural assumptions in your code without having another platform to test against. It leaves lots of opportunities for screwing up itself, but for little endian applications ensures a much better chance of your code porting cleanly than if you only supported x86_64.

Re:my itouch4g

[Dog-Cow]

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.

Compatibility Victims

[Anonymous Coward]

The usual problematic victims in pulling compatibility feature/layer, are:

1). People/organizations running something really old that is no longer supported. The usual reasons are something like, "we've never found anything better", "it's a tiny part of our organization so we have never invested in a new system", or "we are long since on a new solution but all our history from timecode X and before, is in this legacy application." Sometimes you might also hear, "we had/have a huge project that is way over time and budget. It sucks up all available resources and so this smaller system can't get any love in terms of replacement."

2). We're too poor/small/resource starved/our one expert left. Often this means that the legacy application was actually 'too much' for the organization, in terms of the organization's long-term ability to support it.

Telling resource starved people and organizations, "you shouldn't have done or expected that", is unhelpful and just piling on. And yes, there is a definite pattern of behavior with Apple, abandoning legacy tech and expecting their users to upgrade. However think of this. Has Apple ever announced this behavior as policy? Do they have any written documentation to make such behavior official? Could a low-end user read their web site and discover this, or go to an Apple store and learn how Apple operates with respect to legacy tech? Or are they more likely to hear "Apple is Great!", and "Look At Our Incredible New iPhones, MacBook Airs and MacBook Pros!"

My point is, the people and companies most likely to get caught by this move, are those who had marginal resources all along. They tend to get hurt because they were just barely scraping by and might have technologically overextended themselves.

Re:Compatibility Victims

[UnknowingFool]

Telling resource starved people and organizations, "you shouldn't have done or expected that", is unhelpful and just piling on. And yes, there is a definite pattern of behavior with Apple, abandoning legacy tech and expecting their users to upgrade.

Well hardware wise, you're talking about hardware that Apple hasn't made in 12 years (2006 or so). Second, it's not as if this transition is a surprise to any IT department. 32 bit Unix and Linux servers are also being phased out. Yes there are probably legacy applications that can't be replaced but it's not like this problem is only reserved for Apple.

I forgot Yuge

[Impy the Impiuos Imp]

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

[pubwvj]

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 upgrade their OS which means more security flaw problems.

By doing this Apple forces people to not upgrade their hardware which means lost sales to Apple.

My solution, and many people's solution, is to simply hang on to older machines. The reality is the newer machines are not all that more impressive so there is no push for me to upgrade my hardware or OS. I have work to be done and when Apple threatens to take away my needed tools they just get snubbed.

Re:Silver Hammer

[UnknowingFool]

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.

32 bit applications will still work on existing legacy Macs? If you don't update your OS to then you're fine to us 32 bit applications. You won't get any updates or patches though after 10.13.4.

This is arbitrary and pernicious. There is no good reason that Apple doesn't offer backward compatibility.

Read up on 64 bit models. This is the same model that Unix and Linux uses. LP64 does not guarantee backwards compatibility. Since OS X is based on Unix, the reason isn't arbitrary and pernicious.

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.

If the developers don't exist anymore how can the software get upgraded in any case? If there is a bug, if there is a security issue, it will never be fixed. Essentially you're asking Apple to support software that a 3rd party developer has stopped supporting.

By doing this Apple forces people to not upgrade their hardware which means lost sales to Apple.

My understanding is that the last 32 bit Intel hardware that Apple made was sold in 2006. Well if people want to hold onto their hardware because some piece of software won't work, that's their right but I would think some people would start to look for alternatives.

Re:Silver Hammer

[Anonymous Coward]

Wow. You missed on every single point. Clearly you know little about software, hardware and OS's. Even less about Apple and MacOS.

Re:Silver Hammer

[Anonymous Coward]

those are lame excuses fool stop drinking the coolaid

32-bit apps are abandonware

[Anonymous Coward]

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.

The software for 32-bit apps in ending in an upcoming release in Mac OS X, not in the hardware, and it's been several years since Apple charged for OS upgrades (either Mac or iOS). And this isn't exactly new news (from June 2017):

You may have heard that Apple plans to stop support for 32-bit apps across iOS and macOS. While iOS 11 will remove them this fall, macOS will continue to support them until 2019. Nevertheless, it doesn’t hurt to start early and find the 32-bit Mac apps. Read on to learn how to see which apps on your Mac are still 32-bit.

* https://www.macobserver.com/tips/how-to/macos-find-32-bit-apps/
* https://developer.apple.com/news/?id=06282017a

If a developer can't be bothered to update their app in two years (2017 to 2019), then it's abandoned. The pop-ups are there to warn users: (active) devs should know better.

PDP-11 emulator

[Anonymous Coward]

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.

Or just run an emulator:

* http://www.pdp11.org/

A step on the road to ARM CPUs ?

[perpenso]

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.

Forcing users to 64-bit might better prepare the user base for ARM CPU based Macs. It gets rid of a bit of the unsupported legacy software. More modern and/or currently supported software building on current tools is also software that is more likely to be rebuilt to support ARM, should such Macs appear. Such rebuilt software consisting of a fat binary with both 64-bit Intel and 64-bit ARM code. Sure the fat binary could also include 32-bit Intel but that would complicate developer, Apple and App Store testing for a possibly small benefit. And as other have mentioned the unsupported legacy software may also be an increasing security risk.

Tangent: I'm not expecting Apple to go all ARM. But perhaps an ARM version of a MacBook Air. Longer battery endurance, users more likely to use just the Apple supplied apps, web apps and only a small number of 3rd party apps if any?

Stack vs. GlobalHeap = more speed

[Anonymous Coward]

Passing values or vars thru the local stack IS faster vs. using global heap & in 64-bit you have more registers to use (twice as many iirc + my works bears it out when I place "workhorse" functions thru register calls as I can use 16 of these in a single codebase in 64-bit vs. ONLY 8 in 32-bit (ones I use a lot that do larger/slower tasks OR are use a LOT) to be done via "register" calls (Object Pascal analog to C/C++ fastcall)).

* What I state above IS what compilers have shown me (using things like SmallInt vs. Int in vars too keeping them on the local stack vs. globalheap (& iirc, that means I am using the registers in the CPU vs. global RAM on them also) for decades (not just Pascal but also C++).

You're correct on pointersize doubling afaik though!

APK

P.S.=> Feel free to "set me straight" IF I am in error - but IF I AM? Then so is Anders Heijelsberg & Chuck Andrzewski (formerly of Borland & now @ Microsoft - They're the CHIEF designers of BOTH Turbo-Pascal/Delphi + MS' .NET iirc) - after all - their compilers show me EXACTLY what I stated above as do others... apk

I'll have to pay $600/year to open old CS files...

[Anonymous Coward]

Photoshop has competition, Illustrator less so, Indesign nothing.

LOL! Setting myself straight/small correction

[Anonymous Coward]

"SmallInt vs. Int in vars too keeping them on the local stack vs. globalheap (& iirc, that means I am using the registers in the CPU vs. global RAM on them" - quoting myself on Thursday April 12, 2018 @01:30PM (#56425877)

On cachelines: SmallInt vs. Int OR ShortString vs. String datatypes keeps me in CPU L1/L2/L3/L4 onboard faster cpu caches (local 'stack') vs. SLOWER system RAM (global heap) provided the data fits there (& iirc, the memmgt subsystem will fit them into the proper data OR instruction cache depending on size since each grows in size above the previous Lx cache).

On pointers: They can create memory fragmentation (yes, this can mess up programs - I've seen it do it to Exchange servers & it's how I proved Dr. Mark Russinovich WRONG on memory defraggers/freers - unlike arrays, linked lists (pointer-heavy) don't DEMAND contiguous memory & can be all over memory - this creates fewer opportunities for array creation (especially LARGE ones) if done too much)).

APK

P.S.=> I'd further also like to correct myself on that .NET has shown me that (I don't like interpreted slower code & you CAN be just as safe in non-interpreted IF you know what you're doing) - Only Pascal & C/C++ have (only places I used those methods I noted of register/fastcall function/proc calling)... apk

Good luck judging responsiveness over VNC

[tepples]

It's an urban myth that you need a Mac desktop for macOS/iOS development. There are online services out there now that build for macOS and iOS

Correct. You can use a laptop (MacBook) instead of a desktop (Mac Pro, iMac, or Mac mini). But if you have neither, I imagine the latency added by having to VNC to a Mac VPS in order to test the Mac port of an application is likely to give you a false impression of the responsiveness of its user interface.

they even upload the resultant binaries to iTunes Connect. e.g.: Bitrise.io

How do these build services send a test build to your iPhone or iPad if you haven't connected them to a Mac through a USB to Lightning cable?

Oops, Apple

[msk]

$ pwd
/Applications
$ file */Contents/MacOS/*|grep i386
DVD Player.app/Contents/MacOS/DVD Player: Mach-O executable i386
GarageBand.app/Contents/MacOS/GarageBand: Mach-O executable i386
System Preferences.app/Contents/MacOS/System Preferences (for architecture i386): Mach-O executable i386

Oops.

These, however, do not lead to the pop-up, while non-Apple apps do.

Re:why? (Oh, no, not OnMyCommand)

[FlaSheridn]

If you know of an alternative, I’m all ears. The author is testing a fix for the 10.6 problem.

Tired of Apple.. my macpro 2013 now runs Linux

[jerryjnormandin]

I am running Linux bare metal on my MacPro (early 2013) Desktop. I'm tired of Apple's practices.