Noel,
The image reading code changes to handle the header differently, as does the image writing code, and we don't actually have to do the block read/write. Otherwise, I was thinking that the same behaviors would be performed.
How does that sound to you?
I don't think you need to handle the header differently - after all we can make sqImageFileWrite just a stub that writes to the appropriate memory location if the source of the data is outside of the file region :-)
On Windows CE, when you call CreateFileMapping for a size greater than the size of the file, the file is expanded to the full size of the requested space; an error is returned if there is insufficient room.
Sounds reasonable.
This is done to ensure the available of the backing store. I was planning to call SetEndOfFile to truncate the space after closing the file.
Well, why not keep the file at the full size?! It would make certain you do have appropriate space for whatever you want to do (it would be pretty cool to have a 32MB flash card that has nothing but a live Squeak image on it :-) and all it would require for image reading are some slight modifications that actually look at the header of the file for determining the data size.
Cheers, - Andreas
The image reading code changes to handle the header differently, as does the image writing code, and we don't actually have to do the block read/write. Otherwise, I was thinking that the same behaviors would be performed.
How does that sound to you?
I don't think you need to handle the header differently - after all we can make sqImageFileWrite just a stub that writes to the appropriate memory location if the source of the data is outside of the file region :-)
What I meant by differently is that we'd fill in the header fields directly, rather than do all of the put/getLong-type calls.
I do wish, as I go through the code, that the image file were encapsulated, with accessor/mutator methods for the contents, rather than having to find in-line put/getLong-type statements. ;-)
I was planning to call SetEndOfFile to truncate the space after closing
the file.
Well, why not keep the file at the full size?!
I was just trying to be polite with people's CF memory, and also because on the internal store, I wouldn't want to take up excess space that could be shared with other apps. I suppose the truncate can be configured as optional.
[All] it would require for image reading are some slight modifications that actually look at the header of the file for determining the data
size.
I did notice that the datasize header entry tends to be somewhat ignored in at least some versions of the code. :-)
Speaking of source changes, what is the correct procedure for affecting changes on the VM? I am perfectly content to modify the C code I downloaded from Ohshima-san's web site, but I have this vague notion that somehow the code is supposed to be present in the Smalltalk image, and then generated. But the Smalltalk image seems to primarily have Mac code, and generic.
I had asked the question earlier. Bert Freudenberg replied that, "IMHO (which conflicts with the official opinion) the platform-specific support files should not be included in the image. It's only there for historic reasons when the Mac was the only platform, so you could actually have all the sources in one place."
--- Noel
squeak-dev@lists.squeakfoundation.org