fileSystemRepresentationWithPath:

[Leigh Smith]

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

I rechecked the error message and the space seems to have been  
inserted by my mail client.

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

Digging deeper, the problem reduces to that NSFileManager - 
fileSystemRepresentationWithPath: is defined to return a unicode  
encoded const char * string, whereas NSBundle -load NSDebugFLLog()  
statements are assuming the string returned from  
fileSystemRepresentationWithPath: is an 8 bit char *, not unicode.  
The __objc_dynamic_link() definition in win32-load.h calls  
LoadLibraryExW() which assumes (casts) it's filename parameter is  
unichar *.

The problem seems to be that the string returned by  
fileSystemRepresentationWithPath: does not have the leading '\0' for  
latin unicode, but subsequent characters do have the leading '\0'  
hence the 'c' alone being displayed by the NSBundle debugging code  
(which prints using %s).

I'm almost certain there should be a leading '\0' in the unicode  
string returned by fileSystemRepresentationWithPath:?

NSString -dataUsingEncoding:allowLossyConversion: has the following  
code:

  else if (encoding == NSUnicodeStringEncoding)
    {
      unichar    *buff;

      buff = (unichar*)NSZoneMalloc(NSDefaultMallocZone(),
    sizeof(unichar)*(len+1));
      buff[0] = byteOrderMark;
      [self getCharacters: &buff[1] range: ((NSRange){0, len})];
      return [NSDataClass dataWithBytesNoCopy: buff
                    length: sizeof(unichar)*(len+1)];
    }

Adding

      if (objc_load_module([object fileSystemRepresentation],
               stderr, _bundle_load_callback, NULL, NULL))
    {
const char *fsrp = [object fileSystemRepresentation];
NSLog(@"LMS Couldn't load module %0x, %0x, %0x, %0x\n", fsrp[0], fsrp 
[1], fsrp[2], fsrp[3]);
      _codeLoaded = NO;
      DESTROY(_loadingFrameworks);
      DESTROY(_currentFrameworkName);
      [load_lock unlock];
      return NO;
    }

to NSBundle -load when run with:

openapp ThummerComms.app --GNU-Debug=NSBundle

produces:

2005-07-08 10:51:56.000 ThummerComms.exe[528] Disallowed time zone  
name `W. Australia Standard Time'.
2005-07-08 10:51:56.000 ThummerComms.exe[528] Using time zone with  
absolute offset 0.
2005-07-08 10:51:56.000 ThummerComms.exe[528] File NSBundle.m: 823.  
In [NSBundle +mainBundle] Found main in c:/msys/1.0/home/leigh/ 
Sources/FTDITest/ThummerComms.app
2005-07-08 10:51:56.000 ThummerComms.exe[528] LMS self executablePath  
result = c:/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./ 
libgnustep-back.dll
2005-07-08 10:51:56.000 ThummerComms.exe[528] File objc-load.m: 110.  
In objc_initialize_loading Debug (objc-load): initializing dynamic  
loader for c
2005-07-08 10:51:56.000 ThummerComms.exe[528] File objc-load.m: 174.  
In objc_load_module Debug (objc-load): Linking file c
2005-07-08 10:51:56.000 ThummerComms.exe[528] LMS Couldn't load  
module 63, 0, 3a, 0
2005-07-08 10:51:56.000 ThummerComms.exe[528] 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

My point being the lack of byteOrderMark, or a leading '\0' in the  
string, unless there is strange behaviour treating unichar * strings  
and casting them back to char *.

I'll dig in further.

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

Ok, thanks for the clarification.
--
Leigh M. Smith
address@hidden
http://www.leighsmith.com