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

[Richard Frith-Macdonald]

On 9 Jan 2006, at 06:31, Sheldon Gill wrote:

> 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*.

OK ... but we need to be sure what we are talking about and what the  
reasons are ...
Are you against the principle of allowing args/environment to be  
overridden programatically, or against the specific implementation?   
We also need to know why this is currently being done by at least one  
person (wish I could remember who it was), who presumably is of the  
opinion that it *is* a good feature.

I can invent obscure setups where this would obviously be very  
useful ... but I don't know which actually apply.

> > 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.

A significant minority will ... anyone embedding gnustep code inside  
other software written in another language or without main() being  
available for some other reason (eg an apache module)  for instance.

> > 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?

Yes, but I can see that there are lots of situations (fitting code  
into other software frameworks) where that might be inconvenient  
(perhaps completely impractical for all I know).

I think on balance, I'm in favour of the principle of allowing  
programmatic override of ars/env ... (since we *must* have a  
mechanism to provide args/env for lots of uses, and allowing that  
mechanism to override the default setup is not a very complex  
extension), but I would prefer a better implementation.

IMO if we go down that route, we should provide a function to do it  
and remove the method of NSProcessInfo ... so it can be done easily  
from other languages and *before* the objc runtime and any classes  
are initialised.  That would allow code inside the base library to  
access the environment in a consistent way.

We should also change the existing code to work around the current  
problem that the C-string characterset we use is determined by an  
environment variable, but we don't know how to parse the environment  
variables until we know the characterset we are using... in this  
respect the current windows code is better than the unix code ... we  
use the unicode api to get the environment and therefore don't need  
to worry about converting from a C-string.