- Windows 95 Blueprint: Internals and Architecture
- Windows 95 memory management
- Running applications
- Software in the Registry
- Common system drivers
- Lab
3.2. Windows 95 memory management
One problem with Windows versions prior to Windows 95 was the way that they handled memory. Let's think back to when we only had 1MB of usable memory in computers. Remember that? It was segmented into several layers. Figure 3.1 shows a typical setup of the MS-DOS memory model.
){kind=link}
Figure 3.1. The MS-DOS memory model.
Granted, my job here is to prepare you for the Windows 95 exam, but I think a basic understanding of how things used to be will give you a greater understanding of how the Windows 95 memory model works. With that in mind, I will go a little in-depth with my explanation of memory, but I'm not going to go into great detail telling you about the MS-DOS memory model, such as explaining hexadecimal addressing. In other words, I won't be explaining absolutely everything there is to know about memory.
First of all, we started with 1MB of memory. It was segmented into a range of 0K to 640K to be used by applications, and the upper 384K for system use. Portions of the top 384K, called upper memory blocks (UMBs) could be used for loading some type of driver because some reserved areas were not always used. You can see an example of this with areas of upper memory that were reserved for CGA monitors (who uses them anymore?).
Then came Lotus, which needed more than 1MB memory. With the help of Intel, they created what we call expanded memory (also called LIM memory, short for Lotus-Intel memory). In Figure 3.2, you'll see that this was separate from the conventional memory and used a portion of the reserved area to page pieces of information between the conventional memory area and the expanded memory area. To do this, they needed a software program to do the paging, an expanded memory manager. The most common one was EMM386.SYS, and later it became EMM386.EXE. You may not be familiar with the term paging. Think of it as paging someone over a loudspeaker. The expanded memory manager calls for the information and stores it in the expanded memory area. When the information is needed, the expanded memory manager once again calls for the information for retrieval.
){kind=link}
Developers soon realized that this fix could only be a temporary one once more and more programs started to require more and more memory. Then came the extended memory specification. Any memory above the 1MB limit would be known as extended memory (see Figure 3.3). In order for this higher memory to exist, developers needed another software implementation called HIMEM.SYS. In my example, the computer has 16MB or RAM.
){kind=link}
Figure 3.2. The expanded memory area.
Figure 3.3. The extended memory area.
The old memory model had several problems. First of all, information in memory was stored in 64K blocks; therefore, wasted memory was a big problem. If you wanted to load a driver that required 12K of space, it was allocated 64K whether it used it all or not. In that particular scenario, 52K would go unused. I realize that by today's standard, 52K is nothing, but remember, we are talking about way back when we thought we would never need more than 1MB of RAM.
The second and probably more obvious problem was that of segmentation. In Figure 3.3, you'll see two blocks labeled A and B. Let's say that those two blocks are the only two blocks we have that are unused. If we attempted to load a 128K driver, even though those two spaces add up to 128K, we would see an Out of Memory error message. This is because in order for programs to be loaded into memory, they had to be loaded contiguously (in spaces right next to each other). Some of you die-hards would say that I needed to move some things around and free up the space contiguously. Short of explaining hexadecimal addresses and such, you're right, but I'm here to tell you about the Windows 95 memory model, and it's just an example.
The last problem was the biggest to fight. The model never had enough memory. The more programs and drivers we wanted to run, the more we were fighting the battles explained in the previous two paragraphs. The end problem always boiled down to not having enough.
With Windows 95, most of the problems were resolved. The Windows 95 memory model in Figure 3.4 was taken from the Windows NT memory model. Windows 95 tells every loaded application that it has 4GB of memory available. You heard it right. That 4GB of memory is broken down into 2GB of usable space by the application and 2GB reserved as system addressable.
){kind=link}
Figure 3.4. The Windows 95 virtual memory model.
The virtual memory manager (VMM) takes the information from virtual memory addresses of the applications on the left and maps them to actual spaces in physical memory. It tricks the applications into thinking that their information is stored somewhere that it isn't. For instance, if you run two MS-DOS applications at the same time, they both want 0 to 640K. Windows 95 gives them both 0 to 640K, but whenever the applications tell the VMM that they want to store information there, the VMM really puts it where it sees fit to, all the while hiding where it's really stored from the applications.
Think of it this way. If you hire a household goods storage company to store some furniture for you, you could care less where they put it, as long as you get it back when you ask for it. When you get your furniture (or your data) back, you want it in the same condition as when you saw it last. They could tell you that you belongings are stored in Chicago, when all the while they're really stored in Milwaukee. That's kind of what the VMM does.
Let's talk about the problems that this 32-bit, flat, linear model fixed. The first problem was the wasted memory. In the MS-DOS model, the blocks were 64K in size; in the new Windows 95 model, they are 4K in size. Smaller chunks mean less wasted space.
Another problem was this: in order to load a program, the spaces used had to be contiguous. The new memory model no longer requires this. In Figure 3.4, you can see that the applications and free space are spread out noncontiguously. The Virtual Memory Manager handles it all.
3.2.1. Paging memory
The new memory model still needed to solve one problem: not enough memory. The new memory model was created to tell the applications that they had 4GB of memory available, with up to 2GB that was usable. Who was going to back up what the application was being promised? After all, the minimum requirement for RAM was 4MB. Where was this 4GB going to come from? Believe it or not, it would come from the hard disk. I know, I know, not everyone in this day and age has 4GB hard drives yet. Hear me out.
Think of this concept: Windows 95 can allocate more memory than is physically installed in the computer. Even though you may run several applications at one time, it doesn't mean that the applications need things loaded into memory at the same exact time. Take a look at Figure 3.5. When an application needs information loaded into memory, the VMM puts it into physical RAM. When another application needs physical memory space, the VMM takes information that is loaded in physical memory but not currently in use and pages it to the hard disk. It places the information in a file called a swapfile. This frees up space in physical memory to be used elsewhere. When the application with information that was paged to disk needs its information back, the VMM moves the information back into physical memory. This process of memory swapping is also called demand paging. When application demands it, the VMM takes care of it.
){kind=link}
Figure 3.5. Demand paging.
So how does the VMM keep track of this? Actually, it's quite simple: The VMM uses what is called a paging table to keep track of what information is stored on the hard disk and what information is in physical memory (see Figure 3.6).
){kind=link}
Figure 3.6. The paging table.
Virtual memory and this idea of paging to the hard disk involves a slight problem. Let's say that every available space in physical memory is being used. In order to load information that is currently in the swapfile into physical memory (paged in), something currently in physical memory needs to be swapped to the hard disk (paged out) in order to free up the space. Sounds like musical chairs doesn't it?
Even though Windows 95 was designed for paging information in and out of memory, the time comes when enough is enough. Too much of this swapping causes the system to become slow and unresponsive, not to mention that it takes a toll on the hard drive. This is what is called excessive paging . You'll know when your computer is excessively paging. The computer will run slow, and you will hear high activity from the hard drive (thrashing). The fix for excessive paging is simple: add more RAM.
TIP
You should know that the fix for excessive paging (hard disk activity and slow system response) is to add more RAM. This makes for an excellent test question where the true answer, adding more RAM, seems too simple to be the correct answer. Don't let more complicated choices throw you off.
NOTE
I have found that Windows 95 runs smoothest with at least 16MB of RAM. The 4MB minimum is definitely not enough to be happy with the performance.