I am wondering if anyone could tell me whether carbon applications created on Mac OS 8/9 using CodeWarrior Pro and the CarbonLib SDK will work on Mac OS X DP3 or DP4. Does the memory allocation feature on those applications on OS 8/9 has any affect on OS X? Also, do carbon applications on OS X have both a data fork and a resource fork.

On a related subject, since the CarbonLib SDK is not a final product, I would think that the carbon implementation in AppleWorks 6 and Internet Explore 5 is still in development. Anyone know more about that?

[nibs]

yes. carbon apps developed in 8*/9* will work in dp3/4.
the carbon api isn't finished because apple may still add more functionality. i think it's supposed to be 98% finished. any carbon apps which work in dp4 should continue to work from here out.
it's funny cuz i just had this exact conversation with stevie j. yesterday evening

[blizzard]

nibs, who are you? you're the most active guy in this forum by far, and it seems as though you have an answer to everything Mac OS X. given these, i'm clueless as to what to make of your 'Stevie J' comment. it's pretty obvious you're a big developer, but do you actually work at apple? just curious...

Anyone know what the Mac OS X version of Realbasic was made with that it cannot be run on Mac OS 9? Because I think that if it was made using the CarbonLib SDK package with either CodeWarrior or MPW, then it should run on OS 8/9.

[Orbit]

Realbasic made on Codewarrior.. Hee hee.. I know it probably was but for some reason that just strikes me as a funny thought. If it is a carbon app, it should be able to run fine on both OS X and OS 8/9 with the carbonlib extension.

As a side note- I see a lot of people looking at Cocoa and Objective-C with a sort of "what's up with that" attitude. That will change, trust me on this one. You'll see developers flocking to Cocoa en masse, it's that good. John Carmack thinks so!!

[markhers]

The reason you can't run the OS X is that it's likely a Carbon/Mach-O, and not a Carbon/PEF which means that you can't run it on Mac OS 9.

And to be clear all, I'd have been spending this past week reading all of your posts and questions, but I've been busy attending WWDC, so I haven't been able to. I'm back, and somewhat limited in time, but I can shed a lot of light on some of the injustices which have been posted on this forum over the past week.

[Orbit]

Oh yeah- good point! Completely forgot about that. Injustices? Do tell!!

RealBASIC is written with CodeWarrior. The Carbon version *should* work in both Mac OS 9 and X, but as it is an alpha/beta there may be temporary reasons why it isn't behaving quite right just yet.
Anyone else have trouble using the X version in 9?

Yes, there are good reasons why Realbasic is probably made with CodeWarrior. But, anyone know why if you open up the Realbasic application with ResEdit, the last information in the "cfrg" resource and the items in the "PICT" resource are the same as in a typical application created with Realbasic?

But, back to my original questions, does the memory allocation in the "SIZE" resource of carbon applications have any affect on them when running on Mac OS X? Is it right that carbon applications on Mac OS X still have a data fork and a resource fork? Another related question, are applications and files on Mac OS X required to have an extension after them, like ".app" for applications for examle?

[Orbit]

No, the 'SIZE' resource has no effect- and if it does, it doesn't really matter because your system has practically unlimited virtual memory. Programs can still have a data and resource fork, in fact for carbon apps which run in classic as well, this is a necessity. This won't work on UFS partitions, so Apple made "bundles" which have both the carbon app, and the resources in one "folder" which both filesystems can use. A few years down the line, resource forks will be a thing of the past, replaced by supporting files and .nib files included in the application bundle and linked via XML property lists. And no, programs don't need .app after them and this should be removed by the final release.

I have put a Carbon program "BasicApp" up in the Mac OS section on my web site at http://members.xoom.com/comosaw/ for anyone looking for a Carbon program to try on Mac OS 8/9. There are other programming stuff there for Mac and Windows as well.

[This message has been edited by Idler (edited 05-25-2000).]

There are 2 forms of Carbon Apps

Carbon/Mach-o & Carbon/PEF

Mach-o will only run on MacOS X
PEF will run on MacOS 8/9/X

Appleworks IS a carbon App, and is based on CarbonLib 1.0.4 which is a final version of CarbonLib

I presume that IE 5.1 (which only ships on DP4) is based on the prerelease version of CarbonLib 1.1.

As stated before, Carbon apps can have resource forks. Any file still can, and do on HFS+ volumes. If a file with a resource fork is copied to a volume that doesn't support resource forks, the system creates additional hidden files that store that information.

The SIZE resource in a Carbon app is ignored under MacOS X. However, for a carbon app to execute properly on MacOS X (that is, not under the classic environment) a developer has to include a 'carb' resource.

That should about do it for Carbon.

I was surprised to read that Apple now say that CarbonLib 1.1 will only be compatible with Mac OS 8.6 and later. Previously CarbonLib 1.0.2 was compatible with Mac OS 8.1 and later. Anyone know why are there all these different versions of the CarbonLib and are there any differences between them?

[Scott_H]

I would hope that 8.6 or 9.0 are free after OS X is out and selling in stores. If people need it and Apple's not selling it then it should be there in some form.

[mikerally]

Considering Mac OS 8.1 supports 68040 Macintoshes, I'm not surprised Apple have dropped support for Carbon on this System.

REALbasic alphas now do indeed run on 8/9 but the Carbon versions require CarbonLib 1.1.

You can create classic, Mac OS X, and Windows applications from the same project using REALbasic.