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 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'm against the specific implementation primarily.

In general, though, I think we should stick to keeping things clean and simple 
as far as possible. I also think we should stick to the API.

In this case:

[[NSProcessInfo processInfo] arguments] returns an NSArray of NSStrings which 
are, by definition, the arguments used to start this process. Want different 
arguments? Start the process with them.

[[NSProcessInfo processInfo] environment] returns a NSDictionary giving the 
environment variables for the process.

The issue was raised by a windows user for windows. The root cause here seems 
to be that the user wanted to have the library initialised a particular way. 
Lets analyse the fundamental driving concern and deal with it appropriately. 
I'm willing to bet it was to have the library go with an application in 
'stand-alone' mode. If that is the case then the right solution is to build the 
library appropriately for the application.

Fundamentally, "fix it where its broken" rather than "get around that by..."

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

There are lots of potentially useful things which could be added. As a 
Foundation library, though, I don't think they should be. Keep it clean, keep 
it simple. Fancy adds should be outside.

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

You mis-understand me. I didn't say it very well. I was referring only to 
applications/tools.

If you were using -base in an apache module on Linux the args/env would be 
properly set up from /proc.

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

If a specific difficult situation should arise we should examine it

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

We need to get args/env for the process. Period. The reasons why any particular 
application wants to use them is secondary. The need to set them for -base 
startup seems to me to be pointing at other issues/design decisions.

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

IF we go down that route, yes it would be best done (and easily) by setting 
pointers during [load] time rather than relying on [initialise] time.

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

This is a platform issue, rather than a GNUstep one:
- On windows the environment strings are known a-priori to be UTF16 so its
easy.
- *nix has umpteen variants with different settings. How to decide which 
characterset/encoding/codepage is thus more difficult.

It would be just as easy on Linux modern distros which use UTF8.

I think we should rely on API calls rather than environment variables though.

The existing code does need cleaning up, though.

At this point I think we need to move to discuss-gnustep and thread...
we're moving away from the bug itself


Regards,
Sheldon