Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 531
  • Last Modified:

Memory Mapping

This is a Delphi 2 question:

I'm going to be using memory mapping to ensure that a 'middleman' DLL I am writing will allow access to the same data for all processes accessing it.

Can I set up a memory map that simply contains pointers to the addresses of AllocMems that the DLL wil create. If the DLL uses an AllocMem to create 512KB of data storage and I then store the address of this memory in the memory map, can I then access that memory through the memory map via any of the processes that are using the DLL?

I ask because any process can request memory from the DLL and I want any other process to have access to it. So my thought was to still allocate memory the old way, via AllocMem, but store the addresses of these allocations in the shared memory map to allow all processes access to it.

Background: in D2, a DLL creates an an instance of all it global variables and such for each process connected ot it...if one process asks the DLL to allocate memory, that allocation is totally invisible to all other processes using the DLL. But if we use memory-mapping, we can share data among all the processes. Using memory-mapping for all my data sharing would not work because my allocations are very dynamic...therefore a method of storing the addresses of the allocations would work best.

Thanks.
0
mheacock
Asked:
mheacock
1 Solution
 
sperlingCommented:
No, you cannot store the return address from AllocMem. This address will only be valid in the context of the process that caused the DLL to allocate memory.

I have done something very similar to what you're about to. The methods I used was as follows.


First, understand CreateFileMapping and MapViewOfFile if you haven't already.


On Initialization, and in DLLProc on process attachment, I create/connect to a named shared memory object using CreateFileMapping($FFFFFFFF ... Let's call it MEMTABLE


The DLL exports
  ShareAlloc
  ShareDealloc
  ShareLock
  ShareUnlock


ShareAlloc allocates an amount of memory as follows:
  If not MEMTBLxxx exists, create MEMTBL001
  If all MEMTBLxxx are full, create next MEMTBLxxx
  Add an entry to MEMTABLE containig the xxx number, an unique handle, starting and ending offsets within MEMTABLE
  Return the handle

ShareLock looks up a passed handle, and returns a pointer to it in addition to increasing a usage count in MEMTABLE

ShareUnlock takes a pointer and reduces usage count for the associated MEMTABLE entry

ShareDealloc fails if the usage count is 1 or greater. If not, the MEMTABLE entry for the passed handle is zeroed, and if the MEMTBLxxx is empty, it is freed.
 
Using this scheme, any app can pass the handle using e.g. SendMessage to another app, which then can lock and read the memory as if it was allocated in the process. Note however that the actual returned pointer for any handle may and will differ from process to process.


MEMTABLE entry:
  BlockNumber
  Offset
  Size
  Usage
  Handle

all INTEGERs

The initial size of the MEMTABLE determines the max number of handles that can be allocated.

You should use critical sections to protect all the Share* functions.

You could also create a replacement TMemoryManager, which handles this in the DLL. I do believe you could manage to create shared objects this way, but I've never tried as it would be a heck of a job.


Erik.
0

Featured Post

Ask an Anonymous Question!

Don't feel intimidated by what you don't know. Ask your question anonymously. It's easy! Learn more and upgrade.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now