I am looking to see if I can do it in a faster way then those because many notification per second are needed. I know a callback, that is not inter-process (just between my EXE and DLL alone), is the fastest of the three in my tests (although that might not be the case if it was possible to implement in my situation) but given that the goal is inter-process and the interpreted language limitations, maybe something else that I have not mentioned would be better?
In general though each process has a separate address space (NT) so the function can have a different virtual address. It varies process to process. Also, MMF and other IPC can fail for several reasons so I wouldn’t find it reliable for sharing a function address with other processes.
If so, no, you cannot easily make this available in other processes. Other processes would first have to load a module (DLL/EXE) file which contains the same code. Please understand that each process is completely separated in modern OSs. Which means that code which is available in process A is not available in process B. And a pointer in process A doesn't point to the same physical RAM as a pointer with the same value in process B.
How to actually "call" your code in the context of the other process is a whole different topic. It's a separate problem you also have to solve. But the first thing to solve is that any code you want to call must first be made available in the target process.
Maybe if you give us a full explanation of what you really want to do and for which purpose in great detail, then we can give you better advise.
Export your callback from your DLL
Inject your DLL into whichever processes you need to have callback execute remotely
In your process (which executes code in other processes) enumerate modules in the target process(es)
and add the module base address (HMODULE), if your module is found, to the relative virtual address (RVA) of the exported callback function
You can calculate the function's RVA by loading the DLL into your process and subtracting the base address (HMODULE) from the callback's virtual address (VA), and store the RVA, it won't change regardless of process, only the VA can change from process to process.
Create a new remote thread at this function address (your exported callback in the target process with Base + RVA which turns into VA)
That's the short end of it for the sake of brevity, there are things you'll need to pay attention to such as process bitness differences, the state of the process (suspended, debugged, uninitialized, initialized), process session isolation etc. It mostly pertains to if/when it's "safe" to execute a remote thread, but that's magic which Madshi and I already know too well and it's not a quick and easily understood post to elaborate upon.
@iconic - Unfortunately, I found out that the other process can only load a DLL but can not handle pointers/addresses (I seem to work with many interpreted/script based languages). The callback is in my process and the executing code would be in the interpreted process.
Sorry for any confusion, hopefully I can clear things up with a rewording.
If the other process can load a DLL which exports a function it needs no knowledge of what is going on, it's only loaded some .dll file that exports an API, "remotely" callable from any other process. That's why Windows is built on modularization with DLL's, the main .EXE can't perform everything on its own with(out) additional resources, eg: other DLL dependencies.the other process can only load a DLL but can not handle pointers/addresses
If you tell Madshi and I more we can help.
PostMessage(YourExesMainFormWindowHandle, WM_USER + 123, param1, param2);
You can send 2 parameters this way, param1 and param2. And in your Delphi EXE, simply add a message handler for WM_USER + 123.
As Madshi said with PostMessage():
You can use PostMessage() (It's fast and doesn't wait like SendMessage) from your scripted program that loads your DLL and needs to inform your EXE for (IPC) means, however it only works with non-service processes, so be careful of this. madCodeHook's SendIpcMessage() works in both services and GUI apps regardless of session. There's a BIG difference, but if speed is a factor for "notification" PostMessage() is very fast, it's governed below user32.dll by Win32k.sys as a direct system call (e.g: NtUserXxX).
Perhaps, if I understand what you mean, you should have titled your post "Fastest way to IPC from a DLL to an EXE" - actually mailslots are VERY quick too, but that's another rant
@iconic, calling PostMessage does not internally make the thread handle messages or put the thread into an alertable state, does it? I don't think it does, just wondering...