Why can't you access the address space of another process since Windows 95?

Question

Say I send a pointer as an argument to another program:

program.exe -mypointer

and try to use it in that program, it won't work. After some research (i.e asking at Lounge C++ ) I found that since Windows 95, you can't access the address space of another program. In older versions of Windows it was allowed. My question is, why did Microsoft disallow it? What were the problems or disadvantages of doing this?

P.S Is it still possible through some work-around to do this in new versions of Windows?

Answer 1

Because being able to access the address space of other processes means that you can crash them by, for example, changing their memory contents randomly.

The whole point of protected mode is to protect processes from each other. See the memory protection Wikipedia page for some more details. In the bad old days before protection, it was a lot easier to write code that fiddled with other processes.

The downside of that is that it was a lot easier for some a bug in MS Word to not just crash MS Word but also Excel, Borland C, your PI digit calculator that had been running for the last six weeks, and even the operating system itself.

You still can get access to another process address space but you basically have to run at higher privileges to do this. For example, this is how debuggers allow you to run a process and access all its memory for debugging purposes.

The calls ReadProcessMemory and WriteProcessMemory allow you to do this, along with many other debugging functions.

Answer 2

16-bit Windows did some truly amazing feats of memory management, but it was hampered by being designed for a processor without memory management, namely the i8086 of the original PC (hardware folks may note that the original PC used an i8088, which was identical except for width of data bus).

So, in 16-bit Windows processes shared the same view of memory.

One problem with that is that the common memory address space isn't that large, really, when umpteen processes want to own their own chunks of it.

In addition it makes it rather too easy for processes to stumble on each others' feet.

Windows offered some partial solutions, such as the ability for a process to inform Windows about when it was actually using some memory (the process would then "lock" that memory region), which meant that Windows could move memory contents around to make room when needed, but it was all voluntary, and not very safe either.

So, 32-bit Windows, Windows NT, utilized the newer processor's memory management to automate the best practices that 16-bit Windows programs should have used. In essence, a process deals only with logical addresses, which the processor automatically translates down to physical addresses (which the process never sees). Well, on the 32-bit PC the translation is a two step affair, i.e. there's an internal intermediate address form, but that's complication you don't need to know about.

One nice consequence of this hardware-supported address translation is that a process can be completely insulated from knowledge of which physical addresses it uses. For example, it's easy to have two processes of the same program. They think they're dealing with the same addresses, but those are only logical addresses; in reality, their logical addresses are translated down to different physical addresses, so that they're not stomping on each others' memory areas.

And one consequence that we with 20-20 hindsight can say is not so nice, is that the translation scheme allows virtual memory, e.g. to simulate RAM by using disk space. Windows can copy memory contents to disk, and then use that area of physical memory for something else. When the process that used that memory area writes to or reads from it, Windows engages in some frenetic activity to load the data back from disk, into some memory area (could be the same, or other), and map the process' logical addresses there. The upshot of this is that in low memory conditions, the PC is transformed from an electronic beastie to a mechanical beastie, performing thousands and millions times slower. Ungood -- but when RAM sizes were small people thought virtual memory was neat.

The main problem with virtual memory in today's Windows is that in practice it's almost impossible to turn that darn thing off. Even if there's only one "main" program running, and there's much more than adequate physical RAM available, Windows will proactively swap data to disk to be ready for when possibly that process may need even more logical memory. However, if this were fixed then something else would most probably appear in its stead; such is the nature of the Universe.

Answer 3

Your premise is incorrect. You most certainly can read the memory of another process in Windows. You just can't do it be dereferencing a pointer because each process has a different view of memory. This is necessary for a variety of reasons, but the most important one is to prevent a bug in one program from corrupting other executing programs. (Another one is to prevent address space from being a scarce resource.)