Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Mac OS X Tech Talk Tour: UNIX on the Desktop

By codemonkey_uk in Technology
Tue Apr 01, 2003 at 02:23:34 PM EST
Tags: Software (all tags)
Software

On a bright clear day on the outskirts of London, I sat in a lush hotel seemingly staffed exclusively by beautiful people with exotic accents, waiting for my sandwich. I am surrounded by businessmen in expensive looking suits, and hippies with expensive looking Apple notebooks.

As I read about the war going on halfway around the world in the 'free' newspaper laid on by the hotel I can hear two men with beards wage their own private battle with their network configuration and the connection to the hotel's wireless network gateway.


There is an O'Reilly stand selling Unix and Apple books outside the conference room. Later I will learn that they are discounted by 25%, but by then it will be too late. There is a "free" CD on each chair, containing the latest version of the Apple Developer Tools.

There are maybe 100 people, just over half the seats are occupied. I overhear someone observe that there is only one woman. An unusually low male to female ratio for an Apple event, apparently.

The presentation will be delivered using Apple hardware, but initially there is a problem with feedback from the radio mic.

System Architecture and UNIX

The first presentation is an overview of the OS X System Architecture. They talk about how Quartz uses PostScript, and how well Quartz Extreme integrates with hardware acceleration.

The go on to talk about the wide selection of languages available to the developer, and how the POSIX compatibility is "mostly done", and that Apple are now committed to Open Standards. For graphics / UI development there is OpenGL, GLUT, X11, and of course Carbon and Cocoa. They noted that AliasWavefront used X11 as a way to rapidly port Maya to OS X, and went on to get 20% new sales on the platform.

There was mention of Fink, which pretty much got an official recognition, despite Apple admitting that they were looking into doing their own BSD style "Ports" system.

Developers moving from UNIX need to be aware that HFS (native file system) is case insensitive (but case preserving), and that resource forks are still supported, but should be thought of as deprecated.

Developers can of course use ".dot" files for configuration, but that OS X comes with its own XML based system for this.

There was talk about Frameworks, and all the places that they can live. For example Safari has two unfinished frameworks, "webcore" and "webscript", which are currently bundled into the application. When the APIs are stable Apple will move these frameworks into /System/Library/Frameworks/ where they can be used by everybody.

Java

Java 1.4.1 is now available for Mac OS X. Apple's Java engine is now based on Cocoa, which is closer to the Java model than Carbon, which was the framework 1.3.1 was written with, and so the Java VM is tighter and less bloated (300 implementation classes as opposed to 900 previously). 1.4.1 also has better Safari and Keychain integration. The new JVM also has the new shared system library technology, which reduces the overhead in running multiple Java apps on one system. Apple are clearly very happy with the new JVM, with claims that it is "the best JVM implementation in the world".

Cocoa

Cocoa, the Objective-C API for OS X is a "proved" RAD environment. The Apple developers use it, and Project Builder to do their internal development, and the quality and quantity of the output of the software division of Apple has measurably increased.

On a personal note I was very sceptical about Objective-C, but have to say I was impressed by what Apple had to say about this. A lot of people claim this or that about whatever development language, environment, or methodology, but very few have actually done any genuine productivity studies to back up their claims.

Anyway, they talked a lot about how Objective-C worked, but it's not something I want to try to go into details here - I wrote a lot of notes, but I don't think it would make very good reading. If you're interested there are lots of good books. The demo was very very impressive, in that they wrote a simple application from scratch in front of us, then delved into the application bundle, and changed one of the GUI widgets from a text entry box to a slider-bar and the app worked with the new UI without recompilation.

AppleScript

The final presentation was on AppleScript. Apple considers AppleScript to be a first class citizen of the developer tool world, and something that you can use to write real applications. It's not just Yet Another Scripting Language. It is a Mature Language that they have done a lot of research into and done a lot of work on and in.

You can embed shell scripts in apple script, and you can script Java apps with it. Basically any GUI app on the Apple platform "supports" AppleScript, because AppleScript support is built into the OS.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
More Conference Reports?
o Yes 83%
o No 16%

Votes: 48
Results | Other Polls

Related Links
o Apple Developer Tools
o OS X System Architecture
o X11
o AliasWavef ront
o Fink
o Safari
o Java 1.4.1
o Cocoa
o Objective- C
o RAD
o Project Builder
o AppleScrip t
o Also by codemonkey_uk


Display: Sort:
Mac OS X Tech Talk Tour: UNIX on the Desktop | 65 comments (44 topical, 21 editorial, 0 hidden)
I was there (5.00 / 3) (#9)
by creo on Tue Apr 01, 2003 at 10:05:18 AM EST

Flew into London on Sunday and just happened to notice this was on.

As a big iron guy I actually found it very interesting - I especially liked the look of objective C and the Apple dev tools. It kind of reminded me of smalltalk that I did waaaaay back in uni.

I have learnt C++ from purely a DIY perspective to get a feel for the language, but have not used it in anger in my day job, and have never really had the desire to. I have even had less desire to use Java - it.reminds.me.of.wordy.stuff.like.cobol. However, Iwas that interested by the objective C and cocoa demo that I took advantage of the 25% off and bought a couple of books and will have a bit of a bash at it on the wifes iBook.

The dog and pony show is for half a day, and definately worth going to - even if you don't do Apple. My preferred option is a unix with KDE. I was intending to buy a lapzilla, and put on gentoo, but I might give osx a reprieve, or at least MOL it.

Cheers
Creo

Cocoa is also veryWordyWithLongMethodNames[n/t] (5.00 / 2) (#24)
by mahoney on Tue Apr 01, 2003 at 11:30:32 AM EST



[ Parent ]
on the plus side (5.00 / 2) (#30)
by Delirium on Tue Apr 01, 2003 at 12:25:13 PM EST

You won't need a manual to figure out what the library function vwwlmn() does, as with C.

[ Parent ]
hmm (5.00 / 1) (#48)
by e8johan on Wed Apr 02, 2003 at 01:22:44 AM EST

int vwwlmn( void ); Returns the count of very wide web local monitoring nodes. Didn't you know that! :)

[ Parent ]
Historical reasoning (4.00 / 1) (#43)
by Alannon on Tue Apr 01, 2003 at 04:47:51 PM EST

The historical reasoning for the Cocoa framework using veryWordyLongMethodNames is because objective-C uses named method arguments.  For example:
NSBundle pathForResource:ofType:inDirectory:forLocalization:
This would be called as follows:
[aBundle pathForResource: somepath ofType: someType inDirectory: aDirectory forLocalization: aLocale]

Theoretically, this makes it easier to remember the placement and order of method parameters.  When Cocoa added Java support, since Java doesn't support this style of methods, that method would instead be called as follows:

aBundle.pathForResourceOfTypeInDirectoryForLocalization(path, type, directory, locale)

That's only a sample.  That actual method doesn't exist in the java version, but it shows that things can get very wordy, for the sake of consistancy.

[ Parent ]

An odd reason not to use Java (none / 0) (#45)
by coljac on Tue Apr 01, 2003 at 07:15:17 PM EST

The fact that the code tends to be too readable. :)

Having experience with the main languages (C, C++, Java, Perl) I like java the best, though it's not at all the best choice for every app.



---
Whether or not life is discovered there I think Jupiter should be declared an enemy planet. - Jack Handey
[ Parent ]

I know... (5.00 / 1) (#50)
by creo on Wed Apr 02, 2003 at 06:25:51 AM EST

but I only do this for fun. If people pay me, well, lets just say some (fortunately very small part)of my day job does involve cobol.

I guess I was just trying to say that like C++, Java just does not click. I love C and a Tandem language called TAL - both terse and requiring good understanding of machine level structures to do well. I have had a go at Java, and I just found it unappealing. I find C++ more doable, but it has so many inconsistencies. Both of these views are from a non industrial perspective. I'm sure with the right tools and motivation (cash in pocket) that I could learn to love them. I must say that at first glance objective C just seems so much more, well, objective. It combines the simplicity of C with what seems to be a sensible structure for object messaging. Don't get me wrong - I still know jack shit about the language, and may find once I delve into it, that it is really crap. Who knows? That's what's fun about dicking with computers.

Maybe I should keep notes of my feelings and experiences on doing beginning obj-c and cocoa development and do an article on it. If I end up going to Riyadh, I might do that, as there will be no partying at the local pub :-(. That'll be just after I finally get around to doing my Bank Security and PIN article - maybe one day.

Cheers
Creo

[ Parent ]

Riyadh? (none / 0) (#57)
by coljac on Wed Apr 02, 2003 at 02:22:35 PM EST

Do tell, sounds interesting! (I checked but you don't seem to have any diary entries).

coljac



---
Whether or not life is discovered there I think Jupiter should be declared an enemy planet. - Jack Handey
[ Parent ]

Maya and X11 (5.00 / 1) (#17)
by calimehtar on Tue Apr 01, 2003 at 11:05:38 AM EST

"They noted that AliasWavefront used X11 as a way to rapidly port Maya to OS X." I find this hard to believe, considering it was released in 2001 while X11 is still in beta in 2003.

On the same page, an Alias | Wavefront representative says "Maya is the largest, most technically sophisticated program to be built for Mac OS X. But we couldn't have done it without Mac OS X's support of OpenGL, the high-level Carbon API, and Aqua's transparent overlay windows." None of these, excluding OpenGL could be made available through any implementation of XFree86.

I've never tried or even seen Maya, much less looked over the code, but I'm pretty damned sure it doesn't use X11.



hard to believe (none / 0) (#20)
by codemonkey_uk on Tue Apr 01, 2003 at 11:15:36 AM EST

I'm just telling you what the told me...
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
maybe (4.50 / 2) (#27)
by calimehtar on Tue Apr 01, 2003 at 11:58:41 AM EST

what he meant was something like: Mac OS X's Unix underpinnings made it very easy to port Maya. They used a port of XFree86 to run preliminary builds.

[ Parent ]
+1raq-less (1.00 / 2) (#23)
by A Proud American on Tue Apr 01, 2003 at 11:23:28 AM EST



____________________________
The weak are killed and eaten...


+1 Section even though (2.00 / 2) (#25)
by exile1974 on Tue Apr 01, 2003 at 11:36:04 AM EST

I hate Macs slightly less then M$

exile1974

"A sucking chest wound is Nature's way of telling you to stay out of a firefight." --Mary Gentle

Quartz (4.50 / 4) (#26)
by b1t r0t on Tue Apr 01, 2003 at 11:57:55 AM EST

They talk about how Quartz uses PostScript

Except that it actually uses PDF. Close enough to the Display Postscript model to give legacy support for NeXT stuff, open enough not to have to pay a tithe to the "PCs are faster" Adobe corporation.

-- Indymedia: the fanfiction.net of journalism.

"A lot of good books" (none / 0) (#28)
by pb on Tue Apr 01, 2003 at 12:10:07 PM EST

References?

Thanks for the report; sounds like a fun way to spend an afternoon. :)
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall

my Cocoa book recommendations (5.00 / 2) (#42)
by enh on Tue Apr 01, 2003 at 03:58:35 PM EST

The first book I read was O'Reilly's "Building Cocoa Applications: A Step-by-step Guide" by Simson Garfinkel and Michael K. Mahoney. The pictures are pretty, and it's a useful guide to using Project Builder and -- to an even greater extent -- Interface Builder. Unfortunately, this book is a very poor introduction to Cocoa and Objective-C. It tries to be suitable for legacy C coders, but is plainly written by two such, rather than experienced OO programmers. The example programs are also not nearly as exciting as they may sound if you read the blurb rather than have a chance to flick through the book in a bookshop.

Aside on Interface Builder: I personally find Interface Builder doesn't think the way I do, and my guesses as to how it works are often completely backwards. Step-by-step instructions come in handy, and this book has them (with pictures). I do wonder, actually, if I'd have more luck with Interface Builder if I had the same depth of understanding of Cocoa components as I do of Java's AWT and Swing components. Paradoxically, Interface Builder itself seems to be the main obstacle to gaining this knowledge because it keeps me from having to programmatically nest components in containers and programmatically set components' properties.

Back to books, a far better book from the programming perspective is Sams' "Cocoa Programming" by Scott Anguish, Erik M. Buck, and Donald A. Yacktman. This has a better introduction to Objective-C (along the lines of the first edition of "Java in a Nutshell"), broad coverage of Cocoa, and code that looks like it was written by good programmers.

I tend to have both books on my desk when I'm doing Cocoa programming, along with a Safari window so I can ask google for the on-line documentation. There's also a lot of other information on the web. A good place to start is ranchero.com/cocoa.

[ Parent ]

big nerd ranch (none / 0) (#59)
by white light on Wed Apr 02, 2003 at 06:19:54 PM EST

Have you read Aaron Hillegass's "Cocoa Programming for Mac OS X" ?

I found it quite informative and involving. Great for learning Cocoa.

[ Parent ]
Building Cocoa Applications (5.00 / 1) (#61)
by steveftoth on Wed Apr 02, 2003 at 06:54:03 PM EST

that book is awesome.  But as the book says on the cover it is ment for experienced programmers.

Do not pick it up if you are learning to program.  I would say learn java first and get used to using developement tools.  Then learn C, then this book.  
Objective-C is C, and then adds some more.  

Building Cocoa Applications shows you how the deveopment enviroment works and how to connect up apps, get working and build basic applications.  You have to do a lot of the heavy lifting yourself, but IMO that's good because it teaches you how to do things.  They spell out everything so you never are lost as what to do.  Their examples are also open so that you can easily experiment with their code and add more stuff if you want.

It walks you through building from scratch a couple of basic applications, calculator, math editor.  You will have to learn how to use the documentation but you need to as the Apple documentation is good and should be learned anyway.

[ Parent ]

OS X driver architecture is quite nice (5.00 / 4) (#29)
by MichaelCrawford on Tue Apr 01, 2003 at 12:18:49 PM EST

I've been working with the Mac OS X driver architecture for a little while now. It is quite nice.

While the OS X kernel is based on FreeBSD running on top of Mach, it has a driver architecture all its own, called the IOKit.

It provides a nice way of exporting kernel interfaces to user space, so often you can write a "user space driver" to control hardware without any actual kernel programming. There is much less need for custom in-kernel drivers than on other platforms.

Sure you can do that on Unix with ioctl calls but it is painful and primitive. It's almost pleasant on OS X.

Some may find offense in the user space access to hardware being based on Microsoft COM. That made me immediately suspect it at first but I have found it quite pleasant both to use and eventually to implement by providing user space access to my own kernel drivers.

The IOKit is written in Embedded C++. Unfortunately that means many of the most useful features of C++, like exceptions, constructors and templates are unavailable. But there's still a lot you can do with it, notably using other drivers as base classes so you can extend them with your own driver.

I write more about this in my advogato diary.

I'm planning on writing more at length about writing OS X drivers. I probably won't do it for a while yet. If you want to be sure to read it, check my diary here from time to time, I'll mention in there when I post the article.

Apple has very good documentation on writing IOKit drivers (kernel extensions) but unfortunately I found some large gaps. I hope to fill in some of those gaps with what I hope to write.


--

Live your fucking life. Sue someone on the Internet. Write a fucking music player. Like the great man Michael David Crawford has shown us all: Hard work, a strong will to stalk, and a few fries short of a happy meal goes a long way. -- bride of spidy


OS X (1.33 / 6) (#31)
by salsaman on Tue Apr 01, 2003 at 12:30:10 PM EST

...may be useful for those who are too scared to use a real OS

Sick of X zealots (2.66 / 6) (#33)
by phlyingpenguin on Tue Apr 01, 2003 at 12:42:19 PM EST

Sooooooooo tired of the candy apple clean perfect people who all want to exclaim their recent se^H^Hcomputer switches. I switched back after four months when I figured out that I had seen everything there is to OS X and it sucks. For being Unix, it sure doesn't do a very good job in my opinion.

[ Parent ]
You're just pissed... (4.33 / 6) (#38)
by SPYvSPY on Tue Apr 01, 2003 at 03:13:19 PM EST

...because allows your grandma to run a Unix OS as effectively as you can, and she didn't have to memorize obscure commands.
------------------------------------------------

By replying to this or any other comment in this thread, you assign an equal share of all worldwide copyright in such reply to each of the other readers of this site.
[ Parent ]

Mandrake (4.00 / 1) (#46)
by pandeviant on Tue Apr 01, 2003 at 09:19:10 PM EST

Isn't that a distribution for people who don't know how to really use Linux ?

[ Parent ]
it's the one for people (none / 0) (#51)
by werner on Wed Apr 02, 2003 at 09:10:16 AM EST

who can't be bothered to install their own fonts and sort out dependencies. It's probably the slickest linux out there. I would only recommend SuSE to Germans, cos there's more, better German docs. English ones are not so good.

[ Parent ]
Mandrake? (4.00 / 1) (#52)
by Cro Magnon on Wed Apr 02, 2003 at 09:47:54 AM EST

But it's FRENCH!!
Information wants to be beer.
[ Parent ]
UNIX on the desktop... (none / 0) (#32)
by pmk on Tue Apr 01, 2003 at 12:40:56 PM EST

... took place long before the arrival of OS X. SunOS showed up on my desk back in '86. For PCs, there's been (at least) SCO UNIX and Linux, all available for over a decade, and BSDi and other BSDs.

OS X isn't even the first appearance of UNIX on the Mac, since PPC Linux has been around for years.

Silly title. -1, dump it.

Don't forget Microport (none / 0) (#36)
by MichaelCrawford on Tue Apr 01, 2003 at 02:02:27 PM EST

It originally ran on 286 PCs, and when the 386 version came out in, I think 1986, it cost only $99.

At the time the company mounted a major advertising campaign centered around the idea of Unix on the desktop.

I worked there doing tech support (graveyard shift!). It was one of my first jobs.


--

Live your fucking life. Sue someone on the Internet. Write a fucking music player. Like the great man Michael David Crawford has shown us all: Hard work, a strong will to stalk, and a few fries short of a happy meal goes a long way. -- bride of spidy


[ Parent ]

Hey! (none / 0) (#40)
by greenrd on Tue Apr 01, 2003 at 03:32:40 PM EST

Get with the program! Didn't you hear the news: UNIX (still) isn't ready for the Desktop

Quite clearly, UNIX, with its archaic text-mode user interface, absence of "productivity applications" and its complete lack of user-friendliness, is not ready for "The Desktop". You'd have to be a real GNU/Hippy to think otherwise.


"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Yeah, But OSX is the Sexiest 'nix on the Desktop (none / 0) (#56)
by thelizman on Wed Apr 02, 2003 at 12:33:43 PM EST

[n/t]
--

"Our language is sufficiently clumsy enough to allow us to believe foolish things." - George Orwell
[ Parent ]
OSX: The Designer version of Windows (none / 0) (#37)
by SleepDirt on Tue Apr 01, 2003 at 03:04:38 PM EST

I've used OSX and I haven't been terribly impressed. I really didn't see anything in OSX to justify spending $1500 on a Mac to run it. The only positive thing I can say is that Apple has put together a nice development platform. Maybe someday if they port OSX to x86 it will actually be useful.

OSX is kind of like the designer version of Windows. It's expensive and it looks good but other than that.. it doesn't really do anything Windows XP or Linux can't do on x86 hardware, at half the price.


"In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity." - Hunter S. Thompson

OSX on x86 (none / 0) (#55)
by thelizman on Wed Apr 02, 2003 at 12:33:03 PM EST

There is much talk about Apple porting MacOS to the Intel platform. Lets face it, now that BSD is the foundation, it's only a matter of time. Quite a bit of development for OS X was done on Intel based Linux boxes, and Apple has been in the Unix game for over a decade with MkLinux and the Mach MicroKernal.

The skinny down-low on the street is that Apple has already ported OS X to x86, and has code-named the 'Jaguar for Intel OS' "Marklar" (the Marklar a race of aliens from South Park - given Apple's tendency for humor, to me that just makes this that much more believable).
--

"Our language is sufficiently clumsy enough to allow us to believe foolish things." - George Orwell
[ Parent ]
on x86 (none / 0) (#60)
by steveftoth on Wed Apr 02, 2003 at 06:48:16 PM EST

They already have the kernel ported to OSX, all they have to do is port the windowing system, sound system, old mac compatibility layer, rewrite all the drivers, graphics system, etc. etc.  

Then they have to deal with all the people who have weird hardware.  Thus writing all these drivers for strange hardware that only 1% of people own.  

Then, they have to port the finder, iMovie, iTunes, iWhatever.  Port Final Cut, and every other Apple owned mac app.

Then convience all the mac developers to port their software to the new arch.  Probabaly based on Cocoa, which has been a pain for them to move to in the first place.  Not going to happen.

They could do it, but you wouldn't actually be able to run it on many different PC configs, and the software would be really bad, like BEOS bad.  (BE was a great OS, but software was really lacking).  

[ Parent ]

no, no... (none / 0) (#62)
by illuzion on Thu Apr 03, 2003 at 05:02:15 AM EST

They would have to port the OS, true. They already have Darwin, so they just need to port other bits. In general though, theoretically, most applications could just be recompiled and they would work. Why would your average program like iPhoto, or the Finder even, need any more than recompilation unless it makes hardware-dependent calls (which I very much doubt they would)?

[ Parent ]
G4 optimization? (5.00 / 1) (#63)
by steveftoth on Thu Apr 03, 2003 at 06:04:00 PM EST

Most of the iApps are optimized for the G4, or at least have a little bit of G4 code in them now.  

Apple has been pushing very hard for people to use the Altivec opcodes which don't translate to x86.

But really it comes down to, programs have to be written with portability in mind from the start or it can be a pain in the ass to port them.

[ Parent ]

x86? Never (5.00 / 1) (#65)
by scottfeldstein on Fri Apr 11, 2003 at 12:21:06 PM EST

Rest assured, Apple will not "port" Mac OS X to non-Apple hardware.  At least not if they continue to know what's good for them.  That would essentially be allowing "clones" in a PC-style way.  

A great many people are fond of pointing out that the lack of clones is "the major problem with Apple." Yes it keeps prices high and marketshare low. It's true. It is the worst thing about the platform.

And yet, it is also the one single thing that makes them unique in the market and gives them value. The vertical integration they have (hardware/os/iapps) allows them to a) innovate their product line faster and more radically than some other hardware/software makers and b) allows them to sell an entire end-to-end solution (like firewire-imovie-idvd-superdrive) with a user experience better than anyone elses. These things are at the core of what makes Apple Apple. Take them away - take away the vertical integration by doing clones - and what you get is cheaper boxes and much rejoicing...and a dead/dying platform within 2 years because it has lost that which made it valuable to begin with.

Bonus point: Why should anyone care? Certainly Mac users should care, but others should, too. Apple has an influence on the personal computer industry that is vastly disproportionate to its marketshare. They innovate. Others follow. Therefore, a healthy Apple is good for the industry. Mac clones = bad for Apple = bad for the pc industry.
-- scott d. feldstein http://www.scottfeldstein.net/log AIM: TheBeeWolf
[ Parent ]

OS X: An ok desktop with a crappy DE (none / 0) (#39)
by Silent Chris on Tue Apr 01, 2003 at 03:19:02 PM EST

OS X is an ok desktop (I'm a little surprised by some UI decisions -- like the ability to "hide" the control panel icons while in the control panel).  Development on the system is a nightmare, though, compared to most other toolkits.  Even KDE's half-based environment produces better results with less effort.  Hell, even Windows does (only other .NET -- programming under the old API was atrocious).

Apple's got a hard enough time getting developers to switch to the new widgets and "feel".  Making them relearn languages and have obstacle-laden libraries isn't helping.

Partially true (none / 0) (#41)
by epepke on Tue Apr 01, 2003 at 03:57:58 PM EST

Carbon has cruft dating back to 1984, so it's a bit of a pain.

Cocoa, on the other hand, is wonderful to work with. It does the job and, even more importantly, it then gets the hell out of the way.


The truth may be out there, but lies are inside your head.--Terry Pratchett


[ Parent ]
Carbon (none / 0) (#47)
by BlackFireBullet on Wed Apr 02, 2003 at 01:04:07 AM EST

I thought that Carbon was only added very recently, as I seem to remeber that most applications had to undergo "Carbonization" in order to work on OS X. I thought that it was the new API for OS X, however Apple also added backwards compatability by releasing the libraries so that they worked on OS 8.6+.

I admit, I have not done any development for the 'old' family of Apple OSs, thus I do not know whether Carbon is a new API, or a re-implimentation of an old API, or a combination of both, although the wait for applications to be 'carbonized' pushes me to think the former.

[ Parent ]

Well, sorta. (none / 0) (#49)
by DanTheCat on Wed Apr 02, 2003 at 02:11:36 AM EST

Carbon is the framework that is used to (relatively) quickly and painlessly port os 8/9 apps to run on X. Most apps that have been carbonized will run in both environments, I believe. It's meant for backwards compatability only, not new development.

Cocoa is the new X specific framework (evolved from nextstep, i believe) that everybody seems to like.

Dan :)

<--->
the art of compromise is now the only one they teach in schools
...
the art of compromise paid for all their swimming pools

[ Parent ]

How it happened (5.00 / 2) (#58)
by epepke on Wed Apr 02, 2003 at 04:52:12 PM EST

First, there was the Mac OS toolbox, dating back to 1984. This was used to make all sorts of Mac applications. It had its problems but was still pretty clean. Over the years, it accumulated cruft. (The original Mac OS didn't even have a hierarchical file system; folders were simulated by the Finder on top of a flat file system.) Apple was always pretty big on backward compatibility, so a lot of functions and techniques stuck around that were massive kludges in a newer environment. During this time, Apple also released MacApp, which was a Pascal object-oriented application builder.

When it came time to do Carbon, Apple took a subset of the classic Mac toolbox, getting rid of many of the cruftier bits and eliminating forever some of the old short names for functions (required for an identifier length limit on the older Pascal compiler). They also took some of the ideas of MacApp and applied them to C++. They also added a "core framework," a bunch of low-level utility routines in a more modern style.

The idea was that substantial portions of the code written for the original Mac toolbox would compile just as is. Code would mostly need to be tweaked at the very high level (different event structure) and the very low level (no old SoundManager calls, etc).

Cocoa, on the other hand, is based on the old NextStep for the Next. There is a rumor that it passed through OpenStep before making it's way to Cocoa, but I haven't been able to confirm that rumor. This is why the Cocoa classes and functions and constants begin with NS. While the Mac toolbox and Carbon were rooted in structured programming ideas and only grew object hairs, NextStep was built with object-orientation from the getgo. Back when it started, C++ was far from being a serious language, but Objective C was fairly well specified.

I remember hating Objective C when it came out; the efforts along the lines of C++ and similar efforts like Think's object extensions to C made a lot more sense to me. However, the way C++ has turned out, having a distinctive syntax for Objective C may have been a good idea.


The truth may be out there, but lies are inside your head.--Terry Pratchett


[ Parent ]
how long did you try it? (5.00 / 3) (#44)
by dougb on Tue Apr 01, 2003 at 07:04:07 PM EST

i'm not a gui programmer by trade, but i've found myself really enjoying os x development. normally, i develop service software for unix-based websites using perl and c++, to give you an idea of my background.

i'm wondering how much time you spent evaluating the development environment, it's different but i find it pretty useful. it took about 30-40 hours before i felt at home, but i was writing simple apps after a few hours of exploring the tools. i find that most of the time, i can hook up the connections in interface builder, tell it to generate the corresponding source code, and then fill in the callbacks using project builder. i've written a few gui apps so far and a bunch of command line apps, and it's been lots of fun.

i struggled for a while before i found all the examples in /Developer/Examples, they helped me learn a lot. i used a free cocoa class browser i found online to fill in the gaps in my foundation and appkit knowledge, that helped a lot too.

i think it's pretty fun once you get over the first learning curve, so hopefully you'll give it another shot. if not, that's cool. in that case, my comment is directed at everyone who read your comment and now thinks that os x is really hard to develop in. :-)

doug

[ Parent ]

Hiding Control Panel Icons (none / 0) (#53)
by thelizman on Wed Apr 02, 2003 at 12:19:10 PM EST

Windows does this by default also. Especially in Windows 95/98/2000/ME. If you have tweakUI installed, you can see the hidden icons and turn them on, though they are mostly useless. Without tweakUI, just do a search for "*.cpl", and you'll usually see about 5 applets that aren't loaded into the control panel by default.
--

"Our language is sufficiently clumsy enough to allow us to believe foolish things." - George Orwell
[ Parent ]
I'd like to go (none / 0) (#54)
by gnurb on Wed Apr 02, 2003 at 12:32:21 PM EST

Are there any more?

Was it free?

Reply (none / 0) (#64)
by codemonkey_uk on Sat Apr 05, 2003 at 04:45:14 PM EST

Sorry for the delay in my reply, I have just got back from the ACCU Spring Conference 2003.

Yes it was free, but I'm sorry to say the last day of the Tech Tour was on Friday 4th April (In Paris, France).
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]

Mac OS X Tech Talk Tour: UNIX on the Desktop | 65 comments (44 topical, 21 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!