On , Joe Dunford (1:342/1017@fidonet) wrote: 
 RS> While the basic answer here is correct, it doesn't mean you can't hide
 RS> the details from a calling program. For example, in SNIPPETS there is a
 RS> file called HUGEREAD.C which implements reading and writing of huge data
 RS> to/from either standard C or Posix streams. Implementing similar code in
 RS> C++ would be trivial.
 > I'm not sure that the basic answer is correct. I admit I've only glanced 
t
 > HUGEREAD.C but it seems to me that it is for shuffling around large blocks
 > of memory(overcoming the offset limit), and not for "reading" from a file.
Joe...
  A matter of semantics, I guess. The basic fact is that the hugeread(), 
hugewrite(), hugefread(), and hugefwrite() are analogs of the standard C 
library read(), write(), fread(), and fwrite() functions, respectively. That 
they have to shuffle around large blocks of memory in the process is an 
artifact of the underlying OS which cannot be overcome without rewriting that 
particular portion of the OS.
 RS> A more significant question is the desire to read or write "12-13 Mb". 
o
 RS> do this would require that the program operate in one of the x86's 
2-bit
 RS> modes, which would require double buffering to accomodate the underlying
 RS> restrictions of real-mode DOS. The most basic question, of course, is do
 RS> you physically have that much memory free?!?
 > I'm afraid I don't follow you. When you say double buffering do you mean
 > some sort of windowing scheme ? If you are using a good compiler that
 > supports good extenders then reading a 12-13 Mb file would be as simple
 > as:
 > 
 > cTemp=malloc (13*1024*1024);
 > fread (&cTemp,13*1024*1024,1,FHandle);
 > As for memory, I agree. 12-13Mb is a pretty hefty requirement. ;)
  What I was getting at is, as you say, 12-13 Mb of available RAM is a pretty 
hefty requirement! The reference to "double-buffering" is what you aluded to 
previously, namely that if the underlying OS only allows reading 64K at one 
time, you'll still be limited to reading then storing a succession of 64K 
temporary buffers until the entire target buffer is full. DOS extenders can 
give you access to all of extended memory that may be available. When dealing 
regularly with buffers of this size, however, it's best to begin thinking in 
terms of virtual memory which, unfortunately, most DOS extenders and no PC 
OS's which lack the consonants "n" and "x" in their name will do for you in a 
particularly clean manner.
  As for your pseudocode, the hugefread() function will do pretty much what 
you want, with minor modifications to address the fact that you'll be working 
in a flat memory model rather than using HUGE under real mode. The malloc 
will work on many compilers when working in flat model without modification. 
--- QM v1.00
---------------