JC> The question isn't what the user's code looks like, but how fread is
 JC> implemented.  If you're using a full-blown protected OS like Windows NT
 JC> or Linux, this happens fairly directly.  However, if you're using a DOS
 JC> extender, the read has to be done into DOS memory (in the first meg.)
 JC> then copied from there to your buffer.
You mean that WinNT and Linux don't do their own buffering internally?  No 
read caches?  No write caches?
Somehow, Jerry, I doubt this.  That would make for terribly inefficient hard 
drive access.  While we all know NT is a hog (and slow without huge 
horsepower), I believe it is for other design reasons, not for its disk 
access (which seems reasonably quick... at least under NTFS).
 JC> OS/2 falls about halfway between these two: it uses 16 bit protected
 JC> mode code for most device drivers, so device drivers can only address
 JC> the bottom 16 meg of RAM.  If you do a read into the bottom 16 meg of
Since the cache is a device driver, and allocates its cache in the lower 16 
meg of RAM, it's not an issue - double buffering is forced because of the 
cache.  OS/2's 16-bit drivers are there because there is no benefit to 32-bit 
drivers ... this double-buffering must take place anyway for performance 
reasons.
--- Maximus/2 3.01
---------------