On Wed, Jan 20, 2010 at 11:20:42PM -0800, John M McIntosh wrote:
>
> I'm sure David passed a note by my email a week back about the logic to read the header wasn't quite right and some problem with extraVMMemory.
> So I've noticed that
> foo->fullScreenFlag = getLongFromFileswap(f, swapBytes);
> returns 1 on a 64bit image.
>
> Is this mmm true or am I mistaken in what's in that slot?
There is a problem, but I don't think that it will affect the fullScreenFlag.
I entered a Mantis issue to describe the issue(s):
http://bugs.squeak.org/view.php?id=7455To illustrate what is happening, here is a dump of the image header
from a freshly traced 64-bit image as produced by SystemTracer64
(using unix command "od -c myImage64.image | less"). The file header
is at addresses 0 through 127 (up to but not including octal
8r0000200). The fullScreenFlag and the extraVmMemory fields are
both zero:
0000000 240 \t 001 \0 \0 \0 \0 \0 200 \0 \0 \0 \0 \0 \0 \0
0000020 0 s " 002 \0 \0 \0 \0 200 \0 \0 \0 \0 \0 \0 \0
0000040 ( 001 \0 \0 \0 \0 \0 \0 320 \r \0 \0 \0 \0 \0 \0
0000060 x 002 8 004 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000200 1 036 \0 \0 \0 \0 \0 \0 \t \0 \f 027 \0 \0 \0 \0
0000220 231 036 \0 \0 \0 \0 \0 \0 \t \0 240 030 \0 \0 \0 \0
And here is the file header after saving. Header size was changed to
64 and image data begins at 8r0000200, overwriting the value of the
extraVmMemory field. In this example, the fullScreenFlag field is
still zero (eight bytes of zero), so it is not affected by the file
header size problem.
0000000 240 \t 001 \0 \0 \0 \0 \0 @ \0 \0 \0 \0 \0 \0 \0
0000020 H 364 033 002 \0 \0 \0 \0 \0 0 371 267 206 + \0 \0
0000040 250 0 371 267 206 + \0 \0 017 m \0 \0 \0 \0 \0 \0
0000060 x 002 8 004 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000100 271 L 371 267 206 + \0 \0 \t \0 \f 027 \0 \0 \0 \0
0000120 ! M 371 267 206 + \0 \0 \t \0 240 030 \0 \0 \0 \0
0000140 9 0 371 267 206 + \0 \0 \t \0 \0 036 \0 \0 \0 \0
0000160 211 M 371 267 206 + \0 \0 a 001 \f 036 \0 \0 \0 \0
0000200 310 M 371 267 206 + \0 \0 210 303 362 271 206 + \0 \0
0000220 005 \0 \0 \0 \0 \0 \0 \0 ( 0 371 267 206 + \0 \0
If you are getting fullScreenFlag == 1 when it should be 0, then it's
a bug but not the same issue that I am seeing. Take a look at the
image file header for the 64-bit image that you are loading, and see
what it actually contains at positions 55 through 63, that should give
a clue as to what's going on. I don't expect that it would be a bug in
in #getLongFromFile:swap: because you would not be able to load the
image at all if this method did not work.
By the way, my opinion is that the file header for a 64 bit image should
be 64 bytes in length with values stored as 32-bit integers, rather
than 128 byte in length with values stored as 64-bit integers. But
this presents a backward compatibility problem for reading existing
64-bit images, and I have not tried to solve this (yet).
Dave
Locked
