What does unprotected code on the win32 platform mean?

Question

Windows

Here is a quote from Flenov's book.

The Win32 platform was often criticized for its insecurity.
It really has a very weak link - the insecurity of the code and the ability to overwrite any part of the memory.

What kind of insecure code? In simple terms, if possible.

Answer 1

In a simple way. Insecurity means that any program has access to "any" area of ​​memory, not even its own. Those. a third-party program can get into the memory allocated for another program and do whatever it wants there.
There is also clr in it, this problem was sort of solved by moving the execution of the code into a "virtual machine" and, accordingly, each program has its own individual piece that no one else can touch.

Answer 2

It really has a very weak link - the insecurity of the code and the ability to overwrite any part of the memory.

This is indeed a disadvantage in some cases, and in some it is a huge advantage. Strong link in the system.

Answer 3

Perhaps it means the implementation of winapi back in the time of the win9x line, when there was no protected memory as such. Yes, there was an OS vulnerability when any program could operate with system resources and memory.
In the NT line, each process and its memory area is protected.

Answer 4

There are a lot of answers to this question) Because the question is highly generalized.
For example, you can answer like this: in win32, the memory descriptor is written poorly. Win64 is better.
But win64 requires a 64-bit processor. That's where everything comes from.
If there is a 64-bit processor, then it has "in hardware" for example nx-bit. And the 64-bit descriptor is written, as it were, for it, if you pull too hard behind the ears. In total, it turns out that the code and data are separated. And iron takes care of it. Those. you can't run code from data.
And on 32-bit systems, this could be done easily, through an overflow error. Those. insert the executable code into the picture, the picture into the program, and run the code from the picture with the program. Earlier, in the days of 32-bit, protections were built on this in large quantities, and exploits were distributed in exactly the same way.
In a general sense, 32-bit systems have no code execution control. 64-bit already have. But this business also needs a sane organization of memory. In modern versions for example win-64 it is. However, it is also available in all 64-bit systems, as far as I remember. Implementation is already screwed everywhere.