Re: Installation on windows (fwd)

[Sheldon Gill]

Richard Frith-Macdonald wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2005-03-14 19:43:01 +0000 Alex Perez <address@hidden> 
> wrote:
>
> > Nicola Pero wrote:
> >
> > >
> here are currently issues with the path handling
>
> > > > which causes certain things to only work inside the msys 
> > > > environment. If you remove it before those issues are fixed, you 
> > > > will introduce more problems.
> > >
> > >
> > >
> > > Thanks -- ... there might be some confusion ? ;-) ... we are talking of
> > > the msys developer toolkit (ie, additional developer tools), not of msys
> > > (the base development environment).
> > >
> > > Anyway.  Which issues ?  Which path handling ? :-)
> >
> >
> > Unicode path handling under win32 is basically completely broken. I am 
> > not privy to the details, but all I can say for sure is that I believe 
> > it manifests itself as a problem when you launch a gpbs or gdnc (which 
> > are both true GNUstep tools, unlike gdomap, which AFAIR is a C app) 
> > from a path with a space in it, it fails miserably. This should not 
> > happen. Windows is riddled with paths with spaces, and they must be 
> > properly supported. I understand the inherent limitations of GNU Make 
> > and GNUstep-make and spaces, but this is not what I am referring to. 
> > GNUstep apps at runtime should have 100% support for being launched in 
> > a directory with spaces, as well as opening files up in directories 
> > with spaces. The current installer "works around" this problem by 
> > installing GNUstep to c:\GNUstep, which is in violation of the Windows 
> > FSH, but it's the only solution that currently works without fixing 
> > the problem with win32 path handling properly and completely.
>
>
> To the best of my knowledge, the problem with launching apps in paths
> containing a space was fixed about a month ago, and was due to a
> bug/feature of the way that windows deals with the arguments when 
> spawning a
> subprocess ... it had nothing to do with unicode string handling.
> Certainly, I can run gdnc from directories whose names contain spaces.
> Also, I have never heard of gnustep having any problem opening files whose
> names contain spaces.  Which is not to say that there can't be problems
> where application programmers parse strings assuming that spaces are being
> used as filename separators.
> Anyway, there are no outstanding unfixed bug reports on the issue of spaces
> in the base library, and no windows specific bug reports for unicode
> problems that I can remember at all.
>
> > > Let's fix them if we have any.
> >
> >
> > Sheldon Gill knows probably better than anyone else what needs to be 
> > done to resolve this. I suggest you send him an e-mail, since I don't 
> > think he's subscribed to this list currently. I've been discussing 
> > various aspects of win32 gnustep issues with him privately recently, 
> > and he knows far more about it than I'd ever care to know :) You can 
> > contact him at address@hidden , or if he is lurking on the 
> > list reading this, I'd like to encourage him to come out of his hole 
> > and speak to this :)

*Emerges from hole*

Hmm... FYI my involvement has been interrupted by RL and my Wallstreet 
not booting. Also other unspeakable things on the doze box.

By the way, the spaces in paths isn't really the issue we were discussing.

> It's definitely worth checking with Sheldon in case he knows of any bugs he
> hasn't bothered to report ... though my impression was that most of his
> problems were wishes that things would work more 'naturally' in a windows
> environment rather than bugs as such, and I think most/all of the ideas
> discussed with him have been applied by Adam recently.

Ahhem! ...bothered... ?!!

I've a range of "problems" regarding GNUstep in respect to the file 
system, some of which are wishes for better behaviour but some are 
certainly what I'd categorize as bugs. These "wishes" aren't restricted 
to the windows environment either.

Some of the ideas discussed have begun to be implemented in stages. I 
wouldn't call it most and definitely not all.

At the path handling on windows, essentially the issues arise because

OpenStep -> POSIX -> (emulation) -> Win32

is the current layering and that introduces all sorts of issues as we
move from layer to layer. The "impedance mismatch" gets compounded and
we add both overhead and complexity in the process.

Unicode compounds the issues. Especially as there are Unicode issues
with mingw and msys. I'm not sure what exactly has been fixed for the 
latest release but definitely are there for earlier ones.

Internally, the current -core code has some parts working with unicode 
strings for the file system while other parts don't.

After quite some investigation I believe the best way is to go

OpenStep -> Win32

as far as possible. This means that all things should be in
UTF-16 and left untransformed as far as possible and reasonable.

The only transformation which should be done is variable expansion on
paths read from the environment/registry so that absolute paths are used
internally in their native form.

This is the safe, sane and future compatible way to go. Least harm,
smallest set of assumptions. Leads to least code and smallest overhead.

This does lead to some issues with the path handling NSString methods
which need to be considered but they aren't show stoppers. There really 
just needs to be some consideration and handling of the non-POSIX Win32 
case where:
  "\" is the separator
  "/" isn't the FS root
  symlinks don't exist
  "~" is meaningless

That is essence is my position on Unicode & The File System.

Regards,
Sheldon