Re: Installation on windows (fwd)

[Frederic Stark]

> Speak up, people.

We have a GNUstep app that run on both windows/mingw and unix.

Path handling have been a pain all the way. We had to patch the GNUstep 
library to get a correct behavior (this was a few years ago. With 
current versions of GNUstep, we don't have to patch anymore). We did not 
send bug reports/patches mostly because we never clearly understood how 
it was supposed to work.

We had directories containing backslashes on unix, inability to properly 
run installed across multiple drives and/or over UNC path on windows, 
you name it, we ran into it :-) (Add to that, the brain damaged concept 
of msys rewriting path in arguments/environment and the need to fork 
some native utilities with proper path, and you'll get some fun ahead)

We settled on using only / separated strings, and required the user to 
specify those this way (also because of the added fun of specifying a 
windows path in a property list file). This solved all (almost) of our 
path problems, but we basically put the burden of conversion onto the 
user. This is not a problem in our case, but will not be acceptable for 
the general public.

By far, the most important thing here is a clear definition of how it is 
 *supposed* to work under windows. In particular how a GNUstep 
developer/user should expect its path string to be in various cases:

* A binary launched from a msys shell that takes a path.
* A binary launched from a CMD.exe, that takes a path
* A windows service, with a path
* What kind of path an open dialog returns
* How a hard-coded path in the code should look.
* Is NSLog( @"%@", aPath ) the proper way to print a path ?
* How do I store a path in a property list file ?
* What should be done with a path retreived with Windows API
* Where does / points to ? Is it different if I change drive with some 
Win32 API ?
* Is /c/ supported ?
* Does ~ exists, and if yes, where it points to ?
* What should be done before calling fopen with a 'path string'
* What should be done before calling a windows API
etc, etc.

On the broader problem, there are, I think only two ways to deal with 
path in GNUstep:

* We keep everything as '/' internally (as I think it is done today). We 
put the burden on the developer to translate all the path to that 
format. It may be very difficult, because 1) such problem don't occur in 
unix, so code ported from there will ignore the problem 2) sometimes, it 
is hard to know that something is a path (argument to some command-line 
software).

* We keep everything 'native' internally. We render multi-platform 
software harder to write, and will have code with hard-coded '/' 
failing, which is strange, because even the C Library uses '/' under 
windows. All current code that uses '/' (or have stored such path in 
some configuration files) will suddently fail.

My 2 cents,

--fred