Yes ... it seems to be baked into their DNA, right from the beginning when they gave Win16 DLL's their own private execution space that was shared across all programs that were using it.

I was under the impression that Win16 was a shared address space environment anyway (e.g., when kicking off an application, you received an instance handle to the previously-and-still-running instance of the same program). That didn't change until Win32. Am I mistaken?

Right ... but if two or more different Win16 programs were using the same DLL, the DLL had access to its own address space as well, and it was shared between all of the programs. This made it possible to trick a DLL into leaking data between programs, or at best, crashing all programs that were using it.
I wish Ford were here to explain it; he knew this stuff pretty well.

But of course we know that Win16 wasn't a real operating system anyway. Win16 programs were basically just MS-DOS programs that had access to a rudimentary GUI and some extra libraries.

I think Win16, like, the original Win16, didn't have a concept of multiple users or anything. It expects a single-user environment. When Win32 came along, it created a kind of emulation layer for the Win16 environments that segregated them into different environments.

But...

... because Win32/Win64 have a single kernel, and the way that kernel works, yadda yadda, the different Win16 environments are really only separated by the way memory gets managed, not by the functions that enable this segregation.
So, if you compromise the kernel just so, you could pretty well do heinous things within the different win16 spaces.

Now, I forget how DLLs play into all of this. It feels like there's only ever one DLL in the environment, shared by everyone else, until the last process unloads it, but then, I don't think that's quite accurate, because I recall hooking a dll in one process but not having it hooked in another. OTOH, hooking would just mean for this process, call these functions instead of the DLL functions, so maybe that still makes sense... you'd probably have to figure out how to trick the kernel into interpreting the dlls function locations or something. I forget. It's been a while since I had to know this stuff.

Win16, as of Windows 3.0, sat inside a VM, just as DOS VMs did. So while you could compromise KERNEL.EXE or GDI.EXE, you would only end up compromising that Win16 instance. They never used VMMs to enforce protection; but nothing fundamentally *prevented* it from happening.

because Win32/Win64 have a single kernel, and the way that kernel works,

yadda yadda, the different Win16 environments are really only separated by the way memory gets managed

This is as true for Linux as it is for Win16 too. It just takes more work to compromise the system, but it's definitely doable. Both with and without virtualization (easier without, of course). Escalate to root, take control of your target process by way of ptrace, and have all the fun in the world.
Or, take subtle advantage of virtio handlers to break out of your jail, ... viola! A musical instrument!

Memory protections were weak to nonexistent even in Windows 3.11 running in 386 Enhanced mode. Features of the 386 processor were used in order to implement virtual memory, but processes could easily write to shared state in DLL's, and I believe another Win16 process's data segment if you had the right pointer.

I believe that basically, the Win16 runtime environment was mapped onto one single 386-mode memory space. Processes in virtual DOS boxes would have had to have their own spaces, but all Win16 processes shared the same space.

Interesting reminiscing on that: https://blogs.msdn.microsoft.com/oldnewthing/20171113-00/?p=97386

Old PC Mag article on memory protection: https://goo.gl/ioVdHQ

aaaaaaaack ... I forgot about the thunking layer. How horrifying.

What LoanShark said about Win16 processes vs DOS processes is what I remember as well; this is why I said earlier that I thought Win16 was a single address space, but Windows 3.0 and later had use VxDs and a VMM to isolate different virtual machines. Win16 was one (shared) VM, while each DOS box was an independent VM.

...and Quarterdeck ran circles around Microsoft in every single operating mode. It's too bad M$ didn't acquire that technology in one way or another (either by licensing it or by buying the company). It would have saved a lot of people a lot of pain over the years.

Considering MS's history of buying competitors and then shelving the key technologies that they purchased, I am skeptical that that would have helped in any way.

Unfortunately you're probably right. I'll just reiterate what I've said many times before about how they should have just stayed the course with Xenix.
All problems would have been solved (including reliably running multiple DOS programs).

Yep, I totally agree. Xenix was a great system once. They were fools to ditch it.

I think I might have mentioned this before ... many of the features in MS-DOS 2.X were intended to mimic Xenix because their intended long-term migration path at the time was going to be towards Xenix. Then they got distracted by the Mac and went down the OS/2 path, then got greedy and ditched the parts of OS/2 that actually made it work well.

So sad. Xenix would have ruled the world and no one would really have complained much about it.

The same was true for Linux at one time. Filesystems can be improved or replaced without gutting the whole OS.

There is no better file system than NTFS when it comes to survivability of an unexpected shutdown. Which is good, considering how unstable Windows was.

I've heard NTFS described by a developer who worked on a defragger for it as 'slowly unravelling your data over time.'