IPC: named shared memory
-
can i programatically generate a GUID to use as the "name" of "named shared memory" created by call to CreateFileMapping(..) ?? code fragment would be welcome. and if I want to create "no-name" file mapping, how can I communicate the handle to the file mapping object to a separate process? WM_COPYDATE?? thanks norm
-
can i programatically generate a GUID to use as the "name" of "named shared memory" created by call to CreateFileMapping(..) ?? code fragment would be welcome. and if I want to create "no-name" file mapping, how can I communicate the handle to the file mapping object to a separate process? WM_COPYDATE?? thanks norm
norm wrote: can i programatically generate a GUID to use as the "name" of "named shared memory" created by call to CreateFileMapping(..) ??
CoCreateGuid()will do it :-) norm wrote: and if I want to create "no-name" file mapping, how can I communicate the handle to the file mapping object to a separate process? WM_COPYDATE?? Yes, this means you have to use some other IPC channel to send the HANDLE to the target process. WM_COPYDATA is one idea, if the first process creates the second one, you could also use handle inheritance. However, a named object is usually the most convinient solution. BTW: I recommend to use not only a GUID for the name, but also a "human readable" part (somthing likeMy_app_shared_data_63dcc4b9-b122-4337-b897-88f6a7f49f3f). This would make it much easier for you and others to find your section in tools like Process Explorer and other debugging tools. -- Daniel Lohmann http://www.losoft.de (Hey, this page is worth looking! You can find some free and handy NT tools there :-D ) -
norm wrote: can i programatically generate a GUID to use as the "name" of "named shared memory" created by call to CreateFileMapping(..) ??
CoCreateGuid()will do it :-) norm wrote: and if I want to create "no-name" file mapping, how can I communicate the handle to the file mapping object to a separate process? WM_COPYDATE?? Yes, this means you have to use some other IPC channel to send the HANDLE to the target process. WM_COPYDATA is one idea, if the first process creates the second one, you could also use handle inheritance. However, a named object is usually the most convinient solution. BTW: I recommend to use not only a GUID for the name, but also a "human readable" part (somthing likeMy_app_shared_data_63dcc4b9-b122-4337-b897-88f6a7f49f3f). This would make it much easier for you and others to find your section in tools like Process Explorer and other debugging tools. -- Daniel Lohmann http://www.losoft.de (Hey, this page is worth looking! You can find some free and handy NT tools there :-D )thanks for the feedback first of all, but i dont understand the whole issue about handle inheritance. u can set the some flags in security attribute when u create the handle and when u CreateProcess. but the child process still have no idea what the handle is!? the child process has the right to inherit, but it still doesnt know what to inherit until the parent process send the handle via mechanism such as WM_COPYDATA?? norm
-
thanks for the feedback first of all, but i dont understand the whole issue about handle inheritance. u can set the some flags in security attribute when u create the handle and when u CreateProcess. but the child process still have no idea what the handle is!? the child process has the right to inherit, but it still doesnt know what to inherit until the parent process send the handle via mechanism such as WM_COPYDATA?? norm
The usual (and most easy) way to pass the inherited handles to a child process is via the command line or environment variables. -- Daniel Lohmann http://www.losoft.de (Hey, this page is worth looking! You can find some free and handy NT tools there :-D )