Last updated at 12:09 am UTC on 26 January 2020
The image, when stored to a file, is saved with a header section followed by a binary snapshot of the contents of the object memory. When loaded by a VM, the header section provides enough information for the VM to reload the snapshot, fixing up object pointer addresses and other details within the object memory as it is loaded, and preparing the VM to begin running the image at the point it was last saved.
As the virtual machine and object memory have evolved, different ImageFormat numbers have been assigned to identify the requirements of the image. The image format number is stored at the beginning of the image file header, allowing the VM to determine if a given image file is in a format the the VM understands. For example, an older interpreter VM that does not know how to run a newer Spur image will detect the "unknown" image format at the beginning of a Spur image file, and will issue an error message saying that it does not understand that image format.
For external references such as sockets and files that are managed by VM plugins, the external references simply point to things in the VM that are no longer valid, and the associated primitives will fail harmlessly. To the image, an invalid file reference will appear as a file that is closed.)
This image runs on top of a VM. The image is a platform-independent file. In other words, the exact same image file can run on a Windows/Mac/Unix/etc platform, as long as the appropriate virtual machine for the platform is used.
The image does not contain the source code for the system, however. The source code is stored in the .sources file and the .changes file.