[muchfresh]

After reviewing Apple's system overview for OSX I believe that OSX's native API is really Carbon. The major API groups(not including Java and POSIX) are all written in C.

CarbonEvents
CoreFoundation
CoreServices
FileManager
MultiProcessing Services
OpenTransport
Quartz(CoreGraphicsServices and CoreGraphicsRendering)
etc....

According to the docs these API are available to the application environments (carbon and Cocoa). Now does this mean that Cocoa has been ported to these Carbon API?

Originally posted by muchfresh:
After reviewing Apple's system overview for OSX I believe that OSX's native API is really Carbon. The major API groups(not including Java and POSIX) are all written in C.

This is just so completely wrong I don't know where to start. Maybe you can ask the mods to delete the thread to avoid the abject shame later on.

Carbon is *a* native API for OS X, but Cocoa is *the* native API for OS X, if you catch the distinction. If you want full access to all the goodies, you have to use Cocoa. Once Apple gets its **** in gear and gets Obj-C++ out the door I think most people's objections to using Cocoa will go away and everyone can be happy.

[muchfresh]

jeez jethro you might want to provide some information. Simple statements like 'cocoa is *the* native api' don't cut it.

Directly supporting the Carbon, Cocoa, and Java environments are the layers of system software that offer services for all application environments. These layers are stacked in decreasing widths to suggest that application code can access lower layers directly—that is, without the mediation of intervening layers.
...
The first of these layers is the Application Services layer. It contains the graphics and windowing environment of Mac OS X, principally implemented by Quartz and QuickDraw. This environment is responsible for screen rendering, printing, event handling, and low-level window and cursor management. It also holds libraries, frameworks, and background servers useful in the implementation of graphical user interfaces.
...
The Application Services layer sits on top of Core Services. In the Core Services layer are the common services that are not directly a part of a graphical user interface. Here you find cross-environment implementations of basic programmatic abstractions such as strings, run loops, and collections. There are also APIs in CoreServices for managing processes, threads, resources, and virtual memory, and forinteracting with the file system.
...
An application environment consists of the frameworks, libraries, and services (along with associated APIs) necessary for the runtime execution of programs developed with those APIs. The application environments have dependencies on all underlying layers of system software.
...
The other system services in the Application Services layer support all application environments by supplying objects and behavior that affect the graphical user interface

It really looks like to me that Carbon and Cocoa are both dependent on these low level C API that infact look suspiciously like Carbon API.

have a look before you spew
http://developer.apple.com/techpubs/...emOverview.pdf

[Developer]

Well, if Carbon apps are written in C or C++ and Cocoa apps are written in Objective C, and you can call C functions without any problems from within C++ as well as Objective C, in what language would you write the lower level APIs?


Developer

[parallax]

This goes in OS X - Developer (but I can't do anything about it :-). You can attract developer flames there!

[Millennium]

It really looks like to me that Carbon and Cocoa are both dependent on these low level C API that infact look suspiciously like Carbon API.

Dude; learn what you're talking about before you speak.

Yes, much of the core stuff is in C. This is so that both Carbon and Cocoa can use them equally. Truth be told, they're both built on top of C, in that C++ and Objective-C are both extensions to that language. This makes it very convenient to write the core functions in C; that way you don't have to do as many alternate language bindings.

It's not that CoreFoundation looks like Carbon; it's that Objective-C looks so unlike anything else. If Cocoa were C++, it would actually be very hard to tell the difference between the two.

The fact is, both API's are "native" as such. If I had to pick one that I'd say is the "native API" (which is such a misnomer it's not even funny), I'd say it was Cocoa because of its better integration with the system.

[gorgonzola]

Yup, this goes in OS X Developer. I've been busy in the Lounge, sorry for not moving it sooner.

Click through to find your thread.

thanks

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

[muchfresh]

I put this in the general section because it is clear flame bait. I didn't want to dilute the otherwise inteligent discussions going on the developer section.

anyway.

according to james davidson of the o'reily network who is at WWDC, Cocoa is actually built upon Carbon. na na na de boo boo. I right your wrong.
http://www.oreillynet.com/pub/a/mac/...vs_carbon.html

[ali]

At WWDC, during the first day sessions, Scott Forstall discussed the major application programming environments available on Mac OS X (Classic, Java, BSD, Cocoa, and Carbon) and pointed out that the last two are the native environments of Mac OS X, as they are the ones Apple will be developing and nurturing most closely, and the ones where new features will first appear. BSD is also native, of course, but to write a full-fledged graphical app, you would use Cocoa or Carbon on top.

Carbon and Cocoa have some interdependencies, but it is not the case one is built on the other; especially like MFC is built on Win32, or MacApp or Powerplant are built on the Mac Toolbox. Most of the code and services common to Cocoa and Carbon have been moved down to lower levels, and these layers include stuff that is traditionally Carbon (such as ATS, QuickTime), stuff that is traditionally Cocoa (such as CoreFoundation), and stuff that is brand new (such as Quartz, LaunchServices, OpenGL).

There are a few instances where Cocoa uses higher levels of Carbon; one is the menu bar, which is implemented in Carbon and used by Cocoa and Carbon, and the other is the print dialog, which is also implemented as a Carbon window. But, this is an implementation detail. BTW, the example the O'Reilly article above gives --- that the save dialog in Cocoa is actually Carbon --- is not correct. But again, an implementation detail.

A lot of new features are added to the system at the lower levels, and are available fully to both Cocoa and Carbon to use and publish using their respective APIs and paradigms if appropriate.

This approach allows high degree of code and data sharing, and interoperability. Where the two frameworks end up differing most is how they package and present these lower level APIs to the apps --- procedurally, or in an object-oriented fashion. In addition, some features are implemented just in each framework rather than the lower levels, and this also means the two frameworks do have some differences in features, at least temporarily.

Ali




[This message has been edited by ali (edited 05-23-2001).]

[honeydew]

I put this in the general section because it is clear flame bait.

heh

according to james davidson of the o'reily network...

Let me quote the conclusion of that same article:

it becomes more apparent that Carbon is the procedural native framework, and that Cocoa is the object-oriented native framework of OS X building on Carbon.

Developers are free to choose at which level they want to program. Developers choosing to work within Cocoa have all of Carbon's goodies just waiting to be tapped.

In the author's view, both are "native" APIs. The distinction is that a Cocoa developer has access to Carbon, but the reverse is not true. As jethro said earlier, "Carbon is *a* native API for OS X, but Cocoa is *the* native API for OS X." Cocoa gives you everything Carbon does, plus a whole bunch of time-saving goodies.

[This message has been edited by honeydew (edited 05-23-2001).]

[Angus_D]

Lots of the core API is written in C because C has much less bloat than ObjC and C++, and the lower levels of OS X have always been C, since that was the original language that BSD was written in (and probably mach too).

The thing is, all the lower-level APIs are lower-level than or same-level as Carbon or Cocoa, and therefore can't be built on top of them.

I hope that made sense.

[AirSluf]

The language an API is written in has no bearing on the "nativeness" or "non-nativeness" of applications programming languages.

In a perfect world everything would be written in machine code, since we don't think that way we worked up the evolutionary ladder through Assembler to the higher level languages of today. "Nativeness" for an applications programming language is defined by what the API supports, not what language the API was created in.

"Nativeness" on a different level is defined by a language's compiler availability for a specific CPU. Same word, completely different context and meaning. Again, no relation to what an API was constructed with and what it supports.