[Top][All Lists]

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

Re: Installation on windows (fwd)

From: David Ayers
Subject: Re: Installation on windows (fwd)
Date: Wed, 16 Mar 2005 17:30:24 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217

Richard Frith-Macdonald wrote:

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


reply via email to

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