Carbon was intended as a transitional API from OS 9 to OS X and it
worked well for that purpose. Carbon's been around since the advent
of OS X so how long do you keep a transitional API alive? The problem
here is that the replacement API (Cocoa) is nothing like carbon and
as Larry has said, it's much more than just an API. It's an entirely
different philosophy of programming and one that is not cross-
platform. Hind sight is 20/20 but maybe a better thing to do would
have been to develop an API similar to Windows (heretic!!!) given the
fact that we're now transitioning to Intel anyway. If Apple had done
that instead of ramming Next's Cocoa API into XCode, maybe we'd all
be better off as Apple developers today. The way to keep the Mac
viable is for software that people run under Windows to also run
under OS X. The stumbling block has been Cocoa because it's so
different.
Since the original post in this thread was about the lack of 64-bit
carbon, l guess I better say something about 64-bit operation or risk
Larry's wrath coming down on me for being off topic (just kidding
Larry:-). The kernel is 64-bit and has been for quite some time. So I
wrote a command-line program and it's been 32/64-bit compatible for
over a year now. The moral: Don't use GUI's, just use unix kernel
calls and "fuggettaboutit" as Tony Soprano would say... LOL.
Tony
On Jun 13, 2007, at 8:06 AM, Jo Meder wrote:
I'm in pretty much the same boat. Our product is a landscape
visualisation/renderer app. We can hit the 32 bit address space
limit with ease. We need 64 bit support, and have been hanging out
for Leopard with 64 bit Carbon support since that was announced. We
also have a cross platform application framework, and all the Mac
stuff is Carbon. I've already started on the Mac side of things
with removing the last stuff which was said to be unsupported in 64
bit Carbon previously. Having to reimplement all the platform
specific stuff in Cocoa is going to be a serious problem, even if
it's only due to the time needed. We're only a small company, it
would be a major setback. Rearchitecting the app into a 32 bit GUI
and 64 bit backend would be just as bad and probably worse, and a
major issue is that we wouldn't need to do that for the Windows
version and so it would be a huge black mark against the Mac
version. It basically wouldn't happen.
I'm happy with the idea of needing to mix more Cocoa/Obj-C into my
mainly Carbon codebase in the future, based on Apple only seeming
to be adding Obj-C APIs for new stuff going forward. I was happy
with the changes I would need to make because 64 bit Carbon removed
a bunch of legacy stuff. To potentially have the rug pulled out
from under me entirely in this manner is very distressing though. I
was intending to have a 64 bit Mac version of our app ready to go
for Leopard's release, but if there is no 64 bit Carbon I can't
even begin to think when we might be able to do that. I'm positive
we'll have a Windows 64 bit version available long before it
happens though.
Sometimes as a Mac developer I feel like Apple is working against
me rather than working with me in delivering apps for the Mac. I'm
not talking about things like the Carbon or Intel transitions,
those were pretty straightforward from my perspective. However more
and more things seem to need to be done on Apple's terms and there
is little flexibility. I understand that Apple have put the
emphasis on Cocoa from the beginning of OS X, but Cocoa has never
offered anything compelling to me as a long time C++ Mac developer,
and particularly as someone who has for a long time been involved
in cross platform projects. What parts of Cocoa I have wanted to
take advantage of I have been able to access from my Carbon app,
which is cool. I guess I should've read between the lines more and
had less faith that Carbon was still going to be a feasible API
going forward. Ah, well, time to go and quiz my Dev Relations guy,
I guess an ADC Select membership has to be good for something...
Regards,
Jo Meder
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
