ReadFile function from Win32 API

Question

I got two questions about ReadFile function from Win32 API. First of all, given that

BOOL WINAPI ReadFile(
                       _In_         HANDLE hFile,
                       _Out_        LPVOID lpBuffer,
                       _In_         DWORD nNumberOfBytesToRead,
                       _Out_opt_    LPDWORD lpNumberOfBytesRead,
                       _Inout_opt_  LPOVERLAPPED lpOverlapped
                    );

the third and fourth parameters are of type DWORD, which can hold maximum 1^32 without overflow. Does it mean that the ReadFile can only read a file that has less than 1^32 bytes data at a time? If that is true, I want to read a file bigger than 1^32, I'll put the ReadFile in a loop like this

char buffer[1<<32];
while(!EOF){
  ReadFIle(filename,buffer,1^32,bytesout,NULL);
  SomeFunctionToExtractDataFromBuffer(buffer)
}

Supposed the loop tends to overwrite the buffer every iteration, in order for this design to work, the ReadFile needs to remember where the previous read happened in the file is this true? or there are other ways to achieve this. Thanks a lot

Answer 1

The third and fourth parameters are of type DWORD, which can hold maximum 1^32 without overflow. Does it mean that the ReadFile can only read a file that has less than 1^32 bytes data at a time?

No. It means that it can only read up to 2^32 bytes in one go. There's noone stopping you from calling ReadFile multiple times to read a total of as many bytes as you like (each read will advance the file pointer , so it will begin reading from the point where the previous read stopped).

Supposed the loop tends to overwrite the buffer every iteration, in order for this design to work, the ReadFile needs to remember where the previous read happened in the file is this true?

Yes, the OS remembers this for every open file (see file pointer link above).

While on the subject I should mention that if you are scheduling 4GB reads then you are most likely doing something wrong. No matter what the nature of your data is, surely you can process it in smaller chunks and this will help not run up against a variety of problems such as available memory.