Ross,

> However, there is also a file 
> win32/plugins/FilePlugin/sqWin32FilePrims.c 
> that defines the basic file operations using Win32 calls like 
> SetFilePointer.  These calls can potentially do 64 bit 
> access, although they do so in an awkward way (you pass in the
> low and high bits separately) and the upper bits are not currently
> used.  Further, some Win32 systems (e.g. Win95) do not support 64 bit
> addressing.  I see no note of OS limits 
> on _telli64 and friends, but they may have the same problem.

They do have exactly the same problems. See below.

> I do not know what the performance implications are of 64 bit 
> vs 32 bit file access, nor of using the Win32 specific calls vs
> the generic seek/tell, but there probably are some.  Because of the
> possible performance hit from 64 bit access, and because of OS 
> limitations, it may be desirable to generate VMs with and without
> this option.
> 
> Comments?

Yes a few. First of all, the C runtime library functions (fseek, ftell
etc) are implemented by calling the Windows functions (SetFilePointer
etc). Look at the CRTL sources to find out. So whatever you see - the
windows functions are the ultimate documentation on the limits of any
access. Performance differences of 32 vs. 64 bit operations don't matter
whatsoever; if you don't need 64bit (which is trivial to check for in
the support code) you can just pass in the appropriate NULL pointer to
e.g., SetFilePointer. This will give you exact 32bit behavior. If you
need 64bit then you'll have to deal with the consequences anyways. So I
don't see any point whatsoever in generating VMs "with or without" that
options. The overhead is almost exactly zero.

Cheers,
  - Andreas