gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Installation on windows (fwd)


From: Sheldon Gill
Subject: Re: Installation on windows (fwd)
Date: Wed, 16 Mar 2005 14:06:11 +0800
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]