1

I am working with multiple Mac projects that were written during the awkward time between OS 9 and OS X, so it is written in pure C using Carbon, no Cocoa, Objective-C, or really anything modern in sight. Some of the projects I have the .xcodeproj files for, but they are useless with modern XCode (the project files were created with XCode 1).

I've brought some of them into XCode projects under XCode 6 (the earliest version I have access to right now) using the Command Line Application preset and the 10.4 SDK restored. However, using this present doesn't actually build a proper .app, so the nibs never get included. I tried writing some non-nib Carbon apps (unrelated to the old code), and it seems like everything up to opening windows and drawing into them works, but the windows never updates, even all the Carbon Event handlers are in place. Clicking on buttons does nothing, I can't drag the windows around, and the app never even appears in the dock. It seems the entire app just stops after the call to RunApplicationEventLoop()

I tried putting some of the code into a project made with the Cocoa preset with all of the premade code stripped out, but that seems to have just made XCode angry. Is there any way to essentially get a replacement for the Carbon App present that was in old versions of XCode?

Collin L.
  • 11
  • 2
  • Oof. I can't speak from experience on how this might be done — I'm guessing that it might be possible, but likely won't be easy. Carbon was deprecated 4 years ago, and some functionality may have gone away since then. (At the very least, many tools no longer support it, like Xcode.) I'm guessing you can't move this code away from Carbon? What are you looking to do with the code? – Itai Ferber Oct 30 '16 at 06:31
  • I have multiple projects that share some parts. All of these projects split from a large app that was classic Mac OS only (written for OS 8 w/ Macintosh Toolbox, but eventually brought to CarbonLib), and parts of this app were carbonized for OS X around 2001-2003. I'd eventually like to port the large app to OS X and have it be Cocoa compliant, but it will be a much smaller project to get in running in Carbon for the time being. These smaller Carbon parts that I'm referring to in the question were indeed written for OS X; I have the compiled binaries that still run on modern OS X. – Collin L. Oct 30 '16 at 06:51
  • I'm also thinking that it could just be asking too much to ask of XCode to work with code that is old enough to drive. I may have to procure a PowerPC Mac and and equally aged version of XCode before trying to compile anything on modern XCode. – Collin L. Oct 30 '16 at 06:58
  • Actually — if your compiled binaries run on modern OS X okay, that's a pretty good sign; you're not relying on any Carbon functionality that may no longer be present. So, it should really just be up to setting Xcode up with the right incantations to get it to compile. (It's not that Xcode _can't_ get your app compiled, since all Xcode does is run the compiler for you with some arguments, it's that we need to find the right arguments to get it to work.) Do you have a sample of one of these smaller projects to play around with, or is the code private? – Itai Ferber Oct 30 '16 at 17:33
  • The code that would be most helpful to share is private, and the ones that I could share would be very old and a mess (with a ton of #ifdefs to see if it it running on a Carbon or Macintosh Toolbox environment), but the problems are easily illustratable in simpler code. I'll whip up a small, clean Carbon project that shows what I'm talking about today. – Collin L. Oct 30 '16 at 21:11
  • Excellent — I would love to help, I just don't have any Carbon code laying around to try out. – Itai Ferber Oct 30 '16 at 21:15
  • OK, I wrote about 250 lines of Carbon code that I hack to search the depths of my early 2000s knowledge for before I realized that there's a big problem: I can't make a Carbon nib without an ancient Interface Builder! I searched my hard disk and found a project from an old book about Carbon, and it runs (though not 100% as expected) after a little bit of polishing and stripping out PPC code, though it could use a little explanation. Should I E-Mail a link to it? – Collin L. Oct 31 '16 at 05:59
  • If there's a way for you to put the code up publicly and link to it here (for the benefit of others reading the question), that would be best; if not, we can take this offline via email (there's a link to my email on my website, found in my profile). – Itai Ferber Oct 31 '16 at 14:55
  • Alright, I put it in a Dropbox folder [here](https://www.dropbox.com/sh/s92kc0qsq7u24xy/AACkVUoT-t2PR71BNUTcahzwa?dl=0). To compile, XCode must have the 10.4 SDK restored as described [here](http://stackoverflow.com/questions/5333490/how-can-we-restore-ppc-ppc64-as-well-as-full-10-4-10-5-sdk-support-to-xcode-4). Unlike that tutorial however, I just used Pacifist to extract the SDK from an old XCode installer from the ADC Downloads Section, instead of actually installing the old XCode. – Collin L. Nov 01 '16 at 03:09
  • The portions of the code that load the nib can be bypassed by #defining the SKIP_NIB preprocessor directive in MyPCH.pch. Since the problems I had at first are still there, the application never shows up in the dock and cannot become the active application, so I'm not sure if it actually receives keyboard events or not. Oh, and it also uses the deprecated AGL OpenGL library, so get ready for a blast to the past there. – Collin L. Nov 01 '16 at 03:10
  • Attempting to build the project works for me for the most part, naively, save for some linker errors. Which framework are `NewCWindow`, `SetControlMaximum`, `AppendMenu`, `BlockMove`, and others supposed to be coming from? Are those Carbon, or otherwise? – Itai Ferber Nov 02 '16 at 03:23
  • `NewCWindow`, `SetControlMaximum`, and `AppendMenu` are all in the Carbon Framework. `BlockMove` is in CarbonCore, which Carbon should automatically include. That's strange that those errors are coming up, though: I couldn't get just linker errors by bumping up the base SDK from 10.4, failing to link with Carbon.framework, or setting it to build 64 bit. Did you open up the XCode project or start from a fresh project with the Command Line Tool preset written in C? – Collin L. Nov 02 '16 at 04:24
  • I opened up the project, set it to build for the current architecture, relinked it with the system OpenGL, AGL, and Carbon, and modified the code by replacing a constant that was no longer present with the integer value I found online by Googling it. This is on macOS 10.11.6 with the 10.12 SDK. Strange, though, that you seem to be able to run the app as a precompiled binary; that means that the symbols it uses are all present... Unless it's being lazily linked and never uses the missing symbols? In any case, what OS version are you on? Maybe that will be a clue; I don't have the 10.4 SDK. – Itai Ferber Nov 02 '16 at 06:30
  • Not only can I can still run the app, I can compile it from that XCode project on 10.10 with XCode 6.3.2. A lot of the symbols will indeed be undefined with the base SDK set to anything higher than 10.8. I believe 10.6 or 10.7 was the last version of OS X to support the old Carbon functions like `NewCWindow()`, and I have never been able to find a way around that besides using an older SDK. The 10.4 SDK can be restored on a modern version of XCode by copying (or symlinking) it from another XCode version. I have link in comment #9, but I understand if you don't want to go mucking with XCode. – Collin L. Nov 02 '16 at 07:04
  • Actually, I just looked it up and the 10.6 SDK should still have support for all of the old functions, but I don't think 10.7 will. – Collin L. Nov 02 '16 at 07:06
  • **I think I just figured out the problem!** Even though projects created using the Command Line Tool template don't have an info.plist file visible to the programmer, it looks like some properties that one would normally set there are built directly into the project. Specifically, while working with some other Carbon code to force the application to become active, it seems as if the `LSBackgroundOnly` property is set to YES, making it impossible to make any window the app makes an active one. If we could get XCode to recognize an info.plist file with it set to NO, it should work fine. – Collin L. Nov 03 '16 at 04:49
  • Sorry I haven't been able to follow up on this yet; busy with work. I will try to take a look tonight and see if I can get anywhere with that. Sounds potentially promising, though I'm pretty sure it's AppKit which reads the `Info.plist` file and acts on those keys; even if we include `LSBackgroundOnly` in a plist file and stick it in the project, I'm not sure Carbon will do anything with it. But, worth a shot! – Itai Ferber Nov 03 '16 at 14:44
  • The reason I though it might be LSBackgroundOnly is because I tried to make the application the foreground one by calling `SetFrontProcess()` on the ProcessSerialNumber for the app (obtained through `GetCurrentProcess`), but it returned an OSErr value of -606, which is "Application Is Background-only." – Collin L. Nov 04 '16 at 22:50

0 Answers0