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 (ie 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?

PS 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 not 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, ie 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 , eg 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 slooooower. 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.

Cheers & hth.,

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.)

Answer 4

You make it sound like you think memory protection is a bad thing!?

Uncontrolled access of one process's memory from another would generally lead to bugs, crashes, undefined behaviour, and more critically perhaps would be an open door to malware and viruses. You may write two processes that cooperate through shared memory nicely, but equally any other process either by error or maliciously could also access it. Moreover it would be very easy also to trash the OS kernel itself.

Win16 ran originally as a graphical environment rather than a true OS on top of MS-DOS and was designed to work on early 16 bit x86 processors without an MMU to allow memory protection. The Win32S API was introduced later into Windows 3.x which provided a subset of Win32 features on Win16. Windows32 (originally Windows NT then concurrently Windows 95) takes advantages of features introduced with the 80386 to provide each process with its own memory environment invisible to any other except by invitation.

This is what made Windows NT more robust that Win3.x. Windows 95 did not make full use of the protection mechanisms presumably for some level backward compatibility, so while more robust that Win3.x, it was not nearly as crash-proof as NT. Windows XP was the first "consumer" Windows OS to use the Windows NT/Windows 2000 code base, and discard much (but not all) of the Windows 95/MS-DOS compatibility baggage.

If you wish to share data between processes the correct way to do it is through any recognised IPC mechanism . One such method is in fact through a memory mapped file, which is exactly a shared memory block, but with access controls so not just any process can see the memory.

Answer 5

Well if you can mess around in the ram area of other processes it's an easy task to crash it. Eg you just have to set some pointer to NULL and the process will be gone. And well RAM are "private" parts of every process and you don't want anyone to access them won't you? Yes there is some way to access that probably if you do some kernel debugging.