VB6 - MMapper, Memory Mapped File Demo

Background

People are often scrounging for easy to use IPC alternatives for Visual Basic programs. Windows offers a ton of choices, but unless you can state your requirements it is difficult for somebody else to make a recommendation.

One obvious route is to use a common disk file shared among your program instances (processes). This really isn't as bad as it sounds, but there is a somewhat lighter-weight alternative to a shared temporary file that often isn't considered.

Files can be mapped into shared memory, but we can go a step further and "back" such shared memory with the system paging file instead. This thread talks about some simple code to do this in a bare bones fashion.


MMapper

MMapper is a simple class using the basic set of API calls required to create, open, read, write, and close such a chunk of shared memory.

As written, it sets up a BLOB of bytes as shared and then treats it as a single place to write or read data that multiple processes can use. Since you do not get fine control over where this memory is mapped into your processes' address spaces it is normally used along with CopyMemory() calls.

MMapper handles this by accepting pointer and length arguments for its read and write methods. This means you can pass String variables, Byte arrays, or even UDTs that are flat (do not contain dynamic-length fields).


The Demo

The attached demo contains the MMapper class and two projects: Writer and Reader.

Writer is responsible for creating the mapped file and writing data to it. Reader opens this mapped file (which requires that it is first created by Writer) and reads data from it.

MMapper creates/opens the mapped file with read/write access, so the fixed roles of Reader and Writer are simply to make the operation easier to understand.

You could easily have every program (and every instance of each program) try to create the mapped file, and they could all both read and write. It's just a matter of figuring out how you want to coordinate things among all of the running processes, and that part is up to you.

Here I use a small UDT to pass one Long value and one String * 100 value.


Enhancements

It is easy enough to extend MMapper in several ways.

Some of these involve security options to allow sharing among users. You can also treat the mapped space as several separate items instead of one BLOB. And you can map an actual disk file, providing persistence across sessions.

See your MSDN Library CDs or Windows SDK for more details.

This even works on Win9x with a few limitations inherent in the platform (such as no Terminal Services or Fast User Switching or other multi-user support).

To answer a PM:

No, the demo works fine on Windows 95. It is only more broad use of memory mapped files in a multi-user scenario that is a little impaired and the "file" name requirements differ slightly as a result too.

This is covered fairly clearly on the MSDN CDs, the Windows SDKs, and at the MSDN Library Web site.

Can this idea use for video or voice (VOIP) chatting via internet/LAN?
In your previous post of camera view, can we share the video/voice through internet as fast as possible using this technique? (some sore of iPhone/iPad facetime)

No, it can't work at all over the Internet.

Even using it between machines on a LAN there are limitations. As it says in the documentation:

Quote:

---

With one important exception, file views derived from a single file-mapping object are coherent, or identical, at a given time. If multiple processes have handles of the same file-mapping object, they see a coherent view of the data when they map a view of the file.

The exception has to do with remote files. Although CreateFileMapping works with remote files, it does not keep them coherent. For example, if two computers both map a file as writable, and both change the same page, each computer will only see its own writes to the page.

---

This is an inter-process communication (IPC) technique and not a network protocol.

It can't work with any random OS either, whether from Apple or anyone else.

Quote:

---

Originally Posted by dilettante

No, it can't work at all over the Internet.

Even using it between machines on a LAN there are limitations. As it says in the documentation:


This is an inter-process communication (IPC) technique and not a network protocol.

It can't work with any random OS either, whether from Apple or anyone else.

---

I see. I remember I ever created a RAM drive for desktop remote control program at 8 or 10 years ago. The program cashed the screenshots in RAM drive instead of hard disk to speed up screen transfer.

This isn't related to a RAM drive either.

Memory-mapped files are entirely different. See:

Memory-mapped file

File Mapping

It dawns on me that this is yet another pretty nifty way to have inter-process communications. Also, using this approach, there's no need to have a hWnd. It could all be done with headless processes.

Hi dilettante,

could objects be shared between processes using this file mapping technique ? Thanks.

can use rot?lot?
like getobject("11.xls")

Quote:

---

Originally Posted by xiaoyao

can use rot?lot?
like getobject("11.xls")

---

Yes . I know. The ROT is what I use but I was wondering if the file mapping can somehow make possible sharing objects memories between processes.

Thanks.

Quote:

---

Originally Posted by AngelV

I was wondering if the file mapping can somehow make possible sharing objects memories between processes.

---

Yes it can. Just use the same string-name for the lpName in your call to OpenFileMapping.

However, this stuff is really just for getting access to Far Memory (beyond our 2GB). There are easier ways to get strings between processes than this (in memory), especially if they're far less than 2GB.

You can think of this Far Memory I/O much like a regular file. However, it's gone when nobody is accessing it anymore.

Quote:

---

Originally Posted by Elroy

Yes it can
You can think of this Far Memory I/O much like a regular file. However, it's gone when nobody is accessing it anymore.

---

Thanks.