How can I share the data between two managed processes using shared memory segments? I am using "object"
inside C++/CLI code to share the data with some other part of memory in the other process. I am using following code segment.
#define BUFFER_SIZE 32768
#pragma data_seg (".SHAREDMEMORY")
bool _Locked = false;
bool _Initialized = false;
unsigned char[10000] data = NULL;
#pragma data_seg()
#pragma comment(linker,"/SECTION:.SHAREDMEMORY,RWS")
but I need it to be:
#pragma data_seg (".SHAREDMEMORY")
bool _Locked = false;
bool _Initialized = false;
object^ _object = nullptr;
#pragma data_seg()
#pragma comment(linker,"/SECTION:.SHAREDMEMORY,RWS")
It is saying that "global or static variable may not have managed type System::Int32^"
and giving other errors like "missing ; before '^'"
.
I have to copy the .NET "Control"
object's data to this shared segment and I need it to transfer 开发者_JS百科to another process.
It is best if you describe what you want to do instead of asking how to continue when you hit a wall, the wall may be a dead end.
.Net classes like Windows Forms and WPF implement Windows accessibility and automation APIs as Microsoft's efforts to comply with the Americans with Disabilities Act, a USA law to protect the disabled.
Although the APIs are designed mainly for making software written for Microsoft's platform more accessible to the disabled, the APIs expose the software in such a way that standardized UI automation is now possible. What you need to do for your app to be testable is now simplified to making your app accessible
The APIs are called by Microsoft's Microsoft UI Automation Framework, a framework used by many testing frameworks for managed code. To learn more about Windows's accessibility APIs or find open source projects based on Windows Accessibility and Automation APIs, visit Accessibility Overview .
There are some tips about testing apps in MSDN Magazine's testing and debug column.
You cannot put .NET objects in shared memory.
Pointers are only valid in the process they are created in. So data can only be shared if it has no pointers (or uses based addressing, a concept which is mostly dead in the 32-bit flat memory model).
Sometimes you can get away with C++ objects that have a v-table, as long as the library loads at its preferred base address in all processes. But .NET functions have dynamic addresses because they are compiled at runtime. There's no hope that metadata pointers will match between different processes.
Also, how would garbage collection work? Garbage collection needs to see all references to know whether an object is reachable, but you wouldn't be able to see into the non-shared area of other processes. And to which heap would the memory be returned?
Conclusion: You can't put .NET objects in shared segments, shared memory mapped files, or use bitwise serialization. Instead you need to put plain old data in the shared area, and use raw native pointers (not even C++ smart pointers, see above comments about memory management). You can wrap that pointer in a C++/CLI object in order to make it friendly, but you can't share the .NET object itself.
You need some form of IPC, for example a memory mapped file.
精彩评论