Re: [bug #15353] win32 compilation of base fails on NSProcessInfo.m (checked out from CVS today)

[Sheldon Gill]

Richard Frith-Macdonald wrote:
> On 9 Jan 2006, at 05:27, Sheldon Gill wrote:
>
> > > Follow-up Comment #5:
> > > I'm fairly sure this is fixed by moving the declaration of
> > > fallbackInitialisation.
> > > At least ... the current code in CVS compiled and runs fine for me
> >
> > Could you please explain why "fallbackInitialisation" is needed and  a 
> > good idea?
>
>
> I'm not at all sure it *is* a good idea.

Good, because I'm firmly of the opinion that its *not*.


> Basically, it arises from a complaint I got from a windows user  (can't 
> remember who) when I fixed the NSProcessInfo code for  obtaining the 
> environment information to ensure that it got the  correct character 
> encoding (using the unicode api ... the original  code just assumed that 
> the environment info was in latin1 encoding).
>
> The change broke this persons code ... he was using  
> +initializeWithArguments:count:environment: to specify an environment  
> to which he had added some extra environment variables, and my  
> restructuring with fallbackInitialisation was a quick hack to restore  
> the original behavior where the real environment can be overridden.

Perhaps better something supplied as a patch rather than immediately put into 
cvs HEAD?

> Now, the intention of +initializeWithArguments:count:environment: was  
> to supply a mechanism to initialise NSProcessInfo for  systems where  
> the base library can't determine args/env automatically, not to  
> override/alter the args/env, so arguably he shouldn't have been using  
> it for that, which is why I'm not sure that continueing to support  that 
> behavior is a good idea.

I recall the intention of the method. It can remain a usable method at program 
start if the base auto-main stuff is compiled away I guess. (ie force:

main()
{
  [NSProcessInfo initialize...]
}

but not many would want that.

> If we *do* want to allow the args/env to be overridden  
> programmatically, we should document the behavior and ensure that it  
> always works.

The *right* way to over-ride args and env would be to do so in an app-wrapper 
and then exec, isn't it?


Regards,
Sheldon