As the original poster I feel obligated to reply with the solution to
the problem that you all helped with because of the "waves" my post
kicked up and because other developers may very well be in the same
situation as they come for the first time to the Apple platform. Sorry
but the post is a little long.
The problem that we face is that we like many other developers of
portable device software are suffering from the market being too
fragmented. To use relative numbers there is a market of 100,000 where
there are 100 users on each platform in the market. Writing 1,000
variants is an impractical business model. To sidestep this problem we
have written our own safety critical microkernel, windowing system,
etc that uses OpenGL ES/SC as a display output. If an operating system
is used at all it is only needed as the creator of the original
graphics context and as an event handler "device driver" for user
events.
We were hoping to use the Carbon APIs to process user events from our
microkernel's polling loop, where there was some backdoor header file
that could be copied to the iPhone SDK to allow this to take place.
Thanks to you all we quit trying this approach.
To solve this problem, without having to completely rewrite our
applications, we used Cocoa to create a window with an OpenGL view and
set up the event handling for the view. We then created a thread and
ran our existing microkernel application in the thread where it
interacted with the Cocoa side for OpenGL context switches and the
reposting of user events from the Cocoa view into our application's
event queue.
The only difficulties that we faced with this approach was how to call
Cocoa functions from C to trigger OpenGL context switching, since
changing all the .c extensions to .m was not an option. Safety
critical code is largely written C or Ada. We could have used user
events between the C and Obj-C code sets but we were worried about
possible timing issues or race conditions.
To allow the C modules to call Objective-C functions we defined a
static pointer to the Obj-C object in the .m source module and
implemented C functions in the same .m file that used the static
object pointer to call the corresponding Obj-C method that we wished
to expose. A separate header was created that only had the C function
protocols and this was included into the C modules that needed to
interact with the Obj-C layer.
With this approach our application just ran. It was pretty cool to see
it fire up on the iPhone simulator for the first time!
Since we are are about 2-week-old Obj-C developers, if any of you know
of a better or more established way of doing this we are open to your
comments.
I know at times we lose sight of this, but it was not that long ago
that all of this passion about Carbon or Cocoa would have ended in the
thought of "Yes, but who really cares!". It is fun to see the Apple
rebirth and to have a legitimate hope that all of this passion is not
wasted.
Thanks for the help and you all take care,
Jim
On May 28, 2008, at 8:41 AM, Steve Christensen wrote:
On May 28, 2008, at 1:45 AM, Laurence Harris wrote:
On May 26, 2008, at 9:46 AM, Michael Ash wrote:
So your careful observations have led you to the conclusion that I
am
well versed in Cocoa and not as well versed in Carbon. Brilliant! I
would have told you this directly if you had asked.
Mind if I ask why you're subscribed to this list since you don't seem
to have a big investment in it and don't plan to?
As has been mentioned previously, the bickering isn't really helpful
and just comes across as bitter more than anything else.
Larry, according to your reasoning if someone has an existing Carbon
app and they think that adding support for, say, Core Animation
would make it even more useful/marketable/whatever, that they
shouldn't be able to subscribe to cocoa-dev so they could ask
questions because they don't have a big investment in Cocoa (and may
not plan to).
And given the tenor of this thread to date, I suspect if said person
happened to mention that they had added Core Animation support, the
response from some quarters would be less than favorable unless they
included the qualification, "...I got it to work, but it meant
having to add some Cocoa code to my app" and made little gagging
sounds. :)
steve
_______________________________________________
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/eqjrb
%40attglobal.net
This email sent to email@hidden
_______________________________________________
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
