Installing a callback between two applications
-
Hi, Does anyone know how to install a callback function between two applications? I guess that this shouldn't be too difficult (basically you just have to transmit a callback address), but I'm worring about the operating system shifting my applications in the memory. In this case the address isn't correct anymore, is that right? Is there an easy way of doing this? Thanks for your help :)
-
Hi, Does anyone know how to install a callback function between two applications? I guess that this shouldn't be too difficult (basically you just have to transmit a callback address), but I'm worring about the operating system shifting my applications in the memory. In this case the address isn't correct anymore, is that right? Is there an easy way of doing this? Thanks for your help :)
You do not need to worry about the OS moving your application around in memory because you only deal with a virtual address, and that will not change, however, the virtual address that you receive in process A will not be valid in process B. This makes calling a callback function not as simple as you would think. You will need to do some form of inter-process Communication (IPC). There are a number of ways that you can do this including, I listed these in an order of difficulty from easiest to most difficult: Send a message to the second process and the message handler will call the function for you. Create a COM object. Use a memory mapped file to communicate between the two applications, monitor the data that is written in to the file and take appropriate actions. Use a Remote Procedure Call (RPC). This is a networking mechanism that will scale to applications located on other machines, probably overkill in your case. I would suggest the message mechanism. This is the same mechanism that you would probably use in a multi-threaded application. Kilowatt
-
You do not need to worry about the OS moving your application around in memory because you only deal with a virtual address, and that will not change, however, the virtual address that you receive in process A will not be valid in process B. This makes calling a callback function not as simple as you would think. You will need to do some form of inter-process Communication (IPC). There are a number of ways that you can do this including, I listed these in an order of difficulty from easiest to most difficult: Send a message to the second process and the message handler will call the function for you. Create a COM object. Use a memory mapped file to communicate between the two applications, monitor the data that is written in to the file and take appropriate actions. Use a Remote Procedure Call (RPC). This is a networking mechanism that will scale to applications located on other machines, probably overkill in your case. I would suggest the message mechanism. This is the same mechanism that you would probably use in a multi-threaded application. Kilowatt
Thanks for your answer :) Just another question: if I solve the problem by using messages between the two processes, this means I use messages to tell the second application the address of the callback? Or use the messages instead of the callback? My concret problem: I have an application which renders a 3D world. The 3D world is refreshed continuously everytime the message queue is empty. I have a second application which can make modification to some objects in the 3D world through a dll with a shared data segment. The modifications are not directly reported on the 3D world, because all modifications have to be done just before the rendering. The modifications are stored in the shared data segment until a "redraw"-command is executed. I think everything would be easier if I could install a callback (in which I can update the data) which is called just before the rendering. Can't I somehow deduce the absolute adress of a callback function given the virtual adress?
-
Thanks for your answer :) Just another question: if I solve the problem by using messages between the two processes, this means I use messages to tell the second application the address of the callback? Or use the messages instead of the callback? My concret problem: I have an application which renders a 3D world. The 3D world is refreshed continuously everytime the message queue is empty. I have a second application which can make modification to some objects in the 3D world through a dll with a shared data segment. The modifications are not directly reported on the 3D world, because all modifications have to be done just before the rendering. The modifications are stored in the shared data segment until a "redraw"-command is executed. I think everything would be easier if I could install a callback (in which I can update the data) which is called just before the rendering. Can't I somehow deduce the absolute adress of a callback function given the virtual adress?
The reason why you cannot do this is because you cannot access the memory in the second process. If you call the callback function in process 1 with an address of a function that you determined from process 2, you will be accessing the data this is at the memory location in process 1. This will most likely result in a memory access error. WIN32 allows each application to have their own completely independent address space. This is why you cannot match the memory from one process to another. Even if you could find the absolute or physical address of the function call to the redraw command in your second app, the OS would change this address out from under you. That is why it is nice to work with virtual memory addresses, the memory moving becomes transparent to the application programmer. This would not be an issue in WIN16 because all applications shared the same address space. The reason why you can access the shared data segment of the DLL and modify the memory is because windows maps the shared data segment of the DLL into a memory mapped file. Since you already have shared data, you may just want to set an update bit that the Rendering app can monitor in its idle state and determine if it is time to update. kilowatt