Shared memory is not usually used anymore, it is far too much of a security risk on a PC, in fact in higher level languages such as C# and VBasic you can not do that. With C++ you can but must be used with caution. (I do not know if MS have dumped that posibility with the new version of their compiler).
However, if you are going through a secure medium to a server, then you can go back to shared memory using the server's own security to ensure it is safe access and limited to your assigned applications.
Think of it in terms of a shared file except that this file only exists in memory. Just like a file on a server it has access rights, but also makes use of the server's shared file access system. For example
You have 'app1' and 'app2' both accessing 'memfile'.
The server can protect you from race conditions (where both files attempt to simmultaniously alter the file).
app1 looks to see if the file is already locked.
....If not locked app1 accesses the file
...The server locks the file.
app2 looks to see if the file is already locked.
...It is locked so app2 receives an access error.
...app2 can either come back later, or it can wait for the lock to be released
...Much better though is to attach to a hook so the server will tell it when the file is unlocked.
app1 has finished, it releases it's handle and the server unlocks the file
...App2 gets an interrupt (via the hook) so can now perform it's operations ob the file.
Another methos of interprocess communications is via the Desktop messaging system.
On Windows you can create your own Messages, just like the Windows API messages. Then a calling process pops a message onto the normal Windows global queue. The receiver receives that message in it's normal message queue processing. This is quite a good method but the bank of free API values is not unlimited, you the programmer has to ensure that your message can not accidentally trigger an unrelated User Process that is also waiting for messages.
The Windows API help you with this by allowing 'signed' messages. You can also add aditional securities of your own in the 'param' data passed with the message.
There is a third method. Making use of either your Server services or Windows/Linux services.
I used this to have IT communications for all PCs and Servers wiithin a company.
Using 'Socket Services' your communications become platform independent (you obviously have to write the code for each platform, but the method of communication remains the same). You also have the advantage of your network security TCIP, you know effort on your part so long as you attach via TCP and not UDP, then you even get the VPN security system working for your application without change.