views:

56

answers:

5

I got two console processes that second one is created by first one using the API below:

BOOL WINAPI CreateProcess(
  __in_opt     LPCTSTR lpApplicationName,
  __inout_opt  LPTSTR lpCommandLine,
  __in_opt     LPSECURITY_ATTRIBUTES lpProcessAttributes,
  __in_opt     LPSECURITY_ATTRIBUTES lpThreadAttributes,
  __in         BOOL bInheritHandles,
  __in         DWORD dwCreationFlags,
  __in_opt     LPVOID lpEnvironment,
  __in_opt     LPCTSTR lpCurrentDirectory,
  __in         LPSTARTUPINFO lpStartupInfo,
  __out        LPPROCESS_INFORMATION lpProcessInformation
);

Now I wonder that if I pass a pointer to a part of memory of the first process, via IpCommandLine to the second process which is called by first process, will reading the memory to which that pointer points, by the second process definitely cause an access violation error or is it subject to value of some parameter of that API? If I can't use this API alone for my purpose, what method do you propose for the access ?

+2  A: 

You can access this memory using ReadProcessMemory/WriteProcessMemory API. Another process needs to know memory address and handle of the process to access its memory.

Alex Farber
A: 

I believe the use of volatile will allow other processes access to memory. Of course it will need a pointer to it

Raynos
No, volatile will not allow you to jump across address spaces.
janm
Ummm... nope. volatile - back in the day - indicated a compiler should not optimise by keeping a changing variable "privately" in a register, but keep writing the changes back to the actual memory location that other threads/interrupt-handlers etc. would expect the current value to be in. These days - with all the multi-level memory caches and cores, volatile isn't sufficient to ensure a flush out to some generally visible level. A mutex is typically used, though at the asm level various memory barriers instructions may be used.
Tony
Ah. I kind of expected that volatile would still magically allow memory to be used among proccesses.
Raynos
A: 

Here is my uninformed opinion (haven't done much of this thing on windows):

Separate processes (pretty much by definition) normally don't have the access to each other's memory space directly. Therefore you should use one of the interprocess communication (hint: that is something you google for) methods.

I don't know much about windows in this respect, but things like sockets, pipes, memory-mapped files and various forms of RPC come to mind. It, of course, depends on your actual use case.

shylent
A: 

Alex Farber's answer is correct; you can use Win32 API calls to read another process's memory. However, this is probably a bad idea. If you have a data to move around, you can either pass it as a parameter on the command line, or you can pass a handle to the other process and connect the two processes using a pipe.

janm
A: 

I've done this before with #pragma's. I don't have the actual code handy at the moment, but I think something similar to this might work with Visual Studio 2008 C++:

//put this code in a dll that both processes link to

pragma section("shared",read,write,shared)

__declspec(allocate("shared")) int i = 0; // in theory, both processes should be able to access and modify i

The DLL shared memory segments are a holdover from legacy 16 bit dos days and have a number of drawbacks (security holes, mostly) - so it's usually best to avoid them. It's probably better to stick with the OS APIs for shared memory or memory mapped files for this functionality.
Mike Ellery