Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]

[Sheldon Gill]

> > I'm working on string methods now as part of my path & win32 effort, if 
> > anyone is interested.
>
> I'd be interested in knowing what exactly .... as I have a load of 
> uncommitted windows path changes on my system (I was waiting for 
> feedback on the last tranch of changes), and I'm also occasionally 
> updating bits and pieces to match MacOS-X API.

Hmm...

In no particular order and off the top of my head:

* NSHomeDirectoryForUser() now finds other users on Win32

* Additional directory keys for NSSearchPath() including
  all the new Tiger keys.

* GSSearchPath() for porting/compatibility

* New implemenation of SearchPathForDirectories; O(1)
    Very much faster and more readily extensible

* Paths from registry in Win32 for mingw32 native

* standardised, improved way to determine win32 IsExecutableFile

* hide/show extensions on win32 in sync with Explorer

* Flexibilty improvements in FS layout for platform-specific packaging
  Better PLATFORM_SUPPORT. {stuff I was mentioning to Helge}

* Some string methods do better argument checking and/or raise an
  exception when invalid/nil

* Documentation for all this and more

Still progressing

* Path handling fixes in the rest of base and gui: where we have
  assumptions about layout which are no longer valid or where
  the code can be cleaned up

* More and better use of Unicode and Win32 api. We should be
  using either Step or native methods as far as possible to
  improve behaviour. This will be ongoing for a while...

* Framework support on win32. With my _find_framework() in NSBundle we
  can now properly locate the framework directory and so know exactly
  where the DLL is. We can load it explicitly when needed.
  Its a case now of linking and symbol resolution.
  A ways off (because of time)

* Remove PathHandling mode

I'm quite concerned about PathHandling mode and want to remove it. I
don't think it's necessary and adds more confusion and complexity.

Currently, it's a global variable. The mode could be changed by a
loadable bundle without the application code being aware of it.
Hence, code can be expecting to run in one mode and be invoked when it's
different.
Further, it could be changed in one thread and mess up the processing in
a different thread which happens to be executing at that time.

Under this scheme, to write safe code you need to

1 check what the current mode is and remember it
2 set it to what you expect
3 process
4 set it back to what it was so you don't confuse other things
5 pray no other thread is changes mode under you

I understand the concerns which lead to implementing the mode but I
really think it isn't needed and adds more complexity than it solves.

* review and recommendations for NSString & NSFileManager

I've argued that we don't need Local<->OpenStep conversion generally
We also don't need the special ~drive and address@hidden notations. For
starters, though I find it bizarre I have come across accounts with user
name eg 'a'. Anyway, we don't need the ~ encodings.

I'm working on demonstration code to remove these by defining clear path
handling semantics which are appropriate for *nix and for win32 without
confusing either.

Current behaviour can be apparently inconsistent and confusing:

Path string for test is /./Development
Standardised      '/./Development'
FileSystem rep    '\.\Development'
OSFromLocal gives '/./Development'

Path string for test is F:/./Development
Standardised      'F:/./Development'
FileSystem rep    'F:\.\Development'
OSFromLocal gives '~F//./Development'

Path string for test is F:\.\Development
Standardised      'F:/./Development'
FileSystem rep    'F:\.\Development'
OSFromLocal gives '~F/Development'

Path string for test is F:\\.\Development
Standardised      'F://Development'
FileSystem rep    'F:\\Development'
OSFromLocal gives '~F/Development'

Path string for test is F://./Development
Standardised      'F://Development'
FileSystem rep    'F:\\Development'
OSFromLocal gives '~F///./Development'

* string optimisations for the Win32 API where buffers are used
extensively. Initial testing suggests significant savings are possible 
but I want to investigate further.


I'm sorry if this was a little terse but I'm pressed for time right now. 
Off to see clients...



Regards,
Sheldon