Re: Installation on windows (fwd)

[Richard Frith-Macdonald]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005-03-16 06:06:11 +0000 Sheldon Gill <address@hidden> wrote:

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

Perhaps starting with reporting individual bugs would make sense ... since
they generally only get fixed if people know about them, and a problem
broken down into individual parts is much easier to deal with.

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

I see support for unicode filesystem as a strong wishlist item... it's not
part of OpenStep, but I feel we should add it since my guess is that the
windows implementation of the the posix functions used in a lot of places
does not handle it.

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

I'm not sure what you mean above ...

If you simply mean that we should use win32 api calls directly (eg
CreateFile() rather than creat()), then I think that's uncontroversial and
is the direction we are moving in for the sake of performance and
aesthetics.
One thing that bugs me about current code is that, because it was written by
a variety of unix people, it uses fopen(), fread() fclose() etc in a lot of
places where it should realy be using NSFileHandle/NSFileManager to
encapsulate system dependencies.  Thats' not to say that the existing code
is buggy in any way, just that it's less easily maintainable/portable than
it might be.

> 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

I think on this point you are asking to break GNUsteps OpenStep/MacOSX
compatibility and ignore the userbase of  programmers wishing to write
portable code.

OpenStep was designed for/from a unix worldview and has an API reflecting
this.

As such it's my opinion that failing to transform strings (for instance to
use '/' as the path separator internally) would break things and would force
users (by which I mean people writing applications) to write more code with
larger overheads because they would end up writing code to allow for
differences in path semantics at the application level rather than the
library level.

So, while it would indeed be 'safe, sane, future compatible, least code,
smallest overheads' internally withing the base library, it would be the
exact opposite for users of the library who would have to write more code to
make their apps portable between unix/windows, would have to understand the
assumptions of both filesystems, and would need to know about new
filesystems in future... this is not the sort of programming environment we
want to provide.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using the GPG bundle for GNUMail

iD8DBQFCN91sE6AJp3nmKIkRAh+bAJ4yll37mcc3e+BTPXLGSnE5NoYzrACg1Jy4
Ux/X3+ID8NdT8IS1af3T9pk=
=zm2J
-----END PGP SIGNATURE-----