Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
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 his neighbor. Think of what your dog might do on you neighbors front porch - and how your neighbor might respond. Baaad dog! Well that's software development.
All Applications and the System are running in RAM at the same time - think of a table top (RAM) with different drawings (applications) spread out at the same time. Now imagine a few people are working at the same time on different drawings, and someone spills ink -- and it not only gets all over his drawings, but also your drawings, and gets ink on the desk. The other victims of the spillage are going to have a tough sell on a tight schedule explaining that "my dog ate my homework". That is life without memory protection. People often blame the wrong application for the problem, and one bad MS-programmer can spoil it for everyone else.
Preventative Medicine
Better Tools - If you make better tools for the artists (programmers), so that the ink bottle that won't spill as easily, or give the artists ball point pens, etc., then you don't need to worry about the ink spilling (as much). That is the first part of the Mac solution and an area that Windows is woefully lacking. Apple (Mac) often has excellent tools for preventing the problems before they happen - and special tools to help programmers find little spills they might be making, or prevent them from spilling up front. This makes the likelihood of Macs crashing and harming their neighbors much less likely. And Macs often have really good tools for clean-up (debugging) and for exercising (exorcising) code of the bad behaviors and bugs in the first place.
Better documentation - Apple also has much better documentation (than Windows) for how things behave - and better than that, things actually do what the documentation says (people who've programmed Windows know that this is only sometimes the case). Imagine all the people working on the group project had a document (rule sheet) to remind them of how to handle the ink so that they do NOT spill it. This also reduces the likelihood of a spill. This documentation superiority means that programmers write fewer bugs (or artists have rules to prevent spillage) - and so the problem appears less on Macs than on windows.
Better training (discipline) - Apple also has much more disciplined programmers (in general). Mac programmers tended to jump to the Mac for its structure for a reason. Windows programmers often grew out of DOS hacking and anarchy. So the Mac has rules written down (documentation) and a user base (programmers ) that are more likely to follow those rules. This means less spillage. Imagine all the people working on the group project were trained NOT to spill the ink, and always capped the bottle so it would not spill. Things are safer. Mac users generally cause fewer spills because they can train themselves easier (documentation) and they are used to the rules (disciplined).
However, these issues only work if your programmers pay attention to the rules. Also you can note that the worse your application writers are, and the worse the tools that developers have, than the more the OS needs memory protection. This is one of the key reasons why MS is making such a big issue about memory protection in the first place - Windows needs it really badly, and now that lots of the slovenly undisciplined Windows-types are writing Apps for Macs - the Mac is needing protection more than in the past as well.
How Full Memory Protection works
The final solution (pun intended) is memory protection. Imagine that same table top with 4 people trying to work at the same time. Now imagine the table covered in 4 separate sheets of glass. When artist #1 wants to work, he can step up to the table and remove his piece of glass, and work on his exposed drawings - but before artist #2 can work, artist #1 must put the glass back on his part, cap the ink bottle, and step-away from the table. That is memory protection. The artists aren't even allowed to talk to each other - they must mail things to each other. (No direct contact allowed). This forced discipline almost guarantees that one worker can not harm the other workers - but it does cut down on productivity (computers are fast enough now days that this loss is not noticed by the users). That is not to say it is not a good idea - but it has an inherent overhead (performance and size). Memory protection is the same thing - one application can not touch any part of the memory map but its own (safety glass everywhere). It can't read, can't write to it, and any attempt to do so is a security (access) violation and will bring that application down immediately - "bad dog!".
So the costs of memory protection need to be looked at realistically and historically. 17 years ago when the Mac project was starting out, and the Mac had only one application (and a couple of desk accessories) running at one time -- memory protection was not needed and in fact would have harmed the acceptance of the Mac. (It can increase memory demands for both the system and applications, it slows performance, increases cost, and causes nuisances for programmers). But in todays world of computers (literally 1,000 times more powerful than the initial Macs) and with users running many applications simultaneously , and DOS-programmers infecting the Mac with their evil ways - it has become a necessity.
Partial Memory Protection
Many systems are not perfect and don't protect everyone and everything from everything else. A full memory protection system has a microkernel that is the ONLY part of the OS with access to multiple address spaces at one time (and that is only for mailing messages). Some Unixes are like this, WinNT is not - Win95 is not even close.
Usually OS designers go for some compromises to increase speed. They allow the OS and the drivers to walk around freely in memory. This is a slight step back in full protection - but allows quite a bit of security, and if your OS is stable - then your system should still be pretty stable. This is how WinNT works - with some other compromises on full protection as well - but NOT Win95 or Mac (which have more compromises still).
Some Systems share certain global resource pools (variables, etc.) among multiple Applications. This means that they are sharing one page of notes, and if anyone spills on that page, everyone looses work. Win95 (and I am pretty sure WinNT) do this - A LOT. GDI, MDI and many other API's have these shared spaces. This is not full protection, and not a really good compromise. Not only can one person spill and cause lost work, but one person can just hog - take up all that space (which isn't very big) and then no one else can work, and often the System will come crashing down. MacOS does not do this (or in no places that most programmers would know), each application has to have it own space for these resources.
So when people talk about memory protection they are usually talking about some form of Partial Memory protection - with compromises. Applications are often fairly well protected from each other - but definitely not from the system, and in the case of windows they still have to share pools of memory. Windows types then want to argue that their partial memory protection is full memory protection (it isn't), and that the Macs partial memory protection is no memory protections (it is).
Memory Protection increases instability
Now there are some illusions about memory protection. It can not solve the worlds problems - or even the programmers problems. But it can reduce them and make up for bad programmers and poor Quality Assurance, and for the natural errors inherent to the process of development.
Memory protection actually can increase systems instability. Yes, you read that correctly. Memory maps are huge, and only a small percentage of the entire map (table-top) actually has data on it. So the likelihood of a spill ON someone elses work is pretty low to begin with. (And most of the time when it does spill it spills in predictable spaces - like location zero). So most of the time a program spills, it will not hit anything, or will only spill on itself (or you could protect only part of the memory and catch most of the bad spills). So normally, most spills are not that big of a deal, and without memory protection, nothing happens (the system keeps chugging along). However, with memory protection the Application comes crashing down (even though nothing bad would have happened). So the apps crash more than they would - but they do so as a preventative measure. The trade off is that apps are less likely to bring down the system (but more likely to come down).
Macs memory protection
Most of the Macs current memory protection is in the preventative side (not at run time). This avoids taking performance hits all of the time, and works really well if your programmers use those tools. They are definitely forms of memory protection. The protection runs for developers (slowing them down) and helping them to find the errors of their way, but does not impeded users.
Examples -
- The Mac has code-protection - CFM (code fragment
manager) is designed so that when a programmer loads his
code. This code is read-only - called code-protection.
This is like if the artist puts his "finished" work,
inside of little water tight packages - so he can only
mess up the work in progress (data - not code). PC's have
the same capability with 32 bit code (the minority of
their applications), theoretically -- but functionally it
is used rarely because PC
Software writers use self modifying code and
other nastiest that prevent this from working. This is a
form of memory protection - Macs have it, and use it. It
runs all the time, and Win95 does not have it on 16bit
apps, and it is often not used on 32bit apps.
- Bounds checking. When you start allocating or
de-allocating memory the system checks whether you app
has used too much space (the stack is over-running the
heap, etc.). This is a form of bounds checking (memory
protection) and is not only done on many allocations, but
also done 60 times a second. This is a form of memory
protection and Macs do it.
- Dereferencing Zero. The most common error is for a
programmer to access memory location 0, because they
forgot to set something. (Called dereferencing a null
pointer). You can catch probably 50% of the memory bugs
just by protecting location zero, and some of the areas
close to zero. Macs do this.
- Parameter verification. Programmers can often make
calls to the system with bad parameters. Think of mailing
an ink bomb to your neighbor artist. When he removed his
glass sheet to do work, and opens his mail - bloop! Ink
all over his work. (Usually only the system is the
recipient but that can still destroy every ones work).
WinNT does some parameter validation but Win95 does not.
Macs have it as a debugging tools for developers, but do
not do run-time validation. This is very important for
stability (even if it is not technically a memory
protection issue - it does help prevent the system from
walking on other peoples memory, or protect the
programmer from spoofing the system into making errors).
The Mac does it more (through validation tools) than
Win95 - but less than WinNT.
- System globals and variables. Part of making memory
stable is NOT sharing system memory with other
Applications - which allows those applications to crap on
a needed resource or something the system uses. So you
want to keep global memory to a minimum. Win95 (and to a
lesser extent WinNT) use shared memory like GDI/MDI
variables - this is a buffer that every application and
the system writes to on windows - and when it fills up -
phhht - BOOM! The system crashes. Macs allocate these
variables inside of each application - so an application
can crash itself - but not the system.
- Messaging. Shared memory also gets critical with
issues like sending messages back and forth. I mentioned
that technically the 'artists' (applications) should not
be allowed direct contact - but instead should "mail"
information back and forth. This is to prevent one guy
from giving the other guy a surprise in memory. Much of
windows messaging (like COM and
OLE) just pass around pointers to each
others memory. So they are protected, except where they
share - and they have to share quite a bit. The Macs
messaging it handled through an abstraction layer - you
compress and decompress the messages - but have no
intimate knowledge about how that information is passed.
This is a much more secure and expandable way of doing
things, with less surprises.
- Drivers. These are more shared resources, and
generally you don't want drivers working out of global
pools of memory that anyone can mess up (and take down
the system). Windows is very likely to allow this
(Win95). Macs are much better at having their drivers
talk into applications spaces (not shared pools) - so
again, something going wrong is more likely to bring down
the app using the driver - and not the entire system.
- Application space memory protection.This is what most
people are talking about when they say "memory
protection" and is the basic part I described at the
beginning of the article. Only one app can work in one
space at a time - or his supervisor sends him home (the
app gets shut down). The Macs have many tools to do this
fully at debug time (like debugging modern memory manager
and others) to allow programmers to catch their errors
before they ship applications.
Macs only protect apps from writing into another app (or systems) code at run time - it does not protect the applications data. This is partial protection - and is not perfect. Win95 protects apps from writing into other apps code or data (slightly better) - but only if they are all 32 bit apps (Macs do it for all apps - so Win is slightly worse), and they still allow programs to crap on the system code or all the shared memory pools (also worse than the Mac). This is partial memory protection and is not perfect. WinNT has more protection, as does the NeXT Mac OS (code named Rhapsody), but both have much stiffer memory and performance requirements that go with that protection. Computers are now crossing the thresh hold where this is viable in mainstream computers - but just barely. (Win95 outsells WinNT by 100:1 for a reason. This is one of them).
- Macs also have full memory protection for certain device drivers (parts of the system) and their data. There is no way for a user to crap on the Macs RAM-Disk memory. If you have a RAM disk on a Mac it can survive rebooting the computer and is in a completely protected memory space.
Conclusion
So you can see that there are many aspects of memory protection. MS is great at marketing, and they have convinced many of the unaware that the few things that they do are more important than the many other things Apple does - but that does not make it true. There are certainly tradeoffs in different OS designs, and in some ways Windows does have superior memory protection over the Mac, but there are many other areas that the Mac is superior to Windows in memory protection. On balance I might give a very very slight lead to Win95 in memory protection alone - but not in all the support issues that would make a system more stable. WinNT is better than Win95, and Rhapsody (Mach/Unix) is superior to WinNT. However, there is no doubt that the Mac does have many forms of memory protection - even if many Windows advocates, or PC-articles are too biased or ignorant to point this out.
Memory protection is only one step on the path to stability, and in general the Mac has been far more stable (overall) than Windows has. Windows also has a long checkered history of being really bad, it is just that the torture of windows has lessened recently, and now windows users think they are in utopia - because they have reached the Mac level. While the Mac has been getting more Windows programmers writing for it, and its stability has gone down - and so Mac people (at the same level of instability) feel like they are being abused. Mac users have higher standards, and so complain more at the same levels of "pain" - but this really reflect on how good Macs have been. Windows has finally (decades later) almost caught up, and in some limited areas actually surpassed Macs - but now Macs are ready to take another giant leap ahead of the competition with Rhapsody.
|
