🚀 go-pugleaf

In article <SO-ECS.91Apr23115117@stekt1.oulu.fi> so-ecs@stekt1.oulu.fi (Juha Ruotsalainen ti) writes:
>How can my program read a file bigger than 64k into memory. 
> ...
>Is there a problem with DosAllocHuge....
DosAllocHuge allocates a set of consecutive segment descriptors.  With
appropriate pointer operations, it is possible to treat the result as 
one big array.  But underneath, it really is a set of separate 64K segments.
DosRead etc. will never go beyond the end of the segment you pass in as a
parameter... they have no way of knowing it is OK to go on and
use the next segment descriptor.  
 
I don't think there is any way to make DosRead read a full 64K in one
operation, so I guess it will take two reads for each segment. e.g., 
read 0xffff to the base of one segment, 1 byte to the end of the segment,
then 0xffff to the base of the next.  
Probably an easier way would be to just read in a series of 32K chunks
and bump the segment pointer every second time. 
 


Alan Ballard                   | Internet: ballard@ucs.ubc.ca
University Computing Services  |   Bitnet: USERAB1@UBCMTSG
University of British Columbia |    Phone: 604-822-3074
Vancouver B.C. Canada V6R 1Z2  |      Fax: 604-822-5116

I thought I saw that putting 0 in for the length gives 65536 bytes,
but I can't right now find it in the book.  

The length parameter is short, so a number greater than 65536 could
not be specified.

From article <SO-ECS.91Apr23115117@stekt1.oulu.fi>, by so-ecs@stekt1.oulu.fi (Juha Ruotsalainen ti):
> How can my program read a file bigger than 64k into memory. At the
> moment I try to read 64k`s at a time and the rest of it (less than
> 64k) afterwards. But after I`ve read 0xffff bytes, the next DosRead
> reads only 1 byte. Is there a problem with DosAllocHuge, I mean,
> shouldn`t it allocate a memory block larger than 64k. I have traced
> the DosRead call with CodeView, and was surprised to see that when the
> program tried to point past 64k area (jimi[0x10000]) there was an I/O
> error. I hope you understand my I`m trying to say here. Please help...
> -ECS

Is this a problem with the fact that read and write can only r/w
64K - 1 bytes at a time, noting the fact that the error status
return (-1) from read and write represents 64K exactly???


|----------------------------------------------------------------------------|
|Tom Hite					|  The views expressed by me |
|Manager, Product development			|  are mine, not necessarily |
|CADSI (Computer Aided Design Software Inc.	|  the views of CADSI.       |
|----------------------------------------------------------------------------|

In article <1991Apr30.200832.9352@ccad.uiowa.edu> cadsi@ccad.uiowa.edu (CADSI) writes:
> From article <SO-ECS.91Apr23115117@stekt1.oulu.fi>, by so-ecs@stekt1.oulu.fi (Juha Ruotsalainen ti):
>> How can my program read a file bigger than 64k into memory. At the
>> moment I try to read 64k`s at a time and the rest of it (less than
>> 64k) afterwards. But after I`ve read 0xffff bytes, the next DosRead
>> reads only 1 byte.
>
> Is this a problem with the fact that read and write can only r/w
> 64K - 1 bytes at a time, noting the fact that the error status
> return (-1) from read and write represents 64K exactly???

You're talking about read(). Juha asked about DosRead(). Let's talk
about DosRead(). It doesn't return -1 on error at all, and even if it
did, -1 does not represent '64k exactly'.

64k is (65536 == 0x10000), not (65535 == 0xffff == 64k - 1).

The answer to Juha's question is that DosRead() can only read 0xffff
bytes at a time. This is 1 short of 64k. After the DosRead() of 0xffff,
the 64k segment then has 1 byte left in it. The second DosRead()
therefore reads 1 byte into it. DosRead() won't cross segment boundaries.

Juha then has to increment the selector returned by his DosAllocHuge()
to form an address for the beginning of the linearly next segment, into
which he should do more DosRead() calls, and so on.

How are you, Juha?

-- 
Esmond Pitt, Computer Power Group
ejp@bohra.cpg.oz