• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 532
  • Last Modified:

Shared Memory Pool

Hi, i am trying to find out how a Shared Memory Pool works.

1) A driver will be coded in C will read all the I/O values from a I/O device.
2) All the values will be placed in Memory.
3) Clients coded in VB.net will access the memory area, get the values and perform what they are supposed to do according to the value.

Is the above possible? If possible i need some ideas on the implementation because i am abit lost... But the above is from my understanding of what a shared Memory pool is and its uses... anyone with another understanding of a shared memory pool are welcome to comment...

Can any apps access any memory location?

  • 4
3 Solutions
I think the easiest solution would be:

let your c driver do the I/O stuff.
Create a c/c++ DLL to read the stuff from your memory and handle the management for your memory and link this to your VB.NET project.

According to my humble opinion, you cannot, or very hard, do it from VB.NET without the help of unmanaged code.

Do you mean memory-mapped file?
In any case you need to write client code in C. Different drivers require different client code - using CreateFile or Setup SDK functions, ReadFile, WriteFile, DeviceIoControl etc. - this must be written in driver documentation. If you are working together with driver developer, he must know this.
C/C++ client talks with driver and reads values using functions like DeviceIoControl. Having these values C/C++ can make them available for VB clients. Placing variables to shared memory is possible, but this is not straightforward and requires adding PInvoke code to VB .NET client.
I think the best way is writing managed C++ wrapper which talks with driver and provides pure .NET interface for VB .NET clients.
I considered using a .NET Windows Service using remoting for communication.
But I think the C code in the driver to call using remoting would be very difficult.

So I think another means of communication would be better.

Here's a .NET Windows Service using an memory mapped file for the data and using a TCP network port for communication.

A .NET Memory-Mapped Cache TcpListener Service
It's not the best-organized piece of code, but looks workable.
I haven't looked into this in detail, but I think you could take the client code, put it in it's own DLL, and compile it with a COM-Compatible-Wrapper.  The COM DLL should then be callable from both the C driver and the .NET clients.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

It might be simpler to roll your own using these .NET wrappers for the .NET clients, and just use memory-mapped-file WIN32 API calls directly in the C driver.

simple library that wraps the Win32 Memory Mapped File services
Also, here's tutorial on how to create a windows service and add TCP communications to it.
It's much simpler and clearer that the eggheadcafe example above.

P.S. A windows service is basically just a program that starts at system startup, and remains running (unless intentionally shut down, or it fails).
I think I had some good suggestions, as did PockyMaster and AlexFM -- so I suggest splitting the points.

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

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