Well the Excel as found in Office 2003 was XLS and you can't get Office 2003 anymore even as a download so in that regard MS doe snot support even though it should run on 32 bit machines.

Back Story. Been away and looking to start a tech company I will need nerdy programmers.
Also Im breaking with the traditional company as we all know and love. No more employees and no more employers. We all set at the round table of tech and if you want to be boss you can.

I hate to be a party pooper but  I avoid anything DEF this or DEF that. Please see some of my old code on this forum, my code is crisp and clean no caffeine - well that is a lie - I drank a pot today and gonna make another.

** The only thing I need at the moment is an Installer function added to the setup. The (replacement)setup program is written in QB. It has to run in DOS, that is the main goal.**

Ok if the installer only runs in DOS then the game runs in DOS too so Im not sure I follow.  You might want to try messing about with Microsoft XP and see if it works there. To run the same DOS game in QB64 you got to port over the basic source code (if you can get the source) and compile it in QB64.  Now I think you said that the game was written in 16 bit assembler but that wont run on anything later than XP

I've decided to leave the forum.  nothing more to do here. API is the last hurdle - it is not worth it.

Lets look into the WIndows readfile etc


https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-readfile

Reads data from the specified file or input/output (I/O) device. Reads occur at the position specified by the file pointer if supported by the device.

That is OK we might as well include a file pointer sub too. here is how WIndows wants the sub  (er whatever it is) to look like

BOOL ReadFile(
  HANDLE       hFile,
  LPVOID       lpBuffer,
  DWORD        nNumberOfBytesToRead,
  LPDWORD      lpNumberOfBytesRead,
  LPOVERLAPPED lpOverlapped
);

I don't what the BOOL is . Those parameters look OK but there is LPOVERLAPPED lpOverlapped and that one i'm not familiar with.

There is only a 5 minute window to edit posts so this post and  other posts will have mistakes so keep that in mind.

lpOverlapped

A pointer to an OVERLAPPED structure is required if the hFile parameter was opened with FILE_FLAG_OVERLAPPED, otherwise it can be NULL.

If hFile is opened with FILE_FLAG_OVERLAPPED, the lpOverlapped parameter must point to a valid and unique OVERLAPPED structure, otherwise the function can incorrectly report that the read operation is complete.

For an hFile that supports byte offsets, if you use this parameter you must specify a byte offset at which to start reading from the file or device. This offset is specified by setting the Offset and OffsetHigh members of the OVERLAPPED structure. For an hFile that does not support byte offsets, Offset and OffsetHigh are ignored.

For more information about different combinations of lpOverlapped and FILE_FLAG_OVERLAPPED, see the Remarks section and the Synchronization and File Position section.

and that is why we pay $20,000 for an expert to explain this all to us.

 @SMcNeill

I have learned that you are usually correct and yes I love a good argument as long as it is a constructive one.

So READFILE is inside some compiled C++  code.  The thing is GET statement gets it's bytesToRead value from string length.  GET should be like this

GET handle, bytesToRead,  fileBuffer

where handle is a file handle
bytesToRead is the number of bytes to read from the file
fileBuffer is where the file bytes are stored.

Only one fileBuffer.

However you can not enter a bytesToRead value directly into GET.   GET essentially second guesses what the coder would REALLY like.  That leads to complications.

GET figures out bytesToRead from (example)

string1 = space$(bytesToRead)
GET #1,string1   etc

so string1 is a variable length string - not fixed.

The thing is MEM  works with a single memory block (fixed length) but GET works with multiple (variable) memory blocks (strings). It does not work out too well.

If you want the fastest load times, just get the whole file at once and then parse it.

I thought about that and it does work but to me that is a band aid approach.

Trust me!   if I had a READFILE API sub the BMP viewer would be a 1000 times faster.

About 50 hours has gone into the BMP viewer why stop there. We have a resident API wizard and so much absolute talent,  what other forum has that  - none.

The other thing is that a READFILE sub is almost the same as a WRITEFILE sub


Think of all the high speed file access QB64 can do with some practical API subs.  Some might think it is UNBASIC.  Well look at modern day OSes has anyone noticed that they do not resemble the OSes when BASIC was invented. 

Ok

    DIM fileBuffer AS STRING * 16383
    DIM m AS _MEM
    m = _MEM(fileBuffer)

I need these 3 lines of code to work with GET.  fileBuffer is the memory block with a max size of 16383 bytes.  MEMGET must   access fileBuffer and then do some calcs and MEMPUT to the handle given by NEWIMAGE etc.

In assembler I could make a DOS function call to READFILE and it will read a file by a specified number of bytes and put those bytes in, say, fileBuffer.    GET has no such number input as it gets it's length info from string length.  Right away we gotta do some serious gymnastics to get this to work.

The objective here is to read a file by chunks of a least 16383 bytes at a time instead of 3 bytes at a time. This should seriously speed up the code.

MEM works with fixed length strings (which is good). The last file read will be a chunk either 0 bytes or less than 16383 bytes, so that looks like a variable length string is involved but MEM must work with fileBuffer which has a fixed max length of 16383.

If the last chunk is , say, 501 bytes it must be stored to fileBuffer.  In that way MEM references the same memory block.

However GET wants something like string = space$(chunksize)  but now MEM is hooped I think.

Maybe our API wizard could give us a READFILE SUB

(write a specified number of bytes to fileBuffer)



***** correction

I said "read a file by chunks of a least 16383 bytes"

should read " read a file by chunks of 16383 bytes or less"