Simple IPC / Functioncall in different address space
-
Hello, I'm writing on a database application where the data is stored as HTML code (incl. images, JavaScripts and StyleSheets) in an SQlite database. The data is displayed in an MFC application with CHtmlView. I can't use dynamic document writing via OnBeforeNavigate2 because I need my images and scripts to be stored in the database too. So I have written a very simple "Asynchronous Pluggable Protocol" for this. I need to register this handler (a DLL) globally with regsvr32. But now I do not want to split my application logic into the exe and the DLL; instead, I want the whole application logic to reside in the MFC exe. Including the load procedure for a specific HTML page/images from the database. So my idea is: In my app, I navigate with CHtmlView to myapp://. Then my protocol handler is called. This DLL now requests the actual data from the running MFC application. The MFC app in turn loads the specific data from the SQLite database and passes the data back to the DLL. The big question now is: What is the simplest method (IPC) to request data (up to a few MB) from a running application? A great thing would be if the DLL could just call a defined function from the running exe like:
void getContent(int pageID, char *buffer, int *len);
or better:
void GetContent(char *url, char *buffer, int *len);
But I guess this is not easy. So I rely in IPC. But IPC is a very complex topic; I have no experience with it in Windows. Additionally, synchronization is a complicated issue too. How would you solve this problem? Is there a simple method that fits to my description? WM_COPYDATA would be possible but unfortunately the Pluggable Protocol does not have a message queue. And I also need to pass the URL to the application when requesting a specified content. Thank you for any hints! Niki
-
Hello, I'm writing on a database application where the data is stored as HTML code (incl. images, JavaScripts and StyleSheets) in an SQlite database. The data is displayed in an MFC application with CHtmlView. I can't use dynamic document writing via OnBeforeNavigate2 because I need my images and scripts to be stored in the database too. So I have written a very simple "Asynchronous Pluggable Protocol" for this. I need to register this handler (a DLL) globally with regsvr32. But now I do not want to split my application logic into the exe and the DLL; instead, I want the whole application logic to reside in the MFC exe. Including the load procedure for a specific HTML page/images from the database. So my idea is: In my app, I navigate with CHtmlView to myapp://. Then my protocol handler is called. This DLL now requests the actual data from the running MFC application. The MFC app in turn loads the specific data from the SQLite database and passes the data back to the DLL. The big question now is: What is the simplest method (IPC) to request data (up to a few MB) from a running application? A great thing would be if the DLL could just call a defined function from the running exe like:
void getContent(int pageID, char *buffer, int *len);
or better:
void GetContent(char *url, char *buffer, int *len);
But I guess this is not easy. So I rely in IPC. But IPC is a very complex topic; I have no experience with it in Windows. Additionally, synchronization is a complicated issue too. How would you solve this problem? Is there a simple method that fits to my description? WM_COPYDATA would be possible but unfortunately the Pluggable Protocol does not have a message queue. And I also need to pass the URL to the application when requesting a specified content. Thank you for any hints! Niki
How about using sockets or pipes?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
-
How about using sockets or pipes?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
Hi, The main problem is that I have no experience with these. But at first glance they seem to be too complicated. I need no Networking support, it should just go fast & simple. Sockets are really oversized for that. Problem with shared memory: I need complex caching structures and synchronization. I would seek for an IPC method that works very simple like a remote-process function call and which is blocking: I request something in my MFC app and get the answer directly; the DLL should be blocking while this process is done. I have experimented with WM_COPYDATA. But here I need to create a dummy window inside my DLL, send WM_COPYDATA to my MFC app to request the data and in turn send another WM_COPYDATA back to the DLL with the actual data. Too much complexity and oversize :( I also need to copy the data a few times. Named Pipes: I do not know them exactly but is this really simple for my case? How do I manage the server part in my MFC app? Do I need a separate thread for this? Does this work when there are requests done simultanely? Niki
-
Hi, The main problem is that I have no experience with these. But at first glance they seem to be too complicated. I need no Networking support, it should just go fast & simple. Sockets are really oversized for that. Problem with shared memory: I need complex caching structures and synchronization. I would seek for an IPC method that works very simple like a remote-process function call and which is blocking: I request something in my MFC app and get the answer directly; the DLL should be blocking while this process is done. I have experimented with WM_COPYDATA. But here I need to create a dummy window inside my DLL, send WM_COPYDATA to my MFC app to request the data and in turn send another WM_COPYDATA back to the DLL with the actual data. Too much complexity and oversize :( I also need to copy the data a few times. Named Pipes: I do not know them exactly but is this really simple for my case? How do I manage the server part in my MFC app? Do I need a separate thread for this? Does this work when there are requests done simultanely? Niki
Sure it can get complicated, but that's where you earn your money. Don't wimp out!
-
Sure it can get complicated, but that's where you earn your money. Don't wimp out!
I HAVE THE SOLUTION!!! The DLL is loaded into the same address space of my application!! So I can just use pointers in normal WM_USER messages and I do not need any IPC!! :) And the best thing: I do not need synchronizing; this is done automatically: I just send a WM_USER with SendMessage to my view window which reads the data from the database and passes a pointer to that data to the DLL. The good thing: SendMessage is blocking while this is done so I do not need to lock my database variables with critical sections. And if there is another request in parallel, it is spooled automatically by the windows messaging system and SendMessage is blocking again. Please correct me if I am wrong. Regards, Niki
