On Mon, Oct 01, 2012 at 04:56:39PM +0200, Sven Van Caekenberghe wrote: > > On 01 Oct 2012, at 16:33, Henrik Sperre Johansen > <[email protected]> wrote: > > > On 01.10.2012 14:43, Sven Van Caekenberghe wrote: > >> On 01 Oct 2012, at 14:01, Henrik Sperre Johansen > >> <[email protected]> wrote: > >> > >>> Endianness in header depends on the platform the image was saved on. > >>> Which for all practical purposes, means little-endian these days. > >> How can an image be cross-platform, but the header not ? > >> > > IIRC, because the VM checks which endianness the header is written in (by > > comparing to known image formats in big and little-endian format), and then > > triggering a swap of all pointers/variableWord objects when loading the > > image on a differing platform. > > Thanks for the answer, I suspected something like that. > > But that means that the image format on disk, being binary, is native only to > one endianess and not the other, making startup or saving a image > faster/slower depending on whether the conversion needs to be done, right ? > Or is this automagically fixed with the first save ? > >
Normally the conversion does not need to be done, because the common use case is for starting an image on the same (or similar) platform. That means that in the common case, object memory can be directly loaded without word swapping, which is a bit performance win when loading the image. Of course the header part of the file is different from the object memory itself, so Igor is correct: The real reason it got done that way is ... that's how it got done ;) Dave
