Re: Installation on windows (fwd)

[David Ayers]

Richard Frith-Macdonald wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2005-03-16 15:28:25 +0000 David Ayers <address@hidden> wrote:
>
> > The first paragraph was talking about the implicit conversion that 
> > OPENSTEP for NT does.  It would allow things like:
> >
> >    [@"test" writeToFile: @"C:\\Temp/test.txt" atomically: YES];
> >    s = [NSString stringWithContentsOfFile: @"C:/Temp\\test.txt"];
> >
> > I don't know whether we currently also support this on 
> > cygwin/msys/mingw but this has lead to real confusion and down right 
> > problems with some versions of OPENSTEP (or WebObjects) that didn't 
> > always handle it correctly.
>
>
> We don't support it ... but I think the examples you provide would work.
> The reason being ... we expect paths to be in posix format internally and
> convert to windows native format at the point when we do a file operation.
> In both cases, those strings look like relative posix path names containing
> a single separator ...
> so 'C:\Temp/test.txt' would get the '/' converted to '\' and end up as
> 'C:\Temp\test.txt' in the windows native format, and 'C:/Temp\text.txt'
> would similarly end up as 'C:\Temp\text.txt' at the point where it is 
> passed
> to the windows system call to write or read the file.
> However, -lastPathComponent would return 'test.txt' for the first string 
> and
> 'Temp\test.txt' for the second string as these are assumed to be posix
> paths.
> Perhaps OPENSTEP did the same thing?

Interesting!  Maybe that was the case at some point, but the version I 
currently have actually returns test.txt in both cases.

> NSFileManager (from OPENSTEP) has conversion to/from C-string path
> representations on the local filesystem
>
> New GNUstep specific additions are localFromOpenStepPath: and
> openStepPathFromLocal: whee the 'OpenStep' representation is the
> posix/internal representation, and the 'Local' representation is windows 
> (if
> you are running on windows) ... they do nothing if you are running on 
> unix..

Yes, I remember looking at those, but the cString is of course in the 
current C encoding and you also need an file manager instance which was 
very unfortunate because you jump a lot of hoops to convert.  Also there 
were cases where the system evaluating the Windows path, may know that 
the string originated from a windows system's environment variable (or a 
file which wrote it in the windows format) but wasn't itself a windows 
system so no conversion could be done.  We ended up writing NSString 
categories.  I don't think it's terribly vital to have such categories 
in -baseadd as they are easily written, but they seem generally useful.

Cheers,
David