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.