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

Question

Say I'm sending a pointer as an argument to another program:

program.exe -mypointer 

and try to use it in this program, it will not work. After some research (for example, in C ++ Lounge), I found that with Windows 95 you cannot access the address space of another program. In older versions of Windows, this was allowed. My question is: why did Microsoft ban it? What were the problems or disadvantages of this?

PS Is it possible, if done, in new versions of Windows?

Answer 1

Since access to the address space of other processes means that you can split them, for example, by accidentally changing the contents of your memory.

All protected mode - protect processes from each other. See the Wikipedia security page for more information. In the bad old days before the defense, it was much easier to write code that distorted other processes.

The disadvantage of this is that some errors in MS Word made it much easier not just to break MS Word, but also Excel, Borland C, your PI number calculator, which worked over the past six weeks, and even the operating system itself.

You can still access another process address space, but for this you basically need to work with higher privileges. For example, this is how debuggers allow you to start a process and access all your memory for debugging purposes.

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

Answer 2

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

Thus, in 16-bit Windows processes, the general form of memory is preserved.

One problem is that the address space of shared memory is not so large when many processes want to have their own chunks.

In addition, it is too easy for processes to stumble on each other's legs.

Windows offered some partial solutions, such as the ability for the process to inform Windows about when it actually used any memory (the process then locks this memory area), which means that Windows can move the contents of the memory around if necessary, free up space, but it was all voluntary and not very safe.

So, 32-bit Windows, Windows NT, used the new processor memory management to automate the best practices that Windows 16-bit programs should use. In fact, a process only deals with logical addresses that the processor automatically translates to physical addresses (which this process never sees). Well, on a 32-bit PC, translation is a two-step business, i.e. Internal intermediate form of address, but this is a complication that you do not need to know about.

One of the nice consequences of this hardware address translation is that the process can be completely isolated from knowing which physical addresses it uses. For example, it is easy to have two processes of the same program. They think they are dealing with the same addresses, but these are only logical addresses; in fact, their logical addresses translate to different physical addresses, so that they do not stomp in each other's memory areas.

And one of the consequences that we can say about a 20-20 retrospective assessment is not so nice, is that the translation scheme allows virtual memory , for example. to simulate RAM using disk space. Windows can copy the contents of the memory to disk, and then use this area of ​​physical memory for something else. When a process that uses this memory area writes to or reads from it, Windows engages in some frantic activity to load data from the disk into some memory area (it may be the same or different) and maps the logical addresses of the process there. The result of this is that in the conditions of low memory, the PC turns from an electronic beastie into a mechanical beastie, performing slooooower thousands and millions of times. 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 disable this damn thing. Even if there is only one “main” program, and there is much more than enough physical RAM, Windows will actively change data to disk to be prepared for the possibility that even more logical memory might be required for this process. However, if this were corrected, then something else would most likely appear instead; this is the nature of the universe.

Cheers and hth.,

Answer 3

Your premise is incorrect. You can certainly read the memory of another process on Windows. You simply cannot do this by dereferencing a pointer, because each process has a different view of memory. This is necessary for a number of reasons, but the most important is to prevent errors in one program from corrupting other executable programs. (Another one is to prevent a lack of address space.)

Answer 4

Sounds like you think memory protection is bad !?

Uncontrolled access to one process memory from another usually leads to errors, crashes, undefined behavior, and, more critically, it may be an open door for malware and viruses. You can write two processes that interact well with shared memory, but equally, any other process, either by mistake or with malicious intent, can also access it. In addition, it would be very easy to also destroy the OS kernel.

Win16 was originally run as a graphical environment, not a real OS on top of MS-DOS, and was designed to run on early 16-bit x86 processors without MMUs to provide memory protection. The Win32S API was introduced later in Windows 3.x, which provided a subset of Win32 features on Win16. Windows32 (initially Windows NT and then Windows 95) takes advantage of the features introduced in 80386 to provide each process with its own memory environment, invisible to any other than an invitation.

This is what made Windows NT more reliable than Win3.x. Windows 95 did not fully utilize the protection mechanisms, presumably for backward compatibility at the same level, therefore, while more reliable than Win3.x, it was not as robust as NT. Windows XP was the first “consumer” Windows operating system to use the Windows NT / Windows 2000 database and dropped a lot (but not all) of Windows 95 / MS-DOS compatible baggage.

If you want to share data between processes, the right way to do this is through any recognized IPC mechanism . One of these methods actually consists of a memory mapping file, which is a shared memory block, but with access controls, so not only any process can see the memory.

Answer 5

Well, if you can mess around in the markup area of ​​other processes, it's easy to handle it. For example, you just need to set some pointer to NULL, and the process will disappear. And well, RAM is the “private” part of every process, and you don’t want anyone accessing them, do you? Yes, there is access to this, perhaps if you do some kernel debugging.