Additions:
See iPhone
Deletions:
TBD
Additions:
Has to be in platform encoding since it's used directly for platform IO routines
imageName is populated at image read time, if a partial path it's made absolute.
imageName is used to read the image file, it's populated at startup time. This is the reverse of other platforms where
a path is calculated to read the file, and later imageName is populated
No differences.
Additions:
HFS+ imposes
Unicode2.1 decomposed UTF-8 encoding on all path elements
Deletions:
HFS imposes Unicode2.1 decomposed UTF-8 encoding on all path elements
Additions:
HFS imposes Unicode2.1 decomposed UTF-8 encoding on all path elements
Deletions:
HFS+ imposes Unicode2.1 decomposed UTF-8 encoding on all path elements
imageName
This is a global variable, likely for Hydra it should be hung off the VM interpreter local storage.
From: Interpreter writeImageFileIO, and snapshot and writeImageFile (set mac file type)
Why:
Storage for the image file name that is used by writeImageFileIO, has to be in file system representation
Responsibility:
This is a bit messy since on the iPhone and OSX the imagePath is stored both as a URI and as a character string.
MacIntosh
os-9/OSXCarbon
Cocoa:
TBD
char *getImageName(void) populates imageName via
CFStringGetCString (imageNameString, target, IMAGE_NAME_SIZE, encoding); via
getImageNameWithEncoding(imageName,gCurrentVMEncoding);
where imageName is
HFS+ imposes Unicode2.1 decomposed UTF-8 encoding on all path elements
iPhone
uses imageNamePutLength to populate imageName as a result of findImageViaBundleOrPreferences
Unix
Windows
BUGS
how big is unclear and platform dependent.