By Joe Barr
Originally published June, 1995

DMM 1. Dangerous Memory Model, a phrase coined by Phar Lap during the 1980's to draw attention to high-risk architecture used by competing DOS extenders 2. the architecture Microsoft used in the design of Windows 95.

Multitasking operating systems are more complex in design and execution than pure, single-tasking DOS. By definition, they have to be able to run more than one application at a time. Basically, each application operates as if it has the entire machine to itself. When more than one application is running, they have to share. The operating system provides for this sharing. The applications themselves don't know or care that this is happening. They read and write to various system resources as they always have, or at least they think that is what is happening.

Behind the scenes, the operating system is standing between them and the resources so the programs don't step on each others toes. If you have a Pentium machine with 16 meg of RAM, for example, and run OS/2 Warp or Windows NT, each program that's running is going to think they can use any and all of the 16 meg that's not being used by the operating system itself.

In reality, the operating system assigns each program a portion of memory, an address space if you will, and works hard to make sure one program doesn't clobber the data in another program's space.

Programmers familiar with IBM's mainframe operating systems know that S0C4 is code for "You Can't Touch That!" The operating system halts the execution of a wayward roaming application that tries to read or write to memory outside its own assigned space and issues the S0C4 message by way of explanation. Note that the naughty program wasn't allowed to succeed in the operation, so no other tasks are harmed by its obnoxious behavior. They have been protected by the operating system.

Users and programmers familiar with Windows 3.0 are familiar with a similar code: UAE, or Unrecoverable Application Error. Unfortunately, UAE was an after the fact kind of alert. Not only was the bad program killed, its victims died and it was time to reboot. Instead of being a "You Can't Touch That!" warning message, it was "Kiss your app good-bye!"

Microsoft promised to fix this in Windows 3.1, and so they did. They renamed UAE to GPF, or General Protection Fault. Not much else changed, though. A rotten app could still spoil the whole bushel. Even when users felt it was safe to continue, they often found later that the contamination had indeed been fatal. OS/2 made Windows look very much like a toy instead of an operating system primarily for this very reason. But even though vastly superior, even it is not completely bulletproof when it comes to errant programs crashing the system. Windows NT is champion of the personal computing world in this regard, even though it is too slow and bulky for most desktop usage.

Enter the hype about Chicago, aka Win95. It was to be an all new 32-bit solution. It would protect everyone from everything, 32-bit and 16-bit apps could peacefully coexist, multitasking would be smooth and flawless, and it would run as well in 4 meg of RAM as Windows for Workgroups. Granted, that's not very well, but still a worthwhile goal. Since the end of the Chicago NDA period, a number of facts have slowly surfaced which show the reality that is Win95 to be a far, far cry from the hype.

Andrew Schulman, author of "Unauthorized Windows 95", was the first to point out that once again, the emperor's new clothes were more gauze than cloth. His early testing clearly showed that underneath the new GUI beat the ancient heart of dear old DOS. Microsoft attacked Schulman in return, but admitted that much of the new was part of the old, and that design decisions had been made to ensure backwards compatibility. What it was was incredible. Microsoft was getting ripped in the press while its product was still in the hype-phase. This phase is sacred to Gates and company, it's where traditionally they perform the best. It's clear they are not used to being challenged in the press, their clout is just too great for most editors to stand up against.

Next came that black day when Nicholas Petreley (in InfoWorld) dropped another bomb shell. It seems that yet another legacy from Windows 3.x still exists in Win95: his beta release of Win95 locked up and crashed his 32-meg machine because it was "Out of Resources." Microsoft, red-faced and angry once again, attacked Petreley but admitted that it was something that needed fixing.

These two black-eyes are probably the reason that the much touted "400,000 copy Preview Beta" failed to sell out. Industry analysts like Will Zachmann and others put the actual number sold far below that, at between 50,000 and 300,000. I did my own market analysis by calling the sales line on the day before it was scheduled to shut down, just to see if they still had product to sell. The sales rep told me yes, I could still buy a copy until five p.m. the next day. He said he could not confirm or deny rumors that the sales period might be extended. They did shut it down right on schedule, as a phone call the Monday following proved. So my evidence shows sales stopped according to a schedule hour and day, not because of a sell-out.

Microsoft is quiet and defensive. They now claim to have shipped 400,000 copies by the end of May, but refuse to say how many of those were sales and how many were giveaways. One MS employee got huffy about asked what difference it made whether they sold them or gave them away, they still shipped that many. But he wouldn't answer the question of how many sold. And why should he? By keeping silent, the false reports in the trade press about the '400K beta selling out won't have to be corrected. The fact that soon after the Preview started shipping, an offering called REMOVE95.ZIP became one of the most in-demand items items on CompuServe.

But the most damning revelation of all, the fact that Win95 uses the DMM (Dangerous Memory Model) design, scorned by serious operating system architects since the 80's, first saw the light of day in an article by Matt Petrick in the Microsoft Systems Journal. One of the most fundamental decisions to be made when designing a multitasking operating system is to decide where to keep things. The cleanest, saftest approach is to keep the operating system, drivers, and applications in separate areas of memory so they won't clobber each other. If an rogue app can't touch the operating system, it can't crash the operating system. The higher risk (but easier to accomplish) choice is to put everything in the same address space. This is the Dangerous Memory Model.

Under Win95, every 32-bit app has its own address space. So far, so good. One Win95 app is not going to be able to poke its neighbor in the eye. As you will see, however, it can kick it in the shin and cause the operating system itself to drop all the apps it had been juggling. What's been revealed since the article in the Microsoft Journal, is that the first meg of each Win95 app address space is mapped to DOS. Oh, I know, Win95 is all new and doesn't rely on DOS, but trust me on this, it's under every 32-bit app that runs under Win95. And guess what? It's not protected.

Andrew Schulman demonstrated this conclusively with a simple little program that writes over the contents of the first meg of its address space. When it hits a vital organ, it kills Win95. Microsoft argues that most application errors that would cause a program to write to this part of the address space would be caused by a null value in a pointer, so it saw no need to protect more than four thousand of the more than one million bytes at risk. Later builds of the Win95 betas have raised this to 64 kilobytes.

That's the low end of the address space, where DOS lives. The upper end, way up near the top of virtual memory, is where the 32-bit operating system code lives. Actually, it is a collection of VxD's (Virtual Device Drivers, sort of later day TSR's for you die-hard DOS hackers) that make up something like a kernel of a 32-bit operating system. Disk buffers and caches, ring-zero code, stuff that just has to be protected, right? Wrong. Imagine your surprise when you scramble all the data on your new 1-gigabyte hard drive because some app went bad and wrote over the contents of your disk cache.

By this time, it should be very clear to you why Brad Silverberg, the trash-talking MS big-wig, said last year that Win95 should not be used for mission critical applications. This is not a step forward, folks, or if it is, it is off-set by two steps backwards. Win95 may destroy all the credibility MS has left. It also seems clear they seem to be dead serious about releasing it in time to be on the shelves in August. A report just a day or so ago said that the code had been frozen and that over three thousand of the known bugs would not be addressed in the first release.

This looks very bad for Microsoft. Another dangerous memory model is one which assumes that the public will forgive and forget a very late, very buggy, very unstable Win95 and just wait around for MS to usher its next great product, code-named Daytona or Cairo or whatever, onto center stage. I'm sure that, buggy or not, Win95 is going to sell a lot of copies, at least at first. But if it really is as bad as it appears to be at this writing, it may be the most expensive 'successful debut' ever, and the greatest boon to the telephone-support industry ever seen.