Re: NSFileManager fileSystemRepresentationWithPath: problem starting up Win32 libgnustep-back.bundle

[Richard Frith-Macdonald]

On 2005-07-08 07:33:33 +0100 Leigh Smith <address@hidden> wrote:

> Compiling and installing GNUstep on a WinXP SP2 machine works pretty  well, 
> command line tools compile and run without problems.
>
> In the past applications have built and at least run. On the most  recent 
> (CVS head) version, my app dies attempting to load the bundle:
>
> 2005-07-07 09:15:25.000 AppComms.exe[3900] Disallowed time zone name  `W. 
> Australia Standard Time'.
> 2005-07-07 09:15:25.000 AppComms.exe[3900] Using time zone with  absolute 
> offset 0.
> 2005-07-07 09:15:25.000 AppComms.exe[3900] NSApplication.m:217   Assertion 
> failed in initialize_gnustep_backend.  Can't load object  file from backend 
> at path c:/GNUstep/System/Library/Bundles/ libgnustep-back.bundle
> Error (objc-load):126
> c:\msys\1.0\home\leigh\Sources\FTDITest\ThummerComms.app \ThummerComms.exe: 
> Uncaught exception  NSInternalInconsistencyException, reason: 
> NSApplication.m:217   Assertion failed in initialize_gnustep_backend.  
> Can't 
> load object  file from backend at path c:/GNUstep/System/Library/Bundles/ 
> libgnustep-back.bundle
>
> The bundle is indeed at this location.

I'm dubious about that ... there is a space in the path after the '.app' ... 
which is probably incorrect.  Perhaps that's the cause of your trouble?  
Also, there is a space in 'c:/GNUstep/System/Library/Bundles/ 
libgnustep-back.bundle'
Any idea where the spaces come from?

> Tracing further, the problem is in NSString -fileSystemRepresentation  
> which 
> calls NSFileManager -fileSystemRepresentationWithPath: which is  returning 
> the string prior to ":", therefore "c:/GNUstep/System/ 
> Library/Bundles/libgnustep-back.bundle" returns "c".
>
> NSFileManager -fileSystemRepresentationWithPath: uses NSString 
> cStringUsingEncoding: NSUnicodeStringEncoding if the class is  compiled 
> with 
> __MINGW__.
>
> What is the current policy? Should NSApplication 
> initialize_gnustep_backend() be attempting to load "c:/GNUstep"  rather 
> than 
> "/c/GNUstep",

Yes.

> or should cStringUsingEncoding: properly  handle DOS drive 
> separators?

I'm not sure what you mean by that ... it should definitely not do anything 
special with DOS drive separators.  All that method does is provide a 
pointer to a region of memory containing a representation of the string in 
the specified character encoding.

> I would think the latter, but I'm not  clear on what the policy 
> of managing DOS pathnames is within the  GNUstep community?

This has changed ... current policy is to handle paths in either unix or 
windows format internally, and to expect the interface to the outside world 
to use native format paths (ie not to perform translations).