VB6 - Treat a file like an array without reading to memory.

[stevensrmiller]

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

The "TestTestTest" string is actually in a file... It does read from the file location, but doesn't load it into memory.

Sorry to dredge up a very old thread, but VB6 is a very old language, and this posting helped me get going on mapped files.

Even though Comintern's code is great (though I would not regard his suggestion that the SafeArray structure be restored before the bBytes array goes out of scope as optional; gawdnose what VB6's memory manager might do if you end up freeing the same block twice, and, at minimum, you will probably have a memory leak from the original allocation), I believe neither of his statements above is true. The "TestTestTest" string is never in a file. It serves only to return a newly allocated String so there will be something in the bBytes array prior to modifying its SafeArray structure to point to the mapped memory. You actually don't need to do this. When you declare the array, you can give it a dimension if you want to ("Dim bBytes(24) as Byte"), though I doubt even this is really necessary. Regardless, whatever is in the bBytes array before altering it to poing at the mapped memory is never in a file.

Whatever is in the file ("D:\Test2.txt", in Comintern's examples) does get loaded into memory when MapViewOfFile is called. You can map just a chunk or, as Comintern has done, the whole thing. It's a great way to poke around in a file, though, utimately, if all you want to do is to read and write the file, this is a complicated way to do it. Easier would be to read the whole file into a byte array with ordinary file i/o calls, do your work, then write the whole array back again.

Now, the power of Comintern's code is, I would say, in the fact that, once it has been mapped, any other process can also map the same region of memory. Where his code calls "CreateFileMapping," other processes would call "OpenFileMapping" (check out MSDN doc on this, as the calling sequences are surprisingly dissimilar). After both processes have mapped the file and created views, and then altered their bBytes arrays (or whatever they call them), both are then sharing the contents of that array with each other. It becomes one array shared by two (or more) processes. Other IPC mechanisms would be needed to synchronize communications (one might use, say, sockets to alert one process that the other has changed the contents of the shared memory), but this (according to MSDN) the only way for 32-bit Windows processes to share memory.

With a few lines of changed code, I've made Comintern's program into two programs, one that creates the mapping and one that opens it. Both can read and write the same array, with each seeing the other's changes. Now, I have no idea if memory caching could defeat this (that is, if one process caches the memory it writes to, does that mean the other process won't read the changes until after the cache is written through to main memory?). If so, one would have to use some kind of memory fencing to avoid it. But, the problem doesn't come up in my test programs, so maybe mapped memory always writes through from cache to main storage. (If anyone can find a reference that says so, please let me know!)

Great sample program. Thanks for posting it.

UPDATE: According to MSDN, mapped views of the same file are always coherent: no need for memory fences.