Hello,
Well, I can try and clarify. Yet The Owl knows more than me on this issues, so
I'll bet he'll have something to add as well.
The best way to learn about the win16mutex is in matt pietriek's windows
programming secrets. That book is highly recommended, the guy did an awesome
job reversing many internal mechanism in windows.
In short, when MS set out to design win95, they wanted to make an OS that
will be new, and yet will be able to be backwards compatible with win3.11 16bit
programs. One other important design consideration was that they (apparently)
didn't want to rewrite all the windows internals code. For obvious reasons, that
code was much more stable than a newly coded system from the ground up.
So what they decided to do is to somehow build upon the win3.11 16bit libraries
with some more 32bit libraries. In fact, most of the real work of the OS is done
in those old 16bit libraries, which are also apparently, are not entirely 16bit, but
rather a hybrid. In any case, for the reasons mentioned earlier, 16bit memory
cannot be protected like 32bit code using hardware, and maybe some of those
libraries use functions that are non-reentrant (which sounds all too acceptable,
but I'm not certain on this point). In that case there would be a synchronization
problem in the OS when multiple threads execute the same lines of code in the
16bit libraries. It's basically like you can't use a function that uses a static
variable of any kind, if you expect multiple threads to run through it's code at
the same time (which can happen, since a thread has among other things it's
own register set, stack pointer, stack, etc..). MS decided to solve this sync
problem using a mutex. They called that object the Win16Mutex. Each thread
that would have to enter 16bit code will have to acquire control of the mutex
before continuing, and if a different thread is currently executing in 16bit code,
it has the win16mutex acquired so the other thread is put to sleep.That way MS
solved the sync problem with the 16bit libraries, which of course hampered
win95's multithreading. Apparently, as pietriek noted, it is possible to do some
weird things while you obtain the mutex, and in general, since 16bit code has
to be global to all processes, and many important things like window handles
and gdi object handles are stored in those libraries data segments, a process
can do great harm to the system.
I hope that clarified that a little.
You mentioned a process can't access memory outside of it's space with a
weird pointer. Well, that is true in general, but is not a 100% sure thing.
Since the 32bit libraries are also mapped globally, a badly pointed pointer (sorta
speak hehe) can do harm to the system. In fact, it's all too easy to cause
harm to the system or other processes if you try. On top of that there are
the XXXXprocessmemory functions (read and write), which give you a great
deal of power in your hands, since all processes in win9x are created equal,
and there are no security limitations
If you survived this long typing endeavor, i salute you my friend ;-)
ciao,
LS