Re: Using assembly in objective-c

FROM : glenn andreas
DATE : Mon Jan 21 20:36:22 2008

On Jan 21, 2008, at 12:58 PM, Twisted Theory Software wrote:

> I'm still trying, without luck, to use CoreMenuExtraAddMenuExtra() 
> from HIServices.  I know it's still in there, because otool shows 
> it: in the appropriate directory,
>
> % otool -Vt HIServices | grep CoreMenu
> _CoreMenuExtraGetMenuExtra:
> _CoreMenuExtraAddMenuExtra:
> _CoreMenuExtraRemoveMenuExtra:
>
> Given that I can see the actual assembly-language instructions in 
> this file using otool, can I somehow use that to define the 
> function? That is, in my program, can I write something like
>
> int CoreMenuExtraGetMenuExtra(...) {
>
> return gccUseAssemblyString( assembly from otool );
>
> }
>
> Thanks,



Please don't.  It's not a publicly document routine - you shouldn't be 
it.

In order to use something like this from assembly (or at all, for that 
matter) you need to know what all the parameters are (type, size) and 
what they are used for.  CoreMenuExtraAddMenuExtra is a private SPI - 
so you know none of these.  Calling a routine by randomly passing 
parameters is a good way to make things crash - worse, if not your 
app, potentially somebody else's app.  Even if you get it to work, 
unless you understand what all the parameters are (and the side 
effects of the routine) you have no idea if it will continue to work 
on future OS versions
(resulting in the "don't upgrade to this version of the OS because 
it's buggy" mentality - when in fact it is some third party app that 
causes the problems, not the OS),

"But it works fine on my machine" doesn't mean it works fine on 
everybody's machine.  Do you have access to being able to test all 
currently shipping OS version on all shipping (and many no-longer-
shipping-but-still-in-customer-hands) hardware?  Do you know if 
installing things like drivers for other hardware won't alter  the 
semantics of this routine?
"But I know what I'm doing" - without having official documentation 
about the routine, no, you don't.
"But I really need to use this functionality - Apple uses it in their 
software" - yeah, well, that's too bad, but they wrote the OS and 
actually know what they are doing with that routine and its 
ramifications.  Plus since said use by Apple is usually in software 
that is a part of the OS, they don't have to worry about different OS 
versions (they can update their app with the OS).
"But this is the only way to accomplish a feature I need" - file an 
enhancement bug asking for a public API for that, explaining exactly 
what you are trying to accomplish (as opposed to just "I need this 
routine").  Ask on the mailing lists on how to do some task.
"But this other app uses it/I found a reference to it on the web" - 
That doesn't make it a good idea.  More than a few apps that use 
these private APIs have broken, and many of the reverse-engineer 
routines have changed between OSes version (either in subtle 
semantics, or in major ways by adding/removing parameters).

End users may want features, but they need stability more than 
features (if it isn't stable, it doesn't matter what features it 
offers since the user won't be able to access them reliably).

In this particular case, Apple doesn't support third parties writing 
MenuExtra's - use an NSStatusItem.  While the two aren't exactly the 
same  (there are some subtle behavioral differences, such as being 
able reorder them), they should be adequate.  What specific 
functionality do you need to use a MenuExtra for that you aren't 
getting from an NSStatusItem?  (And have you filed an enhancement 
request bug to add that functionality?  If you don't ask, don't expect 
it to be added)





Glenn Andreas                      <email_removed>
  <http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next 
generation of fractal art