Hacker News Reader

Comment by droithomme | Hacker News Reader

I've been through this process with several projects. At this point a Carbon codebase like that needs to be rewritten from scratch.

The best path forward if you want a program that works like the old one but runs on the current version of macOS is to use the old version to create a requirements document and then develop that using modern techniques.

Same as with restoring a 19th century farm house with a bad foundation. The cost of restoring it and bringing it up to modern standards will typically be 5-20 times more than knocking it down and building a lookalike from scratch using modern building techniques.

View on HN

I have no specific experience with carbon but in almost (arguably) similar cases I've come across as a developer, I've found a better approach to look for a mechanism to allow for granular upgrades over time.

In this specific case I could imagine supporting both carbon and cocoa screens / logic at the same time, and begin conversion screen-by-screen or feature-by-feature.

In the end this might mean maintaining extra complexity to support both technologies, but protects you from the danger of having to implement a complet syst m to feature parity at once.

I believe at this point no incremental upgrade is possible, because Carbon is entirely deprecated and will not run on current Macs.

You could reimplement Carbon in Cocoa.

You’re so right, I’ll go grab the source code for both and work on that right away.

It’s so obvious - why has nobody done it before?

Carbon apps do run on current Macs, and on the current macOS (10.14). But that's the end of the line. Carbon is 32 bit only, and Apple has announced they are dropping 32 bit soon.

It's not actually. Only the UI parts of Carbon are deprecated:

"We are still planning to support the Carbon Event Manager and Text Input Sources, to name two mostly non-UI APIs. You might wonder, what about the Memory Manager, or the Alias Manager, or the Process Manager, or other lower-level managers? At this time, it looks like most, if not all, of the APIs provided by the ApplicationServices and CoreServices umbrella frameworks will still be available in 64-bit." - Eric Schlegel (apple developer)

Supporting Carbon isn't really an option, it was a technology designed to ease porting from OS9 to OSX. It's been deprecated for years, is 32 bit only and is being dropped completely after macOS 10.14 Mojave.

I think it would make more sense to slowly port the Windows version to Qt. And then when that process is complete, you get a Mac and a Linux version.

Depends what you mean by Carbon. If you mean "the UI parts of HIToolbox", then yes, Carbon is deprecated. If you mean Carbon in general, most parts of it have been ported to x64, and you wouldn't call that deprecated.

I don’t know why you got downvotes. I cut my programming teeth on Carbon and worked my way through several ports of side projects, and you are absolutely right.

Moreover a complete rewrite doesn’t exclude any truly unique parts of the old codebase from being ported into the modern one.

He might be getting downvoted for cultural reasons... in much of continental Europe knocking down and rebuilding a look-alike house from scratch is tantamount to vandalism.

(I voted him up, but the analogy did make me squirm.)

More likely, a cargo cult reaction based on a “Netscape went out of business because of a rewrite” blog post from Joel Spolsky fifteen years ago.

I disagree with the "requirements document" bit. I do think it's better to move to Cocoa, but this should be done bit by bit. Start with "the upstairs" (the user interface), which absolutely MUST be in Cocoa to be 64-bit, then move everything else with time to Cocoa.

> At this point a Carbon codebase like that needs to be rewritten from scratch.

Hopefully you can just swap out a UI layer. You shouldn't need to rewrite any business logic.

Carbon isn't just a UI toolbox, it also has API for file IO, memory management, etc, etc. The business logic could be using it too.

These are easy to replace, though.

Reply on news.ycombinator.com