Re: [Pyobjc-dev] Python rather than ObjC for main?

[Peter M. <zig...@po...>]

On Friday, November 8, 2002, at 05:59 PM, Ronald Oussoren wrote:

> On Thursday, Nov 7, 2002, at 16:40 Europe/Amsterdam, bb...@ma...=20
> wrote:
>
>> A lot of Foundation/CFBundle applications (and a number of AppKit=20
>> applications) never use NSApplicationMain().  As well, one could=20
>> easily implement something like:
>
> As Bill noted Cocoa seems to fetch the value of argv[0] from somewhere=20=

> else. It is not even fetched from the argv vector (e.g. argv[0] =3D=20
> "foo" wouldn't be usable). I guess it is fetched directly from the=20
> datastructure passed in by execv(), which is only the source from=20
> which the argv vector is build.
>
> IIRC a couple of months ago someone on the MacPython list suggested=20
> how to deal with this using some undocumented function calls.

OK, I've been looking though some of the source to CoreFoundation and=20
CFBundleGetMainBundle() uses a function called _CFProcessPath() to get=20=

the path to the process.

_CFProcessPath() does a couple of things. First it checks to see if it=20=

already has the path cached. If it doesn't, it looks to see if an=20
environment variable called "CFProcessPath" exists. If it does, it uses=20=

that (I've checked this. It works!). If it doesn't, it calls=20
_NSGetArgv(). _NSGetArgv() just returns the global variable char=20
**NXArgv. Note that this variable is present in even the simplest CLI=20
program. You can apparently modify it (unsupported of course).

Anyway, a function called __CFInitialize() is called by _start() (or=20
something else before main() is called, I'm not sure. Couldn't find the=20=

source for _start()). Down the bottom of the function is this line:

=A0_CFProcessPath(); =A0 =A0 =A0 =A0// cache this early

This means that CF already has the process path determined and cached=20
before main() is even called. Damn. I was getting hopeful for a while=20
there.  Well, I think I give up.

Peter=