Hacker News Reader

Comment by galad87 | Hacker News Reader

Carbon UI framework has been deprecated for 12 years. Cocoa has been available since the first Mac OS X version, so ~20 years ago, and it's still be main UI framework on macOS, and it will still be for years.

You can't come now and whine that Apple changes UI frameworks too often.

View on HN

On the other hand, I've been programming in Windows since about the same time.

In the GUI front I had to work on Win32, MFC, WebForms, Silverlight, XAML and WinRT.

I've been trough two DirectX breaking upgrades where we had to rewrite pretty much everything that touched the API because of deprecations.

Sure, old things keep working for users, but if you stick with ancient technology it gets way too hard to hire developers.

I'm not complaining though: I love writing code and upgrading things is a breath of fresh air. Every Microsoft API was significantly better than the one preceding it, IMO.

I write Windows desktop app in WPF since December 2009 and I'm confident that I won't write them in anything else for at least the next 10 years (desktops are supposed to be dead by then but I hope the 'visionaries' are wrong.

I think another issue is that on Apple's platforms the changes are quite abrupt, whereas most other platforms are gradual. E.g., if you wrote a Qt (the toolkit) application in 1996, you could have slowly transitioned your application to Qt 5 version by version. In the meanwhile, you have gone from non-standardized C++ to C++98, to C++11. So, you would have an application with a modern language and toolkit, which was gradually developed over the last 23 years. The same for Windows applications.

For me, the truth is somewhere in the middle. Yes, there is more churn on Apple platforms. On the other hand, it also allows Apple and the ecosystem to move faster. It is amazing what they have been able to achieve with (just naming some random things): wide Touch ID support, Metal, or application sandboxing.

You could have done the same with Carbon to Cocoa: transition a window/view at a time. You can use Cocoa windows and views in Carbon.

Plus you can keep using your C++ core even if the UI is Cocoa. The same applies to Swift, you can write or rewrite parts of the app in Swift and keep part of it in C++/Rust/Objective-C or your preferred language.

The same happens in SwiftUI, you can mix it with NSView and UIViews.

AFAIK Carbon was a C++ API and Cocoa is Objective C(++). In which case the UI is a rewrite , not a transition.

You rewrite one screen at a time.

It's almost like the people complaining the loudest don't have a profitable software product that justifies regular ongoing maintenance or something.

Carbon is a C API.

Carbon continued to work for 13 years after it was officially deprecated. Waiting over a decade to get started on a transition doesn't mean that the transition was abrupt; it just means that you procrastinated until you got a hard deadline and so caused scheduling problems for yourself.

I think that is precisely what they are doing. I can run apps that worked on Windows 95 today in 2019 unmodified. Cocoa or not, I can’t do that with osx apps that are even 3-5 years old sometimes.

Microsoft and Linus have a specific fanatical attitude about the installed base of existing apps. Apple simply does not.

I actually like that. Some software dies and makes room for more modern replacements. All Mac software that I have is modern and consistent.

Contrast this with Windows, where browsing through system settings is like going back in time from Windows 10/8 to XP to 95 all the way to 3.11, if you click "Advanced" enough times.

Some Windows applications (especially installers) pop up dialogs that don't support anti-aliased fonts. It gives an impression of an OS with wildly inconsistent GUI and legacy garbage all over the place.

what about games? I like to play some old games out of nostalgia

Virtualization? Why is it necessary to eternally keep shims and compatibility hacks in the host/main OS when nowadays we can just trivially run the old OS?

How do I trivially get a copy of Mac OS 10.5 Tiger?

This isn't FLOSS.

Next suggestion will be to keep old computers around if you want "old" software.

Repairing Macs is an issue though.

You should keep a few replacements in reserve in case some minor component fails.

10.5 was Leopard actually, 10.4 was Tiger. And both were PPC and thus would require emulation not just virtualization. For something that ran on those what you'd actually probably want to run would be 10.6, because that would give you an Intel based OS that still included Rosetta for PPC compatibility. I can't think of any applications that ran on 10.5 but wouldn't work under Rosetta off the top of my head, though perhaps there were a few. And I vaguely recall there was a security update in 2012 (about 3 years after 10.6 launch) that caused issues with Rosetta, but in a VM you could just not apply it since a VM that old should be isolated anyway, or maybe they later fixed it.

But at any rate I'd assumed that for someone who had "nostalgia" for old games would therefore have played those old games and thus had that system, and thus could just have kept it around as a disk image. I have Mac OS disk images going back to the beginning, it was by far the best way to install anyway because it was so much faster than actually going off the disc (the ease and customizability of network installs was also wonderful, I miss that). For really old stuff you can just emulate it via something like SheepShaver, no need for VM at all. I actually find that's the same as Windows, for all its vaunted backwards compatibility I had the damndest time getting some old games working under W7 even and it was much, much easier to just keep some VMs around cover 98, 2000, and XP. Those are old enough there is full virtual 3D support, even without hardware passthrough.

If you really wanted an old copy of 10.5 or 10.4 or whatever directly despite having not used/kept them, and you didn't want to get it off the net, you could just ask around a Mac site or buy a DVD. A quick look on Ebay shows tons for sale for $10-20, it's not as if they are some rare collector's item. And if you went on some Mac forum and just asked there'd be people with images like me or old discs just sitting around in closets collecting dust you could have for a stamp. It'd be a one-time issue, because then you'd immediate image it and keep it forever since they aren't big (looks like my Mac OS X Server 10.6.dmg is about 6.95GB).

Both 10.4 and 10.5 could run on x86 platforms.

10.5 supported x86 out of the gate.

Right you are! I wonder why 10.6 stuck in my head, I even got the first Xeon MP (as a free replacement from Apple for my G5 PowerMac liquid cooling blowing out and destroying my system utterly) in 2006 and it was Tiger. What a time since then. I guess 10.6 Server was the first officially virtualizable version so maybe that's why, but yes you're absolutely right, 10.4(.4) and 10.5 should both be runnable in a modified VM in principle.

Though I'd suggest its probably easier to run the PPC versions at this point.

eBay?

You can download it (and every other old version of macOS) from the developer portal: https://download.developer.apple.com/Mac_OS_X/mac_os_x_v10.5...

Those links don’t work for me anymore, and besides, I’m fairly sure they only had Leopard and Snow Leopard. It is surprisingly difficult to get access to old versions of macOS, even ones that you paid for.

Every version of macOS is listed and the downloads work for me. You'll need to log into an apple account first.

I have a valid Apple Developer account logged in and it doesn't seem to work for me :(

> paid for

I think you mean "obtained a license to use" ;)

While you did purchase the license, (IANAL) I don't think Apple is legally obligated to produce the original software for which you obtained a license for, at least per the license agreement[0].

0: https://images.apple.com/legal/sla/docs/osx_snow_leopard_sec...

I'll take an ugly installer over a crashing installer any day of the week.

I'll take a good looking, non-crashing installer over an ugly installer or a crashing installer any day of the week.

> Contrast this with Windows, where browsing through system settings is like going back in time from Windows 10/8 to XP to 95 all the way to 3.11, if you click "Advanced" enough times.

Note why we know this. We know this because those legacy dialogs are useful and no one could be bothered to rewrite them with new GUI toolkits. Probably someone would write new dialogs if the old ones were forced to die. Probably the replacement would even be more convenient. Or probably not (on both counts).

The dialogs are extensible by third party drivers and applications. Microsoft has api’d itself into a corner, that’s why they can’t bring many of the dialogs up-to-date.

It's not like there's a limit on space. Also this is a choice, and having choices is pretty good IMHO.

Linus personally has really strong opinions about breaking userspace, but the Gnu/Linux distributions do not. Heck, when I installed Inkscape from the Debian 10 repositories, copy and paste wasn't working because they decided to remove python-uniconverter due to bugs.

Linux is a very different case. Linus is talking about the kernel breaking comparability with userspace.

The kernel not breaking userspace is quite a different thing, and in particular when comparing the macOS kernel and Linux because Linux specifically has a stable ABI and macOS doesn't. On macOS it's libsystem that provides the stable abi and kernel interfaces change underneath.

Beyond the kernel API's and libsystem you have the actual platform interfaces. Carbon is a deprecated framework and has been for a long time. If apps are using carbon then they must get updated, Apple has been warning about this since 2017 (beyond just the depreciation notice in 2012 and everything in between).

And Windows95 apps almost certainly do not run unmodified... it's been awhile and things may have changed, but as I recall in XP (sp2, even?), they introduced the thing to run an app in compatibility mode and you actually select which is version to be compatible with. This works in some cases and not in others. Not to mention win32 support has held back Windows stability and progress for a long time.

I was recently greeted by Brew message that my Mac OS X is too old and is not supported :) It was simply a warning, the installation (GNU tar) run OK and gtar worked. The OS is El Capitan and it's just turned 4 years.

Apple dropped security updates on El Capitan with release of Mojave. El Capitan is supported on MacBooks from 2009. I think it's time to upgrade.

Under 1% of homebrew users are on 10.11 (https://formulae.brew.sh/analytics/os-version/30d/), so continuing to test on that OS version would not be a good use of the maintainers' time.

Interesting that there are five times as many Brew events from Catalina machines than El Capitan machines, and Catalina isn't even out yet.

El Capitan machines are already set up, Catalina machines are being set up?

Since macOS updates are free, is there a reason you haven't moved off of El Capitan?

Do you just like the way it looks and feels? Is there an essential program that you use that need El Cap? Are you using a 2008 MacBook?

I'm not being critical. I have to run Jaguar on a dedicated machine I keep in the closet for a niche reason, so I'm curious what problem you face.

It's old hardware, it cannot run anything newer: Mac Mini 2009. Pretty snappy otherwise (with maxed memory). It just sits on desk, I mostly use it via SSH.

Homebrew in general is very aggressive about dropping support for older versions.

Carbon UI framework has been deprecated for 12 years

Interestingly, Carbon still pops up here and there, even in programs from large companies with tons of resources like Adobe.

The giveaway is when you ask it to do something hard and instead of getting the SPOD, you get the watch icon.

As a kid who learned computers on Mac OS 7, that's beautiful

The NSMenu system is still Carbon actually, as far as I know (last I dug deep into it).

Furthermore, from the start Carbon was intended as a transitionary solution and Apple told devs this many many times. Carbon apps were supposed to be the bubblegum-and-duct-tape answer for holding users over while you worked on your Cocoa version. It’s not Win32 or MFC and Apple never claimed it was.

This is true in hindsight and seemed obvious at the time, but in fact Apple insisted that Carbon was a long-term solution and treated it as an open-ended commitment. They dogfooded it internally, using it to write the Finder and iTunes, two first-party apps so central to the user experience that novices confused them for the OS itself. There were working betas of Carbon 64, and Apple's decision to reverse course and deprecate Carbon on 64-bit platforms in the middle of the release cycle caused significant developer whiplash.

Why in hindsight? It was a compat layer for essentially adapting OS 8/9 software for OSX.

It was deprecated in 2012. In 2017 with High Sierra they announced that carbon apps would require changes to work at all.

Nobody with any sense really believed Apples protestations during the 1999-2007 time period that Carbon was going to be a long term solution, but Apple really tried to sell folks on the idea that it would be, until they suddenly low-key ghosted on the Carbon developer community at WWDC 2007, when 64-bit Carbon was quietly removed from the keynote deck a year after it had been prominently featured.

https://www.macrumors.com/2007/06/13/leopard-drops-carbon-64...

Archive.org records the wailing and gnashing of teeth which accompanied the relatively sudden announcement:

https://web.archive.org/web/20140115143937/http://lists.appl...

https://web.archive.org/web/20140115112428/http://lists.appl...

You can still find developer documents in Apple's archives referring to a 64-bit upgrade path for Carbon apps.

https://developer.apple.com/library/archive/documentation/Ca...

Apple didn't present Carbon as merely a compatibility layer at the time. It was positioned as the procedural C paradigm alongside Cocoa's and Java's object-oriented paradigms. Carbon was supposed to be one of the three development frameworks for OS X alongside Cocoa and Java, which is why Cocoa and Carbon have drink-themed names to fit with Java. Porting a classic app to Carbon was "Carbonization."

Carbon wasn't presented that way in the beginning. They were supposed to be the three equal pillars of OS X development. Carbon was the C-based procedural framework, Objective-C was the object-oriented framework, and Java was, well, the Java framework.

That's why they have drink-themed names to fit with Java. Porting a classic Mac app to Carbon was called "Carbonization."

Reply on news.ycombinator.com