> There weren’t many 32 bit only Intel based Macs.
I don't understand, why Apple even created x86 osx ABI.
When they introduced the first x86 Macs, the writing was already on the wall; in the same way, that there are claims that Carbon was deprecated for years, x86 was in the door on its way out. You would not create a new Carbon-based app today, Apple introduced ABI in similar circumstances? Well, maintaining it then for decades to follow comes with the territory.
Yes, as an user, I do mind removing it. For example, Apple had broken Preview scanning on Samsung MFPs for the entire Mojave lifecycle ([1], [2]), there's no indication that they are going to fix it, and as a workaround, users are using Samsung Easy Document Creator, which talks directly to scanner, avoiding Apple scanner libs. Yes, it a 32-bit app.
When apple started their intel transition, intel used 32 bit CPU’s primarily. The first intel macs (core Duo) and intel dev kits were 32 bit, the core 2 duos onward were 64 bit. It’s really a small amount of Macs.
The previous gen, P4 and P-D were already 64-bit, XP 64-bit and 2003 64-bit was out, Linux was 64-bit for years; Core Duo not being 64-bit was a stop-gap and everybody knew that. Creating new ABI on that was exactly like launching a new Carbon project today, that's why I compared these two in the first place.
Nah. P4s, a gig of SDRAM, either a GMA 800 or GMA 900 for graphics, a 1x and a 16x PCIe slots, a 160GB disk and a DVD drive all running on the first Tiger service pack (10.4.1). Yours for 18 months for only $999! (‘Twas a rental.)
Late Pentium 4 in a pretty much random standard PC motherboard, I think it didn't even have EFI (even the broken 2001-vintage one that was common for years on x86 Macs).
> The people I hear complaining about this are those who, like you, didn't move to Cocoa. Carbon was a _temporary_ transition API*. It was necessary when Mac OS X shipped in March 2001, but even though it wasn't yet formally deprecated, it was clear it would be.
Actually, considering the long-term average growth of “developer market-rate salaries” it makes sense to transition as early as possible (as soon as the new alternative is announced/becomes available) to minimise overall cost and capture the market share of those who shan’t transition when deprecation is announced and cost of developers is too high to make it worthwhile.
Except if the new thing flops and the old thing doesn’t die - which is much more common in the Windows world. MFC is mostly dead. So are ATL and WPF. Win32 is still going strong though.
It's a bit judgmental, though the original complaint is also a bit whiny.
The reality is that Turtle couldn't make the business case to port to Cocoa at any point for 18 years, probably because most of their customers were Windows.
That's not them being lazy, that's just them directing their resources according to market demand and engineering constraints.
And Apple is not being greedy or uncaring, they also have to direct resources according to market demand and engineering constraints.
If Turtle had more Mac customers, they'd have either ported their app, or they'd purchase a Carbon compatibility library. And if more developers were actively using Carbon, Apple would put more resources into it.
They aren't, and so the two are going to part ways.
> But that's part of what lost them their lead after the '90s
I think that guy lives in a bubble, Microsoft is still by a huge margin the lead in desktop OS market share :-P.
And really the main reason is that they try their hardest to not break people's applications. If Windows suddenly couldn't run the applications people wanted, everyone would migrate to Linux (and some to Mac, but Linux is free so the majority would go for the free stuff).
I've seen quite a few legacy Windows app needing to be run as administrator, compatibility mode, or both. Just because you can do something doesn't mean you should. It's glaringly irresponsible that applications should be given read/write access to the C:\Windows folder because that was acceptable in the 90s.
Now when I get an exe that needs to run in compatibility mode I don't even bother with it. I'm not compromising my computer because a developer has abandoned their software.
Jens is way oversimplifying the developer story around Carbon, FWIW. It existed because Adobe and Microsoft wouldn’t port their apps without it, and that wasn’t going to change in the foreseeable future. It wasn’t deprecated in the technical sense until 2007.
Yeah, the arc was that Cocoa was the future, but as late as 2007, Carbon was still widely considered a viable target for new apps.
> Yes, it says that they didn't bother to waste resources doing unnecessary changes.
Keeping up with API changes from a decade ago doesn't qualify as unnecessary.
> There is no way to spin Apple breaking APIs and programs that people have worked on (for developers)
Here's the point. Apple isn't doing that. Apple don't visit customers with old macs to push breaking patches.
What happened is the developers made something that worked on old macs, didn't put in the effort to keep it up to date and are now complaining that Apple won't put in the efforts to support the old APIs on new systems anymore.
> Keeping up with API changes from a decade ago doesn't qualify as unnecessary.
The API didn't change, it worked until Apple decided to break it in a subsequent version of macOS.
> Here's the point. Apple isn't doing that. Apple don't visit customers with old macs to push breaking patches.
They broke the API in new macOS.
> What happened is the developers made something that worked on old macs, didn't put in the effort to keep it up to date and are now complaining that Apple won't put in the efforts to support the old APIs on new systems anymore.
Yes, that is exactly the issue: Apple shouldn't have broken the API in the new macOS. The developers are perfectly in their right to complain about Apple breaking their applications and forcing them to waste time rewriting code that already worked to do the exact same thing only now in a different way because Apple doesn't care about the developers' time.
And yes, it is all on Apple - the breakage wasn't forced on Apple, it was something Apple decided to do.
If in OS version N a program works and in version N+1 the program doesn't work, then the OS version N+1 broke the program. That is all there is to it, anything else is just excuses.`
There weren’t many 32 bit only Intel based Macs.
This complaint says far more about the developer than Apple.