Re: Installation on windows (fwd)

[Richard Frith-Macdonald]

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

On 2005-03-16 08:13:42 +0000 Sheldon Gill <address@hidden> wrote:

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

Hmm ... While I guess I can see why you might think that, I don't really see
that as anything to do with the filesystem. OpenStep uses NSString objects
internally, so inevitably the API to those classes passes NSString objects
... to me that implies nothing about the underlying filesystem support.
Plainly having a unicode filesystem is a good thing, and I feel that support
for unicode filesystems is a natural extension, but the support of unicode
strings doesn't mean that unicode filesystems were supported.

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

Specifically, that converts FROM and NSString (which may be thought of as
unicode. even if it is oftern stored as 8byte characters) TO an 8-bit per
character filesystem representation.  This says that the internal format may
be 16bit unicode, but the external one isn't ... OpenStep anticipates that
the filesystem will be using CStrings rather than unicode.

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

Yes ... I think we should try to keep things as abstract as possible and
OpenStep goes a long way towards this.

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

I'm not really happy with them ... but I'm not sure there is a better
approach, and they seem to make things simpler than any alternative.  A more
efficient api might take 16bit character strings directly ... but then what
about 32bit unicode strings etc etc.
This API may require two stages (one to convert between external data format
and NSString,  and one to convert between external path format and internal
path format), but it keeps additional methods to a minimum given that the

> 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

I believe that's also the case in GNUstep (unless recently broken).  The
interesting question is to what extent path manipulation can be performed on
such a string rather than whether it can be used literally.  In GNUstep
that's minimal.
However, while it way work, I've not seen it recommended anywhere..

> under gnustep-CVS I have to add an intermediate step:
>    * get an NSString from an environment variable via NSProcessInfo
>    * openStepToLocal the string

You mean openStepPathFromLocal: ?

>    * 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..."?

Yes, sorry.

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

Not really ...

1. You are picking a special (though not unusual) case and you have to
consider what the overall behavior is.
2. GNUstep is providing a helper method to make it easier, rather than
leaving the app write to code their own.

OPENSTEP/MacOS-x say you should use
- -stringWithFileSystemRepresentation:length: and
- -fileSystemRepresentationWithPath: when importing/exporting strings which
are expected to be paths.

I think the MacOS-X/OPENSTEP way would be to call
path = [fileManager stringWithFileSystemRepresentation: [path cString]
length: [path cStringLength]];
to convert a string from the environment into a path.
Certainly the documentation says these methods are to convert to/from
CStrings used by native system calls, and if the paths were held internally
by openstep in the same format as the external paths, then you could just
use -cString and +stringWithCString: to perform such conversions.

These methods do not work on windows with unicode filesystems ... as the
designers of  OPENSTEP  didn't anticipate unicode filesystems arriving
on windows and needing a whole new API working with 16bit characters rather
than CStrings.  That's really the only reason that -openStepPathFromLocal:
and -localFromOpenStepPath: were introduced.

Normally, when interacting with users, I think the expectation is that paths
will be selected by browsing the filesystem etc, so the open/save pannel
returns a valid path string already in internal format.  This means that
conversions between internal and external format paths outside the base
library are rarely necessary.

Using a standardised format internally means that an application can
effectively manipulate paths for multiple filesystems on multiple machines
and can do so in a consistent manner.

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

I didn't mean to imply that we could avoid having to know about filesystems,
just that the extent of such knowledge (and certainly the impact on
application code) should be minimised.

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

And the preferred place under MacOS-X is 'Documents' (and I guess other
conventions exist within other environment such as gnome or kde).
Do you mean extending NSSearchPathForDirectoriesInDomains() to add something
to return the preferred directory for storing documents (rather than
resource files etc) on the current system, then encouraging developers to
use it for all documents?
That sounds a reasonable idea.  Though I don't like using that API myself
... I think Apple would have done better to make it an NSFileManager method
instead ... so people could alter behavior in subclasses or categories.
Generally I don't approve of functions in the public API except for really
low level operations where extreme performance is critical.

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

Yes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using the GPG bundle for GNUMail

iD8DBQFCOAohE6AJp3nmKIkRAsSGAJkBbMT0zkhY9cawXmb5GR1CiI1PJACgo6un
uA7sRby6qbPfJt2lAdvIE6A=
=avAR
-----END PGP SIGNATURE-----