Rumour has it that the Mac OS X 10.5 will not have 64bit Carbon support under Intel. That means that Intel based Carbon based apps will only ever be 32bit and that if 32bit support is ever withdrawn (likely?) Carbon will be gone.

I know that the FPC GUI ports under Mac OS X tend to use Carbon.... anyone heard any definite reports on this? I know OS News has one, but that is allegedly still hear-say. Is it even possible/practical to use Cocoa to build a GUI and then use Pascal code to do the logic?

Apaprently Troll Tech is unhappy as they use Carbon in their Qt port for Mac OS X...

M

memsom wrote

allegedly still hear-say. Is it even possible/practical to use Cocoa to build a GUI and then use Pascal code to do the logic?

you can try and build all your functionality into an fpc dynamic lib and then link to it out of xcode. we'll need a layer to export the objective c in a way that we can use it if we're ever going to use cocoa directly. i think it contains a gazillion objects, so this is not trivial...

henry

Currently, Cocoa is only usable from ObjC.

Well, they have the same problem as any non ObjC user probably: using Cocoa from non ObjC languages is hard.

memsom wrote

Rumour has it that the Mac OS X 10.5 will not have 64bit Carbon support under Intel.

It's not just a rumour, and it's not Intel-only. Several parts of Carbon will not be 64 bit under Mac OS X 10.5. See the "64-bit Carbon" and "Is Carbon Viable?" threads at
http://lists.apple.com/archives/carbon-dev/2007/Jun/thrd3.html

(and on the following pages)

In particular the messages from Eric Schlegel (he's from Apple), e.g. http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00426.html http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00433.html

That means that Intel based Carbon based apps will only ever be 32bit and that if 32bit support is ever withdrawn (likely?) Carbon will be gone.

Nobody can say how likely that is. It definitely won't happen in the near future, since there are a lot of Carbon apps out there.

Yes, it is (just as practical to do the logic in C or C++).

Jonas

You don't really have to do that, Apple already did that: http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/

And those routines can be used to build an Objective Pascal on top, to make interfacing easier. And for inspiration for that, see http://www.pascal-central.com/cwpascal.html#Extensions%20providing% 20compatibili
http://en.wikipedia.org/wiki/Objective_Modula-2

Jonas

by the way, do fpc dynamic libraries work in osx? i remember that i had to use the "-install_name" option with gcc. does fpc have something similar?

henry

Yes.

i remember that i had to use the "-install_name" option with gcc. does fpc have something similar?

You can use the equivalent linker parameter using

-k'-dylib_install_name "Your Installation Location"'

Jonas

interesting, thanks for the links.

Jonas

henry

memsom wrote

Apaprently Troll Tech is unhappy as they use Carbon in their Qt port for Mac OS X...

Everyone is unhappy. Office, Photoshop, Adobe products, Firefox, wxWidgets, etc, are all based on Carbon.

Actually to me it seams that Apple is the only entusiastic company about Objective C

This is sad, but at the same time isn't the end of the world, because:

* The transition to 64-bits will take time, so we have some years still where work can continue with Carbon

* Even then 32-bits carbon apps will keep working normally on 64-bits computers

* Until 64-bits GUIs are really needed we will already have some way of interfacing with Cocoa, which can be either supporting obj-c objects on Pascal or procedurizing the Cocoa API

To write stand-alone apps the first approach is 1 million times better, but, for example, to write a Lazarus interface the second is more then enougth.

They have lured many younger developers into the Cocoa cage, but AFAIK the big players
are not there and are unlikely to go there since they need good cross-platform solutions
and can't afford rewriting everything over and over again.

And

* Apple might decide to make 64-bit Carbon if enough big players are unhappy with the
situation.

If that happens (even if it only happens to the modern Carbon APIs like HIView etc)
then all is well and we can go on moving forward.

If it doesn't happen, if Apple insists that Objective-C is the only path into 64-bit, then a
third path will be needed, and I think that should be a strict cross-platform solution.
That will make the Mac interface diverge more than before, but if Apple does not open
better paths it will happen.

At the moment, I would like to see more detailed information about what is actually
officially depreciated, what non-ObjC interfaces are actually ported (CG for sure,
all low-level Unix stuff etc). There is a great confusion about what "Carbon" really
is. If Apple drops QuickDraw, old Menu Manager and other old APIs, but supports
the new APIs, I won't be happy about it but at least the time I spent learning the new
ways is not wasted.

/Ingemar