Re: Carbon removal
On Jul 3, 2013, at 19:23, Chris Paveglio chris_paveg...@yahoo.com wrote:
I've got a project that I am working with, that I did not create. I am trying
to understand it and I would like to remove the Carbon framework dependencies
in it. I don't know anything about Carbon. Is there a good resource to read
up on it? Are there replacement methods in other frameworks to replace some
of the Carbon apis? I'm not really sure where to start.
For example, here's a function I will need to replace, where could I find any
of the same calls or another function to replace OSStatus?
OSStatus is an error code. I blogged about it ages ago here:
http://orangejuiceliberationfront.com/carbon-for-the-cocoa-guy-oserror-and-osstatus/
AFAIK, OSStatus is still being used in CoreFoundation, so you don’t have to
get rid of it. However, Carbon Events are kinda on the way out, I think,
(though I think the very basics are still available in 64 bit, they’re not much
use without the event types etc.). To find out what this handler does, we’d
need to know what types the event is registered for in sAppEvents.
As a general rule of thumb, most event handlers match to methods in
NSResponder, though of course there are lots of specific types where there’s
dedicated callback APIs in Quartz, NSEvent, etc.
pascal OSStatus AppEventHandler( EventHandlerCallRef inCallRef, EventRef
inEvent, void* controller )
{
OSStatusstatus = eventNotHandledErr;
if(GetEventClass(inEvent) == kEventClassApplication)
{
UInt32 mode = 0;
(void) GetEventParameter(inEvent,
kEventParamSystemUIMode,
typeUInt32,
NULL,
sizeof(UInt32),
NULL,
mode);
[controller modeDidChange:mode];
status = noErr;
}
return status;
}
--
and later
--
InstallApplicationEventHandler( NewEventHandlerUPP( AppEventHandler),
GetEventTypeCount( sAppEvents ),
sAppEvents, self, NULL );
---
Thanks for any help.
Chris
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/witness.of.teachtext%40gmx.net
This email sent to witness.of.teacht...@gmx.net
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Carbon removal
On Jul 3, 2013, at 21:40, Jerry Krinock je...@ieee.org wrote: To answer your question, I think the procedure is… * In your main target and its target dependencies, * Set the SDK to Latest Mac OS X. * Set the architecture to x86_64. * Clean your project, so that everything will be recompiled. * Analyze your project (⇧⌘B). After it's done, look at the newly-produced Build log in the Logs navigator. Any deprecated or no-longer-existing functions and types should be listed as warnings and errors. Fix and repeat. This isn’t a general procedure though. What this does is switch the entire application to be compiled as 64-bit, which just happens to have the side-effect of not supporting most of the deprecated Carbon calls. If your application does any low-level byte manipulation or uses the ‘long’ data type (instead of fixed-size types like UInt32 or int32_t), this will also completely break your code. long is 32 bits on 32-bit, but 64 bits on 64 bit. Pointers will also suddenlt by 64 bits in size. So if you pass any pointers through a refCon or userInfo parameter that happens to be typedefed as UInt32 or so, you’ll be stripping off half the pointer and causing entertaining crashes. Now you’ll have to port to 64-bit eventually anyway, but it might help to first go over your code and look for any longs you’re using and make sure they’re turned into int32_t or uint32_t if they’re supposed to stay 32 bit, or use intptr_t or void* for any types that are supposed to be the size of a pointer. -- Uli ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Carbon removal
On 2013 Jul 04, at 02:14, Uli Kusterer witness.of.teacht...@gmx.net wrote: What this does is switch the entire application to be compiled as 64-bit, Yes, you're correct, Uli. I moshed in the 64-bit conversion with this as extra insurance. which just happens to have the side-effect of not supporting most of the deprecated Carbon calls. If you simply use the latest SDK, will you not supposedly get compiler warnings of *all* deprecated calls, Carbon or otherwise? Now you’ll have to port to 64-bit eventually anyway, but it might help to first go over your code and look for any longs you’re using and make sure they’re turned into int32_t or uint32_t if they’re supposed to stay 32 bit, or use intptr_t or void* for any types that are supposed to be the size of a pointer. Yes, and there's a whole document on converting old apps to 64 bit. https://developer.apple.com/library/mac/#documentation/Darwin/Conceptual/64bitPorting/transition/transition.html#//apple_ref/doc/uid/TP40001064-CH207-TPXREF101 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Carbon removal
I've got a project that I am working with, that I did not create. I am trying
to understand it and I would like to remove the Carbon framework dependencies
in it. I don't know anything about Carbon. Is there a good resource to read up
on it? Are there replacement methods in other frameworks to replace some of the
Carbon apis? I'm not really sure where to start.
For example, here's a function I will need to replace, where could I find any
of the same calls or another function to replace OSStatus?
pascal OSStatus AppEventHandler( EventHandlerCallRef inCallRef, EventRef
inEvent, void* controller )
{
OSStatusstatus = eventNotHandledErr;
if(GetEventClass(inEvent) == kEventClassApplication)
{
UInt32 mode = 0;
(void) GetEventParameter(inEvent,
kEventParamSystemUIMode,
typeUInt32,
NULL,
sizeof(UInt32),
NULL,
mode);
[controller modeDidChange:mode];
status = noErr;
}
return status;
}
--
and later
--
InstallApplicationEventHandler( NewEventHandlerUPP( AppEventHandler),
GetEventTypeCount( sAppEvents ),
sAppEvents, self, NULL );
---
Thanks for any help.
Chris
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Carbon removal
On Jul 3, 2013, at 10:23 AM, Chris Paveglio chris_paveg...@yahoo.com wrote: For example, here's a function I will need to replace, where could I find any of the same calls or another function to replace OSStatus? This is an event handler — I’m not sure what it’s doing, but it’s certainly going to have to be done completely differently in a Cocoa app, because AppKit is doing this kind of low-level event handling internally. It looks like this is getting a parameter named “kEventParamSystemUIMode” from the event and passing its value to [controller modeDidChange:]. You could start by looking up that this parameter means, and then see what the Cocoa equivalent is. —Jens smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Carbon removal
On 2013 Jul 03, at 10:23, Chris Paveglio chris_paveg...@yahoo.com wrote: I am trying to understand it and I would like to remove the Carbon framework dependencies in it. As I understand it, the box surrounding Carbon is fuzzy. There are even some API documents with Carbon in their names whose functions are going to be around forever. To answer your question, I think the procedure is… * In your main target and its target dependencies, * Set the SDK to Latest Mac OS X. * Set the architecture to x86_64. * Clean your project, so that everything will be recompiled. * Analyze your project (⇧⌘B). After it's done, look at the newly-produced Build log in the Logs navigator. Any deprecated or no-longer-existing functions and types should be listed as warnings and errors. Fix and repeat. Even the two functions you mentioned may in fact turn out to be OK. I don't think that the OSStatus type is going away. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
