[VM] Build report and queries (Unix and Win32)
Ross Boylan
RossBoylan at stanfordalumni.org
Wed Feb 20 09:22:49 UTC 2002
I've had some success build a 3.2gamma VM for Win32 using MSVC, but have
two questions before my report:
1. What's up with the 512 byte header on Unix? The code I wrote to deal
with it was in routines that did checking, but not the main routine that
actually reads and understands the image. This makes me a bit
nervous. The main code looks as if it automatically seeks 512 bytes
forward if it runs into trouble, and I guess the file is read from this
offset. Is that really all there is to it? Obviously a messup on this
could be catastrophic.
The unix code redefines sqImageFileStartLocation and claims this is
automatically used. But the only caller I found (in interp.c) uses it when
writing, not reading. This is just as well, since it's hard coded to 512,
while on Unix some files have the extra header and some don't. All this
left me with an uneasy feeling.
2. I can now build an exe and start it, even for an image with the 512 byte
header. But the bottom of the image shows a fairly large white box,
perhaps 60 pixels high (clearly taller than the tabs that are usually
there) and the width of the window. If I popup a menu above it, it seems
to obscure the part of the menu that goes below this. It looks as if
messages might flash by very quickly in this area. Ahh... I see this in
the debug build, but not the release build. Is this a bug or a
feature? What is it?
What I've done:
* Modified a bunch of source files, including renaming AsynchPlugin so it's
recognized.
* Not attempted to compile the MPEG3 plugin, which seems to have some
special issues.
* Installed Andreas's DX7 material and pointed the build procedure at it.
* Toned down the use of 64 bit ints and seeks (i.e., there's still work to
do to make it right).
* Hacked Win32VMMaker heavily to support MSVC, by having it write the .dsp
file. As a result, many files are now referenced in place, rather than
copied. Because of this, the gcc makefile will no longer work; it probably
needs similar treatment. (By the way, the strategy for non-copy builds on
other platforms was not apparent to me--anything there I might want to
borrow?).
On the 64 bit front, it looks as if it may be possible to use __int64 for
offsets, and then reinterpret the bits for use in the funky calls that have
a separate low and high 32 bits. See the LARGE_INTEGER structure and the
SDK docs on SetFilePointer. They seem to imply that an __int64 can be
reinterpreted as a LARGE_INTEGER to pull out its two parts. Because of
issues of bit ordering and the sign bit, I had some doubts whether this
operation was safe. I guess windows is back to running on only one chip
family, which simplifies things.
More information about the Squeak-dev
mailing list
|