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 its neighbors memory
(causing the neighbor to crash).
[Read DojoWhat is Memory Protection for what the different types of memory protection are, and how they work.]
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).
Comparison
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 is "protected".
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 hi-mem.
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 RAM.
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 runtime.
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 error).
- MacsBug has a few DCMD's to excorcise memory and do bounds and leak checks.
- Jasik Debugger can do memory excorcising and check bounds and leaks.
- Q.C. moves memory around and stress tests.
- 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!).
- DebuggingModernMemoryManager is a programmer's version of the Mac's memory manager that helps developers find bugs.
- Many more tools...
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 protection).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 memory protection.
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 now.
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 System.
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 System.
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 protection.
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.
Conclusion
What people really care about is overall stability.
[Read MythsStability
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 stable?
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 instability.
- 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 Security.
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 help.
|
