The Future or Lack of It for Carbon

If you are tasked with maintaining a large, old—is there any other kind—Carbon application, here's an illuminating experiment. In XCode 3.0, under Build architecture, turn on 64 bit compilation for Intel. Now try to compile.


In my case, I see errors and lots of them:

error: '::FlushVol' has not been declared
error: 'HideCursor' was not declared in this scope
error: 'ShowCursor' was not declared in this scope
error: 'LMGetFractEnable' was not declared in this scope
error: 'GetOutlinePreferred' was not declared in this scope
error: 'GetPreserveGlyph' was not declared in this scope
error: 'GetWindowEventTarget' was not declared in this scope
error: 'SetFractEnable' was not declared in this scope
error: 'SetOutlinePreferred' was not declared in this scope
error: 'MoveWindow' was not declared in this scope
error: 'SetOutlinePreferred' was not declared in this scope
error: 'OpenCPicture' was not declared in this scope
error: 'SetControlPopupMenuHandle' was not declared in this scope
error: '::SetControlMaximum' has not been declared
error: '::DrawThemeMenuItem' has not been declared
error: 'GetIntlResource' was not declared in this scope
error: 'CompareString' was not declared in this scope
error: '::SetMenuWidth' has not been declared
error: 'IsWindowVisible' was not declared in this scope
error: '::GetPicture' has not been declared
error: '::DrawPicture' has not been declared
error: '::EraseRect' has not been declared
error: '::FindDialogItem' has not been declared
.... lots more errors ...

So, we have a litany straight out of Inside Macintosh Vol. 1-3: all of QuickDraw, much of the File Manager, the Control Manager, the Dialog Manager, the Window Manager, the Menu Manager, the Font Manager all gone, but surprisingly not the Resource Manager. Anything that uses Pascal strings or FSSpecs. Few of the API's which came from the Classic Mac OS survive a 64 bit compile.


I don't know in the short term, what the carrot is for getting independent developers to make 64-bit compiles. Unless you are doing something that really needs 6 GB of real RAM—very few applications—there seems to be little performance advantage for 64-bit. And, it's hard taking a Carbon application, ripping out the APIs behind its entire GUI, and putting it back together again. Lots of redesign and drudgery for little immediate payoff. In the long term, Apple will presumably stop supporting 32-bit applications, but that is in the very long term.


Plus, there are little bits of functionality in the Carbon APIs which are hard to replicate in the more modern APIs. One example is embedding one's private metadata in the PICT clipboard flavor. I'd very much like to know how to do that with the PDF API. Another example is the XOR drawing mode for doing tracking, stupid and old fashioned, yes, hard to replace, yes.


There's an Ars Technica article which goes into this in more detail.

It's Time for Carbon Apps to Support RTF on the Clipboard

I don't know when the 'styl' resource was defined, but I do know it is very, very old. For those not in the know, back in the days of the Mac II, if you wanted to copy and paste bold/italic/underlined/colored/text from your application to another, you put both a 'TEXT' Handle on the clipboard, and a Handle filled with individual style records (the 'styl' flavor), with each record corresponding to a range of the raw text in the 'TEXT' resource. You could even put in foreign words and phrases by switching to lets say a Japanese font. This was what was done in 1987, it was what was done in 1997, and it is what most Carbon apps still do in 2007. I fired up iTunes Friday, copied something from a dialog, and looked at what was on the clipboard: a 'TEXT' resource and a 'styl' resource.

Well, what's wrong with it?

Here is an individual style record from TextEdit.h:
struct ScrpSTElement {
long scrpStartChar;
short scrpHeight;
short scrpAscent;
short scrpFont;
StyleField scrpFace;
short scrpSize;
RGBColor scrpColor;
};
And here are the things you can put in a StyleField:
normal = 0,
bold = 1,
italic = 2,
underline = 4,
outline = 8,
shadow = 0x10,
condense = 0x20,
extend = 0x40
What's wrong?

• No superscript or subscript, not even one level. Try pasting data from a scientific app to MS Word. H⁺₂SO₄^-2 becomes H+2SO4-2.
• It takes an old fashioned QuickDraw font ID, not an ATSUI ID, so it may be difficult to map to the fonts you're actually using.
• No paragraph alignment information. You can have any justification you want as long as it's left.
• Text encoding is by necessity implied by the QuickDraw font encoding.
• The OS has to go through and endian swap every element before pasting across Rosetta.

So what is the alternative?

There is nothing preventing you from supporting the 'RTF ' (Rich Text Format) flavor on the clipboard. It's a Microsoft invention, so you know Word will like it, and it satisfies all the problems I enumerated above. Plus, it's the favored flavor of any Cocoa application, so your text should be more accurately transferred to newer applications.

It's just a matter of implementing it. As I was already mixing in Cocoa into my Carbon application, I built up an NSAttributedString, extracted the string's content using the RTFFromRange:documentAttributes message and stored that raw data in a Handle. When I, inversely, wanted to paste, I extracted styled text information from an NSAttributedString created from the data in an RTF Handle. I did it all in a day for my application. (Sorry, can't share the code.) This has the added advantage of using the exact RTF flavor Cocoa applications get for free.

Alternatively, you could pretty easily create simple RTF documents from scratch using the description of the format in O'Reilly's RTF Pocket Guide. Parsing such documents looks to be a lot harder, but doable, just ignore the tags you aren't interested in.

I could hardly be happier with the result. My users will be getting a nice little present come the next release, and I'm one step closer to expunging the last bit of QuickDraw from my application. If you are maintaining a Carbon application which has anything but the simplest text formatting requirements, do your users a favor and look into supporting the 'RTF ' clipboard flavor.
[Entry has been edited for content since first publication]