4 ms·

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 yo

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.

EmielMols 8y ago
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.
- cnasc 8y ago
  I believe at this point no incremental upgrade is possible, because Carbon is entirely deprecated and will not run on current Macs.
  - ksherlock 8y ago
    You could reimplement Carbon in Cocoa.
    - lostgame 8y ago
      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?
  - 1over137 8y ago
    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.
  - honeywhite 8y ago
    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)
- FigBug 8y ago
  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.
  - honeywhite 8y ago
    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.
deleted 8y ago
[deleted]
matheweis 8y ago
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.
- qubex 8y ago
  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.)
  - mikestew 8y ago
    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.
chrisseaton 8y ago
> 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.
- 1over137 8y ago
  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.
  - zozbot123 8y ago
    These are easy to replace, though.
honeywhite 8y 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.

EmielMols 8y ago

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.

cnasc 8y ago
I believe at this point no incremental upgrade is possible, because Carbon is entirely deprecated and will not run on current Macs.
- ksherlock 8y ago
  You could reimplement Carbon in Cocoa.
  - lostgame 8y ago
    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?
- 1over137 8y ago
  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.
- honeywhite 8y ago
  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)
FigBug 8y ago
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.
- honeywhite 8y ago
  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.

deleted 8y ago

[deleted]

matheweis 8y ago

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.

qubex 8y ago
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.)
- mikestew 8y ago
  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.

chrisseaton 8y ago

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

1over137 8y ago
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.
- zozbot123 8y ago
  These are easy to replace, though.

honeywhite 8y 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.