Re: [Pyobjc-dev] NSAppEnableForeground

[Bob I. <bo...@re...>]

On Thursday, Feb 13, 2003, at 01:26 America/New_York, Ronald Oussoren  
wrote:

>
> On Wednesday, Feb 12, 2003, at 22:47 Europe/Amsterdam, Bob Ippolito  
> wrote:
>
>> On Wednesday, Feb 12, 2003, at 16:03 America/New_York, Ronald  
>> Oussoren wrote:
>>
>>> As I mentioned in the patch tracker I'd prefer to not use private  
>>> functions of other libraries, even more so when those functions are  
>>> not exported.
>>>
>>> During development I prefer to use the -l option of bundlebuilder,  
>>> that way I don't have to rebuild the app bundle unless I add new  
>>> files and I get a normal application, including Info.plist and the  
>>> like.
>>>
>>> Ronald
>>
>> If it would make a difference, I can convert that libFoundation.a to  
>> source code (using an undocumented but exported function or two).  I  
>> know how it works, I wrote something nearly identical to it about a  
>> year ago (reverse-engineered the jar launcher).  But I figured it  
>> might "feel safer" to use Apple's own implementation.
>
> Please convert libFoundation to C, if I understand correctly this uses  
> CPSEnableForegroundOperation and while that is an undocumented  
> function it is at least exported from its framework and used by a  
> number of other projects.

Just to cover bases, CPSEnableForeground is exported by  
CoreGraphics.framework, which is part of ApplicationServices (and used  
by AppKit, which you can prove for yourself).
% nm  
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ 
Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics | grep  
CPSEnableForeground
938a54b8 T _CPSEnableForegroundOperation

I will do so once I find the time (likely Saturday or Sunday).. but you  
should note that the "number of other projects" that use  
CPSEnableForegroundOperation are __all__ straight up copied from my  
reverse engineering of the jar runtime, which I did somewhere between  
dec 2001 and jan 2002... The first project that actually used the code  
was pygame, as that was what I was working on at the time.   You can  
tell that it's all derived from my original work by the fact that they  
all use the same code:
CPSEnableForegroundOperation(&PSN,0x03,0x3C,0x2C,0x1103);

I bet if you ask ANYONE that uses it, nobody can say what the purpose  
of the 0x03, 0x3C, 0x2C, 0x1103 are.  I never knew myself, they  
probably aren't actually arguments at all (see paragraph after next).

The fact that other projects use this function should not affect your  
decision on whether or not to use it, at least on my account, because  
it's *my fault* that other projects use it in the first place :)  As a  
quick fix I'm recommending the Apple implementation, but if I must  
write my own [again] to get into PyObjC - so be it.

That specific code is the result of on or two runs through gdb (reverse  
engineering the jar runtime), and that's what the registers told me.. I  
didn't know how many arguments it was actually expecting so I just made  
the call from what I saw in the dump, and it worked.. and I realized  
that since they're passed by register on PPC it really didn't matter if  
you specify extra ones.  Everyone has used this line of code for over a  
year now, even after a major upgrade to OS X, and it's Just Worked...  
surprisingly or not :)

Anyways, after looking at the disassembly of Apple's libForeground from  
GLUT this week, it's pretty obvious to me that  
CPSEnableForegroundOperation doesn't require all of these arguments. In  
my opinion, it's highly likely that CPSEnableForegroundOperation only  
requires the pointer to ProcessSerialNumber.. there's certainly not  
enough lines of PPC assembly in the otool -tVv output of libFoundation  
to specify 5 arguments.  I'll figure this out definitively when I get  
around to providing you with the equivalent C source to libForeground.a.

> Could you also add a (short) docstring?

Yeah, I'll do that when I add the C code.

-bob