Understanding Memory Protection
Memory protection is a way for an OS
to protect bad applications from harming other applications
or the System. Applications use Memory,
and an application with bugs can often go gleefully romping
out of its space, and romp all over its neighbors memory
(causing the neighbor to crash).
is Memory Protection for what the different
types of memory protection are, and how they
Remember that Memory Protection is just a set of tools to
help make the OS more stable -- assuming that programmers
have already failed in their job of writing quality
(relatively bug-free) Apps.
When an Application crashes (or crashes the System) it is
95% the fault OF THE DEVELOPER! It is not the
System's fault. The System can (and should) help
prevent an App from taking down other Apps or the System
(and camoflauge the symptom), but it can almost never stop
crashes completely, nor can it cure the problem (which is a
poorly written app). We should not make excuses for bad QA,
bad development processes, and lazy programmers(1).
We should blame companies who don't test their software
enough or who don't value quality Apps enough! There are
plenty of good tools to stop these crashes (find those
bugs), if Developers would take the time to use them.
(1) In fact, this is one of my major problem
with Windows in general -- that it seems to attract far
more "go with the flow" type developers that hack
something out, rather than doing it right.
I'd say that half of all Windows
developers have the old DOS "just hack it together"
attitude. The other half varies. I know many good DOS/WIN
programmers, but the worst code and designs I've seen
have come from DOS/Win programmers.
I'd say that about 75% of all
Mac programmers are good -- after all, they are good
enough to CHOOSE their platform (instead of just
following), and they are principled and opinionated
enough not to just whore themselves out for a buck, or go
with the flow. If you take out those MacProgrammers that
are really left-over DOS programmers (working at MS,
Netscape or Novell) then that number of quality
MacProgrammers would jump to 90-95%. (There are good
people at Novell and MS -- it's just that the worst
programs I've seen has come out of those companies. It
may be because their management just doesn't care about
quality -- but I'm pretty hard on programmers who don't
take the time to do what is right).
For the drawings, green memory is "safe" (protected) and
yellow memory is "open" (Danger Will Robinson! This area can
be stomped).The blue areas is where no-memory is mapped, so
Both MacOS and Win95 have many "modes" and behaviors. So
I must generalize quite a bit. Both have exceptions (Windows
has far more than the Mac). All the memory maps are only to
give general ideas of what is going on, and are not
completely "pure". Both machines have memory maps are more
complex than expressed.
MacOS 7.x & 8.x
There are a few modes in the Mac -- basically I describe
new Mac programs, using the CodeFragmentManager, with
Virtual Memory turned on.
On the Mac all code blocks are protected as read only. So
Code segments in the System AND all Applications are
protected from one another (this started with the PowerPC's
and something called CodeFragmentManager, which has been
ported to the 68000's). Devices are usually mapped to
In the Mac jumping to an odd address is a failure
(2) -- so jumping to a bad address (at random) has a
greater than 50% chance of failure. (This is why I show the
yellow areas as striped -- bad addresses are half
protected). Memory failures are detected if you go into the
memory map where there is no RAM available (most of the
memory map -- all the blue area -- which is much larger than
it appears) (3).
(2) If you have ever
seen a Type-2 error (bad address), that is because a
program tried jump to an odd address.
(3) If you have ever seen
a Type-1 error (bus error), this is because a program
tried to access another program's code, or tried to
access an area of the memory map where there was no
BOTH of these examples are
proof that the Mac has SOME Memory Protection! The
Mac's protection may not be as full featured as it should
be, but it exists.
The Mac also has stack-heap collision detection (60 times
a second, the Mac checks to see if the stack has walked into
the heap -- if it does then you get a Type-28 error). The
Mac also protects a few areas of memory completely; the RAM
disk exists completely in protected memory, and some files
(mostly System stuff) are "file-mapped" and protected.
Overall the System is not FULLY protected -- so an
App can stomp on another app's data (but not code) -- at
The Mac has great debugging tools to help catch all of
these errors at debug time. The Mac even has full memory
protection for developers (to help detect errors). At
debug time the Mac can even do parameter validation to help
programmers get all the bugs out. But these tools are
performance intensive and impractical for users. The problem
is that many aren't using the tools that are
available (again see those at MS , Netscape and Novell--
even Adobe and some others deserve blame here).
Some tools that do a form of memory
protection for the Mac, include:
- EvenBetterBusError -- puts a
guard page at location zero (the most common memory
- MacsBug has a few DCMD's to
excorcise memory and do bounds and leak
- Jasik Debugger can do memory
excorcising and check bounds and leaks.
- Q.C. moves memory around and
- Spotlight is an excellent
tool to "protected" memory (inter and intra
application), and detect for leaks and overwrites. (We
are running some of our Windows programs through it,
and have found a few nasty memory bugs that had
existed for years!).
is a programmer's version of the Mac's memory manager
that helps developers find bugs.
- Many more
The problem is that many
developers are not using the tools they have, and not
spending the time to debug their Apps! Even Apple is
guilty of being lax.
Win95 / 98
Windows is a kludgy Operating System, built on a kludgy
processor, with lots of kludgy hacks. There are a few rules,
and many exceptions, and literally dozens of modes. So it is
hard to say what it does, or doesn't do -- because
everything is sometimes true, but usually not true.
An example is addressing:
Different instructions have many different ways of
addressing memory, some old and ugly, some new and clean.
It is quite frustrating to work with -- and helps add
bugs to Applications (and causes more need for memory
On the Mac there is one way to
compile code -- 32 bit (clean). Or you could say for two
targets PPC or 68K -- but you can mix both into one "fat"
application. On the PC there are like 6+ addressing modes
(near, far, yada yada), and 32 bit or 16 bit. That isn't
even counting the 4 or 5 variants of 16 bit Apps and
memory models (like Extended, Expanded and so on). Most
legacy machines still run 16 bit only. There are two or
more flavors of 32 bit Apps (Win32 for Win95 and Win32
for NT, and Win32S for older machines which never worked
right). Then you can optimize for Pentiums (and take a
performance hit on all older machines), or optimize for
486 using either 32 or 16 bit instructions, and so on. It
is a nightmare.
Windows is still slapped on top of DOS (and still has
some 640K limits and other legacy "uglies"), it is just that
MS has hidden the symptoms of the problems better. But
camoflauging symptoms is not a cure!
32 Bit Apps
In Windows a 32 bit app is protected from squashing all
other apps (and much of the System). But Windows
Applications can write over their own code (code is
not always read-only). This is because some
programmers in Windows world still use self-modifying code,
or have data embedded inside their code (both bad
programming techniques). This reduces the intra-application
COM / OLE / ActiveX, DNA (or whatever it is being called
this week) forces you to share small parts of your memory
with other Apps (and the System) -- opening up security and
data holes. So 32 bit Apps can crash other apps if they
aren't real cautious about these "gaps". They also can do
the same thing with Libraries, and they can often have full
access to the System (and can often corrupt the System or
other applications). Libraries are also NOT unloaded
when an App quits -- so there are serious security holes
there as well,but let's stay on memory protection for
There is some System protection, and there are guard
pages in lo-mem (more than MacOS 7/8). However, Windows uses
lo-mem global pools of shared data (across applications).
The "pools" have information about all the Windows, Menus,
graphics and other resources. This is another reason why
Windows has such lousy security -- anyone can access other
people's resources (but I'm getting off track). All
applications and the system have access to those shared
"pools" (e.g. no memory protection for them). If programmers
make an error in these pools, they can easily squash
structures that other apps need. A program can also "leak"
(4) and fill up all available space in those pools
and crash the System and other Applications. So an App's
code and most data has protection, but its most critical
resources often do not.
(4) A leak is where an program asks for a structure
then forgets (or loses) its reference to that structure
-- so even though the structure (memory) has been
allocated and is taking space, it can not be found -- so
the App has to get a new instance of that structure
(which may forget, and so on). So that "leaked" memory is
lost until the System is rebooted (or sometimes until the
Application is quit).
Macs don't keep data in global
pools, and instead keeps an app's data in the application
space. So on a Mac, a leaking App can run out of its own
memory and crashes the App. On Windows a leaking App can
run out of System Space (global pools) and crash the
There is limited stack-heap collision in 16 bit Windows
(done less frequently than on the Mac) -- but I'm not sure
about Win32. There is less intra-Application protection for
Win95 (compared to the Mac) and COM / OLE make this much
worse. This is all compounded by worse developer tools
(there are many tools for Windows, but most have lower
quality and worse documentation, etc.).
Even despite the negatives, Win95 has pretty good memory
protection for 32 bit apps -- if this was all there was. But
there are a lot more negatives to this story!
16 Bit Apps
In Windows a large number of Apps are still 16 bit -- and
so are many drivers (and parts of the System). All DOS Apps,
most Games, and all legacy Apps are 16 bit. Even many new
apps, use older 16 bit libraries, drivers or TSR's and so
on. When running the 32 bit apps, you get the memory
protection -- but when you run the 16 bit Apps (or
libraries, or drivers...), the memory protection basically
evaporates. (There are ways to protect, a little, 16 bit
apps, but that is not the way they work by default).
As soon as a 16 bit App or driver kicks in, the memory
protection turns off. It is also not obvious to the average
user which Apps, drivers or parts of the System are 16 bit
-- so they can't tell when they are endangering their
There is better System protection in Win95 (for 16 bit
apps) than there was in Win3.1 (some low-memory protection,
and larger global pools to reduce how frequently the apps
run out of space) -- and things have improved since Windows
3.1 (a little). But a 16 bit App can definitely step on any
other 16 bit app (5).
(5) I am NOT sure if a 16 bit App can stomp on
any 32 bit app. I know that 16 bit apps can stomp other
16 bit apps, and the System. I know that 16 bit drivers
can stomp 32 bit apps. I know there are instances where a
16 bit App can stomp a 32 bit app (like using COM / OLE)
-- but I don't know if they can just stomp anywhere on a
32 bit app. If you bring down the System, it won't really
matter that the App is OK anyway. Microsoft isn't very
forthcoming about this information, and has been so
disingenuous in the past that you can't trust them
anyway. There are many books that explain what is really
going on by testing, and they disagree with what
Microsoft says they are doing.
Overall Windows95 / 98 has blotchy protection. 32 bit
apps aren't bad, 16 bit apps are.
I have found most of the Windows developer tools are
inferior to that of the Mac's, causing much more difficulty
in creating good programs in the first place (and increasing
the need for memory protection). They also slow down
productivity in general (like having to debug in a postage
stamp sizedWindows on the PC -- as compared to multilple
monitor support, and multiple Windows on the Mac). To
further complicate the issues, MS has some of the worst
documentation that it has been my misfortune to work with
(poorly written and often WRONG). Then you often have to
pick different tools depending on whether you are writing 32
bit Apps, or 16 bit Apps (Microsoft abandoned 16 bit
developers and won't update their tools). Then there are all
the pitfalls of using the wrong technologies on Windows.
Like when Microsoft made something called Win32S (a way to
run Win32 Apps on 16 bit Windows), except it doesn't work,
and never has. Developers only found that out after
investing up to millions of dollars to learn the hard way.
Of course there are about 10 other technologies that
Microsoft promised that never worked as well. (At least
Apple gets the technologies working before they stop
developing them -- which is quite different).
Microsoft doesn't care about these errors or complexities
because it generates them more revenue answering developer
support questions -- which have much higher fees than Apple
has on the Mac side. Plus, if Microsoft can make it harder
to develop for Windows, it increases their competitive
advantages! This is compounded by an OS that has lots of
"undocumented" features/behaviors which increase the
likelihood of an error, and the need for memory
One of the most glaring
examples of how bad Windows Development really is, is
developer productivity. In the last couple cross-platform
companies I've worked at, the Mac teams are often half
the size of the Windows teams. Still the Mac progammers
not only achieve feature parity, but often feature
superiority. All while releasing more quality products --
and sometimes on tighter schedules. And I don't think the
Windows programmers I worked with are the bad ones --
many (most) seemed highly competant.
Overall, I am surprised by how stable Windows 95 is, in
spite of its many glaring flaws -- which implies that I may
be too hard on DOS/Windows programmers. (I still think of
most of them as either ignorant, masochistic, or whores. I
just know that I can't stand working in Windows because of
how kludgy and "unclean" everything is). But surprisingly,
if you get a Win95 machine installed correctly (which can be
quite a chore), and you don't change your configuration (add
any devices or change software), it can be quite stable. It
can just be a real pain to get it in that stable state.
What people really care about is overall stability.
for more] Users don't care how you get there
(stability). In fact, there is a lot of proof that Memory
Protection is NOT the only key to perceived stability.
To improve perceived stability between System7 and MacOS
8, Apple just remapped System Errors (often memory
protection violations), so the System now just terminates
the Application, and goes on -- instead of halting the
System. People see the System as much more stable (even
though Apps crash as often as before) -- yet there was no
real change to memory protection. There are many other
ways to improve stability without memory protection.
Those should be explored, as well as Memory Protection.
Windows95 is not really as stable as many pretend -- and
the MacOS is not as unstable as those same people pretend.
You can destabilize a Mac by adding lots of Inits and
extensions -- but in most cases you can't even get complex
configurations with lots of TSR's and Drivers to work right
at all in Windows95 -- and you need professionals to
configure and Fix PC's far far more often. Which is more
The real problem is that people are willing to try much
more, or install much more, on their Mac -- which leads to
more instability. They put on UI-replacement tools, or
Speed-Doubler, RAM doubler (which changes the memory model),
or other tools that alter the system-- then wonder why the
System is unstable. These are all things that aren't even
possible in Windows. Windows users are too scared to try
most of this (with simpler stuff), or they don't have the
tools in the first place -- and so are less likely to have
the problems that come with that power and flexibility.
In both environments there are bad Apps -- which cause
- On the Mac you have to watch your use of Inits and
some utilities that "patch". You can make your System
crashy by using almost anything from Microsoft, Novell,
and Netscape Navigator is not that great. Adobe does a
lot of quirky things and doesn't always play by the
rules, but they try to keep up to date. If you reduce
your use of these Apps it is amazing how stable a Mac is.
I've run Macs as servers for
months without a crash -- longer than most Win95 machines
can survive. So the Mac is stable by default
-- it is just a few bad Apps that can make the System
touchy. Instead of people blaming the product they chose,
they blame the Mac. My company has a pretty unstable
network, thanks to Novell. If I turn off Novell, I can
run my Mac for weeks without a crash -- if I turn it on,
it fails about once per day, this is NOT Apple's
fault. The IS guys often blame the Macs <sigh> -- I
guess that is easier than blaming themselves (for
choosing Novell Netware and GroupWise).
- On Windows the irony is that Microsoft Apps are often
the most stable -- probably because Microsoft makes the
OS,. MS programmers are the only ones can use all those
undocumented (or poorly documented) behaviors (or they
can patch their OS to adapt to their Apps) -- so they
seem to be the only ones that can write really good
Windows apps. Novell products are far better on PC's than
on Macs but it is still no surprise they are dieing. Of
course on Windows95 you must try to avoid all 16 bit
Apps, which leaves Win95 with a smaller selection of Apps
than the Mac has. You should basically avoid most
anything NOT by Microsoft or a couple of others, because
"you just can't be sure". But when you live within these
boundries, you are very limited in software and machine
usability -- and often still find that you need
someone else to "support" you to keep your machine
running. Not to mention all the protection you need from
Viruses. This may be why IS/IT loves PC's... Job
The point to all this is, that stability has as much (or
more) to do with the quality of the Applications that you
are running (and configuration), and the quality of the
System as a whole -- not just memory protection.
Memory Protection is still a
valuable tool (especially for developers at debug
time), and Systems CAN be more stable with it than
without it -- but never forget it is still only a small part
of a complex equation that results in System stability.
Both companies could have made their OS's far
more stable than they are now, WITHOUT memory protection
-- and both need to.
Both OS's could use more memory protection than
they have right now -- and they need to. Personally,
I'd still rather that they spent more effort in other
areas that would help stability even more -- but they
need to add better protection as well!
The argument that Windows95 is more stable than MacOS
because it has memory protection is wrong on both counts. I
find it less stable, unless you are very selective (and
limited) -- but when you put the same criteria on the Mac,
you get the same results (more stability). Also, the
System's stability has a little to do with the memory
protection -- but also has more to do with application
quality and other issues. And I still find Windows Memory
Protection is inferior to the Mac's in many ways (and
superior in few).
I do know that a good
article would be to follow this one up with WinNT vs
Rhapsody/Unix. The trouble is the specifics are far
harder to get than on MacOS vs Win95 -- and I don't get
down and dirty as much any more (because I don't have
to). So it may happen, especially if someone who is a
good low-level cross platform person wants to