It is, but it is a separate Window server app. I could be wrong, but couldn't a 64-bit Darwin app call X11 and still function. Only the GUI would be 32-bit.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Leopard Drops 64-bit Carbon Support
- Thread starter MacRumors
- Start date
- Sort by reaction score
It is, but it is a separate Window server app. I could be wrong, but couldn't a 64-bit Darwin app call X11 and still function. Only the GUI would be 32-bit.
Wow, this is dumb... Apple is finally starting to make some gains on the front runner and they decide to shoot one of their feet?
Tell me someone is going to release a C++ framework that basically wraps the Cocoa API... Won't work for everything, but maybe enough to keep open source apps viable?
At the very least, anyone who had 64bit-ness on their roadmap (mainly the power apps) will have to delay development and probably disband their Mac dev teams. Will they start them back up in 2 years? We'll have to see...
Tell me someone is going to release a C++ framework that basically wraps the Cocoa API... Won't work for everything, but maybe enough to keep open source apps viable?
It could stop Adobe, but you're right, the big risk is that new applications won't be ported. Things were finally getting to a place where there was an argument to be made for porting applications to OS X, and now they just made it 10 times harder... Unless the rumors of the return of Yellow Box are true, this makes it a pain to maintain cross platform compatibility.
You'd discontinue it because the pain of maintaining it exceeds the revenue. As it stands there is no guarantee of 64bit Carbon ever. First there was the OS X switch, then the Intel switch, now the framework switch. Real companies aren't in the habit of gritting their teeth and shouting "Thank you sir! May I have another?!" Developers don't want to spend all of their time moving the same code from architecture to architecture-- they want to spend their time improving their code. All of these changes and the broken promise on Carbon make OS X look like an unstable platform to support.
At the very least, anyone who had 64bit-ness on their roadmap (mainly the power apps) will have to delay development and probably disband their Mac dev teams. Will they start them back up in 2 years? We'll have to see...
The official line has changed.
Much of carbon is 64-bit ready in Leopard, and they are taking input on what further parts are required by developers.
So it seems like only the oldest parts of Carbon have been pruned (and these have substitutes in Carbon anyway). More than enough is left so that cross platform developers can still write applications.
Good news!
Much of carbon is 64-bit ready in Leopard, and they are taking input on what further parts are required by developers.
So it seems like only the oldest parts of Carbon have been pruned (and these have substitutes in Carbon anyway). More than enough is left so that cross platform developers can still write applications.
Good news!
If you can tell me how to write a Carbon application without using Window Manager, Menu Manager and Control Manager...
The stuff that was mentioned as being present is exactly what you don't need in a cross-platform application, because you have code handling your data and strings already. And the user interface is exactly the part where Cocoa is a pain for cross-platform applications because it cannot be made to fit in.
Handbrake doesn't have any Cocoa code that is _integrated_ into an existing codebase. Handbrake is a tiny Cocoa application, with lots of C libraries integrated into the Cocoa application, not the other way round. The problem is integrating Cocoa into existing applications, and Handbrake doesn't have that problem.
HIToolbox. (If my memory is correct, it is a full replacement for all three, and the C version of Cocoa's view-based controls, meaning you can get more of Cocoa's features for free without going into Obj-C)
Which is only somewhat true. HB is split into libhb (which links with all the C libraries you discuss), and the Obj-C front-end. libhb is pretty much the object model for the app, written in C. It does all the heavy lifting, the threading, handles the pipeline, etc, etc. The Obj-C front-end just queries libhb on the status for UI updates, and takes UI input and feeds it into libhb to create jobs for it to run.
libhb is also wrapped into a C-based CLI app which does all the same things that Handbrake does, but with a command-line interface (mostly used for the Windows port and testing).
And HIToolbox is also not available in 64-bit. I've been following the Carbon Dev mailing list and apparently the only reason 64-bit Carbon was canned was because Apple management wanted to get rid of it and emphasize Cocoa.
It sounds like 64-bit Carbon was largely complete and ready to go and then management recently told the Carbon team that 64-bit Carbon will be canned. From what it sounds like on the mailing list this was very recent as even Apple's Carbon engineers still don't know with certainty what will and will not be included. Also, it was mentioned that 64-bit Xcode in Leopard currently renders all of its menus using 64-bit Carbon (as the Cocoa menu system has always been based on Carbon). So it seems that Apple will have to spend ADDITIONAL resources to rip out and replace the largely complete 64-bit Carbon.
What a brilliant decision! Alienate your biggest and oldest developers while at the same time spend MORE resources to remove something that is nearly complete and used by even your own applications.
While I agree that this move (depending on how accurate it is) is bone-headed... I don't think they will be ripping out and replacing 64-bit Carbon if they do. They will likely make it all private in order to make October's ship date, meaning 64-bit Cocoa will be allowed to leverage it, but not 3rd party apps.
That is if Adobe/Quark/etc don't all rip Apple a new one.
Then again, Adobe already is having tons of fun with CS3 and the Intel transition (having to do stuff they put off with hacks to keep OS 9-era bits running).
So what is the official (least items) long-term hardware and software compatibility path for:
OS 4.2, OS 6.1, OS 7.5, OS 8.6, OS 9.2, OS 10.3
68000
68020
68030
68040
601
G3
G4
G5
There must be a subset of Apple hardware timeline which has sufficient crossover and compatibility to deal with many of those. Mac IIci, 8100 and PB Ti G4 pop to mind.
Rocketman
OS 4.2, OS 6.1, OS 7.5, OS 8.6, OS 9.2, OS 10.3
68000
68020
68030
68040
601
G3
G4
G5
There must be a subset of Apple hardware timeline which has sufficient crossover and compatibility to deal with many of those. Mac IIci, 8100 and PB Ti G4 pop to mind.
Rocketman
Hmm, were you there at the conference? Cause, I was, and it was largely a non-issue. Its time to move on, apple can't keep updating features twice, once in carbon and once in cocoa....its a waste of resources. There are many things that have been done to enhance C++ and Objective-C compatibility...
But how easy is it to move from Carbon to Cocoa, and how are they not pissing off their Carbon developers who have just moved to Xcode/Intel? Which is the point I originally made. It seems you want to duplicate the functionality because Cocoa and Carbon have different strengths and are complimentary, Carbon is far better for cross platform applications for a start.
It really sounds like that doesn't it
Not really. There are many ways to integrate cocoa with carbon, some of which are coming with leopard. There was a nice talk by Kevin Hoffman (the .NET addict) that was very nice and went into cross-platform stuff, but since EVERYTHING in WWDC is under NDA, my lips are zipped...... but lets just say, there is no pressing need right now for 64-bit carbon apps, and in the future, the apps that need to be 64-bit can be ported to cocoa.... in the long run, apple can't keep updating carbon forever.............
A lot easier than maintaining the same dusty code base year after year. And it's a move they should have made ten years ago.
Moved from where exactly?
How do you figure that? Perhaps over half of any GUI app is the GUI stuff itself. What in the name of all that is compiled does an archaic and rather obtuse system like Carbon have in common with .NET, the Windows API, or GNOME or KDE?
Not to speak of the fact that Cocoa is relatively easy, relatively streamlined where these other platforms are terrible nightmares.
And it isn't the "procedural" as opposed to the "object oriented". For Cocoa can wrap Carbon but not the other way around. Do like this.
1. Create a new Cocoa project in Xcode.
2. Pull all your old Carbon code into it.
3. Wrap that Carbon code inside your app classes.
4. Start decimating the Carbon cruft left and right - you won't need the half of it anymore.
CodeWarrior, which is what all the major apps used to use before the Intel switch, they now use Xcode, so they have just gone through a major transition now to have this one thrust upon them.
The problem with Cocoa seems to be (which is based on the previous couple of pages of posts), is that it is too clever and does stuff that cross platform applications don't want to use. I don't develop with Carbon, but it doesn't seem like that brilliant a move as Adobe/MS and other major developers use Carbon.
Yup. I remember CodeWarrior. Shame that it had to go, but when the Intel transition was looming, Freescale killed that product faster than you can say, "Huh?"
Or was it already killed at that point?
The advantage of Cocoa is also that you can override behavior whenever you see fit. Some of the best Cocoa apps are written by programmers who know when to step in and do it themselves instead of letting Cocoa do it for them. Early prototypes/alphas are much more stable and easier to produce using bindings and default behaviors than otherwise, and then you override the behavior as you move forward.
Still, unlike what other posters claim (not you)... Carbon is definitely not an old and dusty API. It has received major upgrades, and while I haven't used most of them, it is a much more robust and polished API now than when it was with CarbonLib 1.0.x. Although even that was a huge step up in many ways over InterfaceLib.
In an extreme case of bad luck, Freescale had sold off the Intel version of the Codewarrior compiler complete with all the rights about six weeks before the Intel Macs were announced, that was about five weeks before the first rumors about Intel Macs came out.
Anyone who had been using CodeWarrior knew long before (more than 6 weeks) the Intel announcement that the writing was on the wall. Metrowerks/Freescale hadn't announced anything officially but it was easy to tell that CodeWarrior was heading for the grave. The Intel announcement was really just the final nail in the coffin. I say this having worked at a CodeWarrior-using company that had already started moving from CodeWarrior to Xcode well before the Intel announcement.
CodeWarrior might have survived a bit longer on life support had Apple not switched to Intel, but it would probably still be a dead product today.
CodeWarrior as we know it might... but don't forget Codewarrior is also Freescale's embedded IDE for the PPC line and couple other products.