Re: Installation on windows (fwd)

[Sheldon Gill]

Richard Frith-Macdonald wrote:
> -----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.

Sure. I've not done much testing with the latest revisions. If I have a 
test case to provide demonstrating a bug, I'll do so.

In the interim, a review of the code has suggested a number of possible 
bug scenarios. I will get to them...

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

I disagree that Unicode to the file system isn't part of OpenStep. 
Mostly, the OSAPI uses NSStrings passed to NSFileManager or 
NSFileHandle. It is Unicode clean as far as possible.

There is even a specific method to transform from an NSString to a path 
string which the OS system routines can handle to provide compatibility 
between the OpenStep fully unicode API and the underlying OS requirements.

There are string methods to help manipulating strings which represent 
paths and many of them are rather POSIX focused but that is a different 
thing. Mostly they don't care path separator etc and are done in a 
sufficiently abstract way so it doesn't matter.

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

Then we are in complete agreement about this. Excellent!

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

Again, we are in complete agreement. In fact, I'd already done work in 
this regard but there wasn't any point in submitting it as it followed 
on from previous work on NSPathUtilities, NSFileManager and the Win32 
support routines.

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

Umm.. no. I really don't want to break compatibility. In fact, I want to 
enhance it and make it easier. That doesn't mean, though, that I 
advocate doing everything to try and support existing code as written 
where it makes sense to have a better approach.

I'd actually say that the current changes do more to break compatibility 
in porting code than my goal to do things cleanly "under the hood".

The current situation forces localToOpenStep and openStepToLocal. These 
are extensions to the API and complicate things. In my view, they are 
unnecessary. We can do better without them.

Under MacOS-X, *nix and even YellowBox I could:
  * get an NSString from an environment variable via NSProcessInfo
  * Use that string as a path to NSFileManager

under gnustep-CVS I have to add an intermediate step:
  * get an NSString from an environment variable via NSProcessInfo
  * openStepToLocal the string
  * Use that string as a path to NSFileManager and friends

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

Don't you mean "...use '\' as the path separator..."?

If you consider my example above the current CVS solution adds code and 
semantic complexity at the application level. Precisely what you are 
advocating shouldn't happen.

In the common situation that I get a path string from a user or other 
external input source (like a file with references) all gnustep 
compatible portable code has to call localToOpen and vice versa. That is 
adding complexity and code at the application level. We don't need to do 
it and I suggest we don't.

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

A certain level of knowledge about the assumptions and layout of both 
filesystems is, IMHO, unavoidable. We can, though, provide a good way of 
dealing with the differences and moving from one to another with minimal 
impact.

By way of example, under *nix it'd be perfectly acceptable for my 
application to create a document using NSHomeDirectory(). The preferred 
place under Windows is "My Documents". Extensions to NSSearchPath() will 
help us cope with this sort of situation but the underlying semantic 
variations remain.

In many cases the code can be written cleanly portable. Some cases will 
require knowing which OS you're on and behaving accordingly.

Developers need to be aware when porting. We can only achieve partial OS 
isolation. We can try to reduce the pain and provide nice docs to help 
people along, though.


Regards,
Sheldon