[muchfresh]

one of the interesting aspects of OSX is the broad set of Interfaces, frameworks and interfaces that are supported. My simple overview of the various API leads me to believe that Carbon and Java will be the predominent API for OSX. Java while is a very popular framework and API it isn't a Mac specific technology. Additionally Java being a interpereted technology will never achieve the speed of a Native API. Cocoa I don't think will be heavily supported by large ISVs and therefore Apple.

I believe that Carbon will for the foreseeable future Carbon will be the most viable API to develop for. I was therfore interested in peoples opinions on how stable Carbon? Also how advanced are the API? are they fully reentrent? any other comments on Carbon whould be appreciated.

thanks

[Angus_D]

NO WAY!

Carbon is being recommended mainly for porting Classic apps to OS X, and possibly for developers experienced with Classic to keep on developing apps with under OS X.

Cocoa is suggested as the way to go for all new apps under OS X. It's a lot faster to develop under, its APIs are great, and it's powerful. It's also way easier to learn than Carbon.

Cocoa is a little bit unsupported at the moment because the documentation hasn't been written yet. Apple are probably busting a gut trying to get the thing out on time, and I'm unsurprised nobody's bothered to write a lot of the vast developer documentation yet.

Nowhere does it say that Java 2 is the suggested language to develop under. You can develop for Cocoa using Java to call the framework, but Objective C seems like the predominant language to call Cocoa from, mainly because it's faster (AFAIK).

Carbon currently isn't on par with Cocoa, since Cocoa is the native API really. Carbon was added in recently and as such isn't quite of the same standard Cocoa is.

If you only want (need) your app to run on OS X, or if you're new to development, I suggest using Cocoa (with Objective C of course).

[strobe]

Feel free to ignore zealots, like this OPENSTEP zealot.

Carbon is an excellent tool if you want to use PowerPlant which is often an easier solution if you want to utilize C++ libs (ObjC++ died). It is also more mac-like until Apple fixes Cocoa (which still has annoying NeXT-isms like lousy text handling behavior).

Carbon is being continually improved by Apple making it close to par with Cocoa feature-wise. Sheets, services, Carbon events, etc.

I've also heard good things about MacApp yet I haven't used it.

[muchfresh]

I agree zealots are not very usefull in helping people make decisions. Good advice base on experience that I don't have is much more usefull.

Still I am concerned about the quality of the API. They are based on old Macintosh technology. I know that Apple spin is that are fully modern API but really I would like to know a developers veiw of them. Do they fully support pre-emptive multithreading. I understand that an API has to built reentrent to support pre-emptive multithreading. Can Carbon take full advantage of all the cool OSX features (i.e. BSD, NetInfo, Services, etc.) While I agree that the OpenStep framework sounds like it was really advanced for its day, it doesn't sound like Apple is investing a lot of effort into improving it. All buzz that comes out of Apple is Carbon and Java. I really question their long term commitment to the API. Why should they if only a handful of developers are supporting the API?

One has to look no further than Apple is self to see. Let me paraphrase Steve J. 'we are going to eat our own dogfood and develop the Mail app with Cocoa and the Finder with Carbon'. the Finder is a huge complex application that is of paramount importance to the success of OSX, the mail app is below average Mail application that as of PB was very unstable.

thanks for any advice

[Angus_D]

I don't see how on earth you can call me an OpenStep zealot, since I've never used OpenStep before in my life. Or NeXTStep.

My first contact with Cocoa was a few weeks ago.
My first contact with OS X was DP3.

Still I am concerned about the quality of the API.

It's pretty good AFAIK, and it's ever-improving.

Can Carbon take full advantage of all the cool OSX features (i.e. BSD, NetInfo, Services, etc.)

I'm pretty sure they can, yeah.

While I agree that the OpenStep framework sounds like it was really advanced for its day, it doesn't sound like Apple is investing a lot of effort into improving it.

Apple is putting quite a lot of effort into improving it - not that it needed improving much in the first place. Admittedly they've been quite heavily involved with Carbon since that's what most developers wanted to ease transition to OS X.

All buzz that comes out of Apple is Carbon and Java. I really question their long term commitment to the API. Why should they if only a handful of developers are supporting the API?

Uhh what are you on about here? I don't really get what you mean here. Are you talking about evil swing apps, or using Java as a development language for the Cocoa API?

One has to look no further than Apple is self to see. Let me paraphrase Steve J. 'we are going to eat our own dogfood and develop the Mail app with Cocoa and the Finder with Carbon'. the Finder is a huge complex application that is of paramount importance to the success of OSX, the mail app is below average Mail application that as of PB was very unstable.

Actually, the Finder isn't as big as you make it out to be. It's simply that little file browsing application you use. It's not the entire Desktop. In fact, the Finder is quite inferior in most people's view, when compared to the OpenStep-based FileViewer or whatever it was called. Mail.app isn't below average, it's quite good. And the only reason it was unstable was because Apple mucked up multi-threading.

Apple is still touting Carbon for transition and Cocoa for new apps.

[Hobbes]

I have to agree with Angus_D completely. Like him, I've never used OpenStep or NeXTStep. Aside from pictures, never even seen them.

But in my opinion as a developer, Cocoa is a much better bet. Its much faster to develop for, its extremely powerful, much easier to learn, and while Carbon is still OS X native with protected memory, multi-tasking and so on, Carbon still can't take advantage of some of the features that X offers. One quick example is built in spell-checking. Only Cocoa apps can use it. There's a number of other features that Carbon can't take advantage of as well.

Angus_D is right. Carbon is being promoted only as a transitional step, not the final destination. Therefore, any additional features that have been added to make it more functional are not with the intent of it replacing Cocoa, simply to make it as easy as possible for developers to continue programming for OS X and eventually make the switch to Cocoa.

[muchfresh]

I dug these up on their Carbon API documentation page:

################################################## #####################
--Scheduling and Application Threading In Mac OS X, each Carbon application is scheduled preemptively against other Carbon applications. For calls to most low-level operating system services,Mac OS X also supports preemptive threading within an application. Because most
Human Interface Toolbox functions are not reentrant, however, a multithreaded application will initially be able to call these functions only from cooperatively scheduled threads. Thread-based preemptive access to all system services— including the Human Interface Toolbox—is an important future direction for the Mac OS.

--Thread Manager
You can use the Thread Manager to provide cooperatively scheduled threads, or multiple points of execution, in an application. You can think of the Thread Manager as an enhancement to the classic Mac OS Process Manager, which governs how applications work together in the Mac OS cooperative multitasking environment.

Consider using the Thread Manager for applications with more than one thread, especially if these threads can execute only in the cooperative multitasking environment of the classic Mac OS Process Manager. For example, Human Interface Toolbox functions, such as those belonging to the Window Manager and Control Manager, are not reentrant. Hence, they can't be scheduled preemptively but must instead rely on the classic Mac OS cooperative multitasking model. If your application would benefit from having two separate paths of execution, each of which calls Human Interface Toolbox functions, you can safely implement these paths in Thread Manager threads.

Alternatively, you should consider using the Multiprocessing Services to implement separate paths of execution for tasks that are reentrant and can therefore be preemptively scheduled.
Using Thread Manager routines, you can create threads and thread pools and set them up to run; turn scheduling on and off; work with stacks; create dialog boxes that yield control to other threads; pass information between threads; install custom scheduling and context-switching functions; and use threads to make asynchronous I/O calls.
################################################## ######################

I think I am begining to answer my own question. How good are the Carbon API? It looks like substanatial parts of Carbon are not reentrent and therefore must be coopertivaly schedualed. Additionaly Hobbes pointed out that carbon doesn't take full advantage of OSX features such as services that provide functionality like global spell checker.

As for Java and Swing. I think your are keeping your eyes closed in front of a speeding train. Just go to a bookstore to see the number of Java programming books on sale. Companies like IBM transfering most of their development efforts over to Java. I think Apple has wisely noted this trend and is pushing Java (with Swing not just Cocoa) Cocoa really only has one development tool, PB/IB. whereas Java has many very powerful IDEs. I really don't see any new applications being developed in Cocoa. I looked at xappeal.org who keeps a small list of OSX apss and it looks like even the new apps are being built in Carbon.

While Cocoa probably does have many advanced features I think that advancing Carbon and investing heavily into Carbon frameworks (i.e. powerplant and MacAPP) would be a better use of resources then improving an old framework that isn't used by many.

just some more thoughts

Java might be really big...on the server side. But Java is still unsuitable for client-side applications: long startup times and large memory footprint. In Cocoa, Java is currently an ugly duckling.

But I for one still wish there was a C++-based framework to work with.

[Angus_D]

There is - MacApp. It's Carbon and is written in C++.

Also there's been some rumours of Apple re-introducing ObjC++, but I'm not sure how much grounding they have in reality.

[muchfresh]

MacApp is being ported to Carbon, although it is still in beta. I don't think PB/IB can use MacApp. Metrowerks powerplant is also carbon with version 6 of Codewarrior.



------------------

[Angus_D]

The latest MacApp framework development versions support building under OS X from Project Builder - although it's true, they can't use IB.

[strobe]

The cited documentation is misleading.

You only have coperatively tasked thread scheduling when you use the event manager. Do not use the event manager, problem solved. If you want events pre-emptively use Carbon events.

Apple may or may not turn the TextEdit functions info a wrapper for Cocoa classes. I think they will in some fashion because they are definitely working on Carbon fonts. If it can be done with TextEdit I'm sure WASTE will follow. Time will tell however if/how services will be made available to Carbon (I'm not on ADC).

PowerPlant is already carbonized with a Carbon events version forthcoming. Thus all PowerPlant projects will be able to be recompiled as pre-emptive-threading enabled applications with respect to menus, window dragging, etc.

You can also mix and match in a veriety of ways. Music Player has a WDEF which takes a PDF and pushes the data to Quartz to make the window. Thus the CFM app uses the dyld WDEF.

[davecom]

Why should we argue about choice - choice is good - as long as your choice is not Classic. Apple was originally not going to ship their next generation OS with carbon, but only with an emulator for legacy(blue box) and cocoa. But in the end carbon was added because developers didn't want to learn cocoa.

I personally like cocoa and am waiting for some books to be published on it to take the big plunge. One thing I'm very pleased with is the integration of the Java 2 platform with both cocoa and the OS as a whole.

I think an interesting combination is using POSIX with cocoa, though POSIX is a little cryptic at times. Cocoa seems as though it is so easy to use for some things, yet so complex for others(like TCP sockets).

Just my five cents(if you factor inflation).

------------------
Think Different.

[davecom]

Why should we argue about choice - choice is good - as long as your choice is not Classic. Apple was originally not going to ship their next generation OS with carbon, but only with an emulator for legacy(blue box) and cocoa. But in the end carbon was added because developers didn't want to learn cocoa.

I personally like cocoa and am waiting for some books to be published on it to take the big plunge. One thing I'm very pleased with is the integration of the Java 2 platform with both cocoa and the OS as a whole.

I think an interesting combination is using POSIX with cocoa, though POSIX is a little cryptic at times. Cocoa seems as though it is so easy to use for some things, yet so complex for others(like TCP sockets).

Just my five cents(if you factor inflation).

------------------
Think Different.

[exrae]

Cocoa is ideal for new apps. The APIs are great, you get a lot of free code. It's fast, easy and FUN!

What more can be said...

------------------

exrae "The pool on the roof must have a leak"

[Mooseyard]

If you're developing a new app (or porting one from a different platform like Win or Unix), and you don't need compatibility with earlier Mac OS versions, then definitely go with Cocoa.
I'm no OpenStep zealot and I used to roll my eyes at their wild claims. But I started using Cocoa last September and immediately felt like I'd put on some huge set of powered armor (as in those Japanese "mech" anime) that let me lift huge I-beams and concrete blocks and build huge edifices out of them in no time. Seriously!
InterfaceBuilder is an awesome RAD tool, its integration with the AppKit frameworks is brilliantly thought out (much better than any Java or PowerPlant tool), and the frameworks themselves are incredibly powerful and mature.
The end result was that I had a prototype of a large portion of my app up and running in about two weeks after first cracking open the Cocoa docs (and the first week I spent just playing with the standard tutorials.)
If you have old Mac code to port, or if you need OS 9 compatibility, go with Carbon. Otherwise, spend a few days kicking the tires on Cocoa before making your choice, or you're doing yourself a disservice.

[gorgonzola]

While I'm no big coder, I do know that Carbon in the PB is unfinished so you may want to wait until Final release to properly judge Carbon.

Both the APIs have some rough edges, AFAIK.

good luck

------------------
it's only after you lose everything that you're free to do anything