A Modular Approach
The Windows 95 architecture is modular in design, with separate subsystems arranged in layers, from the lowest-level modules, which deal directly with hardware, to the highest-level modules, which provide application support. Figure1 illustrates, in broad strokes, this modular, multilayered approach. The next few sections take a closer look at these components.
Fig.1 Schematic of the Windows 95 Architecture.
Device drivers are small software programs that serve as intermediaries between hardware devices and the operating system. Device drivers encode software instructions into signals that the device understands, and, conversely, they interpret device signals and report them to the operating system. Although Windows 95 still supports real-mode device drivers for compatibility reasons, most device issues are now handled by virtual device drivers (VXD’s), which are 32-bit protected-mode drivers.
With tens of millions of legacy systems-and all their myriad combinations of bus types, devices, and protocols-still being put to good use, and with all the new Plug and Play (PnP) functionality being added to new machines, the number of potential hardware configurations is astronomical. To help sort all this out Windows 95 includes a component called the Configuration Manager. It's the Configuration Manager's job to enumerate the various Plug and Play devices on your system, identify the resources used by each device, resolve resource con-fliers, monitor the system for hardware changes, and ensure that the proper device drivers are loaded.
The Installable File System Manager
VFAT (Virtual File Allocation Table), is the new Windows 95 file system that supports long filenames. In fact, Windows 95 supports several file systems besides VFAT including CDFS (CD ROM File System) and network redirectors for connectivity to network servers. All this is handled by the Installable File System Manager, which not only includes access to the various file systems, but also handles the file system drivers and the block I/O subsystem, which interacts directly with your system's physical disks.
If Windows 95 has an "engine, it is probably the Virtual Machine Manager. In the same way that the Configuration Manager allocates and manages the resources needed by your system's hardware, the Virtual Machine Manager allocates and manages the resources needed by your system's software - your applications and the various operating system processes. If a program or the operating system needs a resource-whether it's a chunk of memory or access to an I/O port-the Virtual Machine Manager handles the request and allocates the resource appropriately. The Virtual Machine Manager does this by taking advantage of two advanced features of Intel's microprocessors: protected mode and virtual machines.
Protected mode is an operating mode that was introduced with the 80286 microprocessor. Real mode can address only up to 640 KB of memory and gives a running program direct access to hardware. Protected mode, on the other hand, lets software use memory beyond 640 KB, and it sets up a protection scheme so that multiple programs can share the same computer resources without stepping on each other's toes (and, usually, crashing the system).
Virtual machines were born with the release of Intel's 80386 microprocessor. Thanks to protected mode, the 80386 circuitry could address up to 4 GB of memory. Using this potentially huge address space, the 80386 let software carve out separate chunks of memory and use these areas to emulate the full operation of a computer. This emulation is so complete and effective that a program running in a virtual machine thinks it's dealing with a real computer. Combined with the resource-sharing features of protected mode, virtual machines can run their programs simultaneously without bumping into each other.
In Windows 3.x, you had one virtual machine for Windows itself (including all running Windows applications) and separate virtual machines for each DOS session. In Windows 95, the Virtual Machine Manager creates a System Virtual Machine for Windows applications and operating system resources, and DOS virtual machines for each DOS session.
The Virtual Machine Manager's responsibilities fall into three categories:
Process Scheduling and Multitasking
There's certainly no shortage of reasons to leave DOS in the dust, but one of the biggest is its lack of a multitasking feature. DOS, with its real-mode-only support, exists in a can't-walk-and-chew-gum-at-the-same-time territory. And that's despite the fact that multitasking has been available, at least theoretically, since virtual machines were introduced with the 80386.
Windows 3.x changed that by bringing true multitasking (and not just mere task switching, which is all that DOS is capable of) to the masses. Windows 95 ups the multitasking ante even further. The Virtual Machine Manager has a component called the Process Scheduler that doles out resources to applications and operating system processes. In particular, the Process Scheduler organizes running applications so that they take advantage of preemptive multitasking and multithreading. The next two sections discuss these powerful operating modes.
Understanding Preemptive Multitasking
Although Windows 3.x supported true multitasking, it wasn't implemented optimally. That's because Windows 3.x used cooperative multitasking This meant that you could have several applications running, but it was up to the individual applications to decide when they relinquished control of the system. It wasn't unusual for an ill-behaved application to start an operation and then refuse to hand over control until it was good and ready. You had no choice but to fume at the hourglass icon and wait until the program had completed its labors. In other words, cooperative multitasking was often very uncooperative.
Windows 95 abandons cooperative multitasking, for the most part, and replaces it with some-thing much better: preemptive multitasking In this model, the Process Scheduler uses a sophisticated algorithm to monitor all running processes, assign each a priority level, and allocate CPU resources according to the relative priority of each process. So if a particular process-such as a print job-is running, and a process with a higher priority-such as a spreadsheet recalculation-comes along, the Process Scheduler preempts the print job (hence the name preemptive multitasking) and allocates CPU cycles to the recalculation process. (All of this is measured in milliseconds, however, so everything seems totally seamless to you and me.) The result is extremely smooth multitasking, and interruptions to wait for a process to finish are rare, if not nonexistent, under Win 95.
Note, however, that Windows 95 applies preemptive multitasking only to 32-bit applications. Any 16-bit applications are still multitasked cooperatively within their virtual machine.
Preemptive multitasking is a great leap forward in multiple application support, but there is one fly in the ointment: For all this high-tech talk of schedulers and CPU cycles, there is still only one process happening at a time. The switching occurs so quickly that it only seems as though multiple things are happening at once. To see what I mean, imagine a film of a busy intersection. In regular motion, you see that the traffic light lets some cars through while others have to wait their turn. If you speed up the film, however, it looks as though a steady stream of cars is passing through in all directions.
If you want processes to occur simultaneously, you need to look at multithreading. A thread is a small chunk of executable code with a very narrow focus. In a spreadsheet, for example, you might have one thread for recalculating, another for printing, and a third for accepting keyboard input. You can set all these threads in motion and they'll run concurrently, without interfering with each other. Windows 95 supports multithreading in those (still relatively rare) 32-bit programs that implement it. (Windows 95 even uses multithreading in some of its accessories, such as WordPad.)
The Virtual Machine Manager includes a second component called the Memory Pager. Its job is to move data back and forth between the hard disk and the system's physical memory and to allocate hard disk space as virtual memory addresses. This is called paging.
Nearly all DOS programs are perfectly content to run inside an MS-DOS virtual machine. DOS programs expect to have full run of the computer, and the Virtual Machine Manager fools them into thinking that's exactly what they have. However, a few (thankfully rare) DOS applications really do need direct control over the computer. For these programs, Windows 95 can run in MS-DOS mode which gives the program exclusive access to the computer. When you run such a program, the Virtual Machine Manager takes care of the behind-the-scenes prep work, including shutting down any running programs and "rebooting" the system into a pure DOS environment.
Core Operating System Components
The next layer in the Windows 95 hierarchy consists of the core operating system components: the User, the Graphical Device Interface (GDI) and the Kernel Actually, each of these components comes in two flavors 16 bit and 32 bit. The 16 bit versions handle services that are needed to maintain compatibility with 16 bit applications; the 32 bit versions are used to improve the performance of Windows 95 in areas where compatibility isn't an issue.
The User component handles all user-related I/O tasks. On the input side, User manages incoming data from the keyboard, mouse, joystick, and any other input devices that might be attached to your computer. For ~output," User sends data to windows, icons, menus, and other components of the Windows 95 user interface. User also handles the sound driver, the system timer, and the communications ports. For compatibility, most of the User component is implemented as 16-bit code.
The GDI manages Windows 95's graphical interface. It contains routines that draw graphics primitives (such as lines), manage colors, display fonts, manipulate bitmap images, and interact with graphics drivers. The GDJ uses a mix of 16-bit and 32-bit code.
As its name implies, the Kernel makes up the heart of Windows 95. The Kernel loads applications (including any DLLs needed by the program), handles all aspects of file I/O, allocates virtual memory and works with the Memory Pager, and schedules and runs threads started by applications. The Kernel is mostly 32-bit for maximum performance.
The next layer in the Windows 95 architecture is the shell. (Note that the shell is called Explorer, which isn't to be confused with the Windows Explorer file management accessory). The shell provides the user interface and supplies applications with various common controls, including common dialog boxes (such as Open and Save As), tree views, list views, and so on.
The top layer of the Windows 95 architecture consists of the applications, including the Windows 95 accessories. Windows 95 can run three types of applications:
Win32: These are 32-bit applications built using the Win32 application programming interface (API). The Virtual Machine Manager creates a separate virtual machine (within the System Virtual Machine) for each running Win32 application, so these programs always have their own private address space. In addition, Win32 applications take full advantage of the Windows 95 environment, including preemptive multitasking, long filenames, and so on.
Winl6: These are 16-bit applications built using the Win16 API. Although most Win16 programs run fine under Windows 95, you should know that the Virtual Machine Manager doesn't create a separate virtual machine for each running Win 16 application. Instead, all Win16 applications run inside the same virtual machine, as they did with Windows 3.x. (These applications are cooperatively multitasked within this virtual machine.) Thus, using Winl6 programs with Windows 95 leaves you open to the same vulnerabilities associated with Windows 3.x.
DOS: These are programs designed to be run in a DOS environment. The Virtual Machine Manager creates a separate DOS virtual machine (with 1 MB of virtual memory) for each running DOS program. The environment that the Virtual Machine Manager uses for each DOS virtual machine is determined at startup. Based on the entries in CONFIG.SYS and AUTOEXEC.BAT, Windows 95 established an 'invisible" virtual DOS machine that acts as a sort of template. Each time a DOS program is run, the Virtual Machine Manager uses this template to create the DOS environment for the new virtual machine. It's possible to customize this environment for individual DOS programs.
The Registry is Windows 95's central database for configuration data, options, and any information that affects the operation of Windows 95 itself, your system's devices, or your applications. In that sense, the Registry is used by each layer of the Windows 95 architecture to read the current settings for your system and to store any new values that get set during a session.
Intel's Protection Ring Architecture
Another way to look at the Windows 95 architecture is in terms of Intel's protection ring architecture. Beginning with the 80386 processor, Intel implemented a system of privilege levels for all running applications and system processes. These levels determine how much freedom the code has to perform certain operations. For example, code running on a level of lesser privilege won't be able to access certain memory regions.
These levels, called rings, range from ring 0, the highest privilege level, to ring 3, the lowest level. Unlike Windows NT, which uses all four levels, Windows 95 uses only two levels:
Ring 0: Windows 95 uses the highest privilege level for its most fundamental services: Configuration Manager, Virtual Machine Manager, and Installable File System Manager. This ensures that these key components can't be compromised by running applications (which run in ring 3). However, Windows 95 also allows virtual device drivers to run in ring 0, thus opening the system to potential problems caused by misbehaving or poorly written drivers.
Ring 3: Windows 95 uses the lowest privilege level for the core operating system components (User, GDI, and Kernel) and applications. This prevents applications from executing instructions or functions that are the responsibility of the operating system, and it prevents applications from overwriting memory areas that contain key operating system components.
Improvements in the Windows 95 File System
Microsoft put a great deal of time and effort into making the Windows 95 file system better and faster than the one that powered Windows 3 x (even the one in Windows for Workgroups). Here's a summary of just some of the changes you can expect
32-bit VFAT: Disk access is provided by the 32-bit VFAT (virtual file allocation
table). Unlike the 16-bit FAT (file allocation table) used in Windows 3.1, VFAT is a virtual device driver that operates in protected mode, so there are no time-consuming mode switches to real mode every time an application needs to write to the disk.
Windows for Workgroups used an early version of VFAT (called 32- bit file access), but the Windows 95 version is more reliable and operates with a greater variety of hardware (Note that OSR2 replaces VFAT with the more efficient FAT32). FAT32 was further improved in Windows 98.
Long filenames: You can create files that use names that have up to 255 characters (including the path). Windows 95 implements long filenames without creating incompatibilities with 16-bit applications that don't recognise long filenames.
Demand paging: This is an advanced algorithm for paging memory to the swap file. Not only is it faster than even the permanent swap file used in Windows 3.x, but it also is dynamic: The swap file's size is adjusted according to the load on the system.
VCACHE: This is the Windows 95 32-bit disk cache driver. It replaced SMARTDrive, the 16-bit real-mode driver used in Windows 3.x. Like the swap file, VCACHE is dynamic, which means that it tailors the size of the cache based on how much memory is available and the intensity of disk paging.
Built-in CD-ROM support: Windows 3.x relied on real-mode drivers to work with CD-ROM drives. In Windows 95, CD-ROMs get their own 32-bit file system (CDFS).
Built-in EIDE and SCSI support: Windows 3.x didn't support either EIDE or SCSI and relied on third-party manufacturers to supply drivers for these devices. Windows 95 supports both EIDE and SCSI right out of the box.
Port drivers: These are 32-bit drivers that communicate with specific disk devices. For example, the port driver that manages the floppy disk controller lets you format a floppy disk in the background while you continue working on other tasks.
The Windows 95 File System Architecture
To implement all the new features discussed in the preceding section, the Windows 95 development team revamped the file system architecture into a layered model that makes extensive use of32-bit protected-mode drivers for increased performance and reliability. Figure 2 shows the various components of this new architecture, and the next few sections explain each component.
Fig.2 Windows95 File System Architecture
More On the Installable File System Manager
An installable file system is a file system that can be loaded into the operating system dynamically FAT is built right in at the hardware level, so to speak, when you format a disk. Any other file system you want to use either must come from a low-level format or must be installed on top of the existing file system. The advantage of the latter situation is that your operating system can then work with multiple file systems at once, which is what Windows 95 does.
The software that manages file systems in Windows 95 is called, appropriately enough, the Installable File System (IFS) Manager. It's a 32-bit protected-mode device driver that's loaded at startup (along with other device drivers that make up VMM32.VXD). The IFS Manager installs the file systems (see the next section) and arbitrates access to these systems. IFS Manager automatically determines the format of a storage medium and reads and writes files in the correct format.
Note that IFS Manager is designed as an open system, meaning that third-parry developers can use it to install extra file systems. (For example, you might see third-party file systems that give you access to the Windows NT file system (NTFS) on a local hard disk partition-which would be a real boon to those running both Windows 95 and Windows NT on one system).
In its default incarnation, the IFS Manager loads three file system drivers: VFAT, CDFS, and one or more network redirectors.
The Virtual File Allocation Table (VFAT)
VFAT is the file system driver that works with the block I/O subsystem (described later) to access disk services. Because it's a 32-bit protected-mode VxD and is multithreaded, VFAT provides superior performance (especially compared to the 16-bit real-mode disk access found in Windows 3.1), enhanced reliability, and easier multitasking. In particular, VFAT avoids the slow processor mode switches between protected mode and real mode that plagued Windows 3.1.
VFAT also supports many more drive and controller types than did Windows 3.x. For disk drives, VFAT has drivers that can work with the types IDE, ElDE, ESDI, and Hardcard. For disk drive controllers, VFAT has drivers for the types MFM, RLL, PCI, PCMCIA, SCSI, and SCSI 2.
VFAT is far from perfect, however. It still uses the 16-bit FAT for physical storage of files and folders, so it inherits FAT's legendary fragility. (For example, you're just asking for trouble if you shut down your computer while Windows 95 is still running.)
Using a mechanism called the Real Mode Mapper (RMM), VFAT can also work with any real-mode disk drivers you might still be using (such as DBLSPACE BIN or a third-party disk not supported by Windows 95). The RMM makes the real-mode driver appear as though it's operating in protected mode.
Besides enhanced speed and multitasking, perhaps the greatest advantage VFAT brings to the file system table is long filenames.
Like Windows NT, Windows 95 now implements a separate installable file system for CD-ROM drives: CDFS. CDFS uses a 32-bit protected-mode VxD (VCDFSD.VXD) that replaces MSCDEX.EXE, the 16-bit real-mode driver used in previous versions of Windows. The new driver provides many of the same benefits you saw with VFAT, including improved performance and better multitasking. CDFS also supports a separate, dynamic pool of cache memory to further enhance CD-ROM performance.
A network redirector is a virtual device driver that lets applications find, open, read, write, and delete files on a remote drive. Windows 95 comes with network redirectors for Microsoft network clients (VREDIR.VXD) and NetWare network clients (NWREDIR.VXD).
The block I/O subsystem is the Windows 95 mechanism that talks directly to disk hardware. It's the replacement for the FastDisk feature used in previous versions of Windows. The next few sections discuss the various parts of the block I/O subsystem.
The I/O Supervisor acts as an intermediary between the disk drivers and the file systems. Besides loading the appropriate drivers for accessing disk controllers and disk drives, the I/O Supervisor arbitrates all I/O operations, including the queuing and routing of file service requests. It also assumes control of any real-mode drivers that have been loaded. The Real Mode Mapper is part of the I/O Supervisor, and it translates file I/O requests from protected mode to real mode so that the real-mode driver can complete its work. Note that drivers designed to work specifically with the I/O Supervisor are stored in the \WINDOWS\SYSTEM\ IOSUBSYS folder.
This is one of the few examples in which old-style monolithic drivers are used in Windows 95. Port drivers are 32-bit protected-mode drivers that provide complete functionality for working with devices such as hard disk controllers or floppy disk controllers.
Windows 95 uses the universal driver/minidriver model for SCSI device support. A 32-bit protected-mode driver called the SCSI layer provides the basic high-level functionality common to all SCSI devices and then relies on manufacturers to provide minidrivers (called miniport drivers) for device-specific I/O requests.
A separate component called the SCSl Manager (SCSIPORT.PDR) ensures compatibility between the SCSI layer and Windows NT miniport drivers.
Windows 95 stomps all over the old 8.3 filename limitation that people had to suffer with for so many years. Now you can create long, sentence-like names that actually describe what’s in a particular file.
So just how long can your filenames be? Well, according to Microsoft, the limit is 255 characters, but that's not right. Here's the correct rule: The total number of characters in the pathname - that's the filename plus the file's path information (drive and folder) -cannot exceed 253.
For example, if you create a file in the root folder of drive C, your path is three characters long (C:\), so the maximum length of the filename is 250 characters. If you create a verbosely named file and then try to copy it into, say, the C:\WINDOWS folder, you get an error message because the new pathname is actually 260 characters (250 for the filename plus 10 for the path).
One of the keys to understanding how Windows 95 works is learning how it converts long filenames into 8.3 filenames, so let's take a closer look. When converting a long filename to an 8.3 filename, VFAT goes through no fewer than seven steps:
1. All spaces are removed from the long filename.
2. All characters that are illegal under DOS (such as ; and =) are replaced by the underscore character (_).
3. The resulting primary name is truncated at six characters.
4. The first three characters in the extension are kept.
5. A tilde (~) and a 1 are appended to the six-character primary name.
6. All letters in the filename are converted to uppercase.
7. VFAT checks to see whether the resulting 8.3 filename is unique in the folder. If it's not, the 1 at the end of the primary name is changed to 2. If it's still not unique, the number is incremented until a unique filename is found.
For example, consider the following 10 long filenames:
Testing, testing, one.txt
Testing, testing, two.txt
Testing, testing, three.txt
Testing, testing, four.txt
Testing, testing, five.txt
Testing, testing, six.txt
Testing, testing, seven.txt
Testing, testing, eight.txt
Testing, testing, nine.txt
Testing, testing, ten.txt
The VFAT system converts these files to the following in 8.3 format:
TESTIN~1 .TXT
TESTIN~2 .TXT
TEST IN~3 .TXT
TEST IN~4 .TXT
TEST IN~5 .TXT
TEST IN~S .TXT
TEST IN~7 .TXT
TEST IN~S .TXT
TEST IN~9 .TXT
TESTI~10.TXT
Notice that in the last filename, VFAT truncates the primary name to five characters because the trailing number is now in double digits.
Although this conversion is an admirable attempt to maintain compatibility with older systems, the addition of two (and sometimes three) superfluous characters (the tilde and the number) at the end of the primary name isn't a great solution. The problem is that you're now down to just six (or even five) characters in the primary name, which gives you even less flexibility with respect to naming files. This is of little importance if you'll be using your files only on a Windows 95 (or Windows NT) system, but it can make a big difference if you'll be distributing your files to people still using DOS or Windows 3.x. Happily, there's a way to tell Windows 95 not to append the tilde l number combination (known as the numeric tail) to 8.3 names.
So just how did Microsoft perform the seemingly impossible task of giving us long filenames and backward compatibility? Well, they did it by keeping track of two names for every file and directory: a regular 8.3 name and a long name. When you create a file with a long name, VFAT creates a regular FAT-compatible directory entry as well as a secondary directory entry. This new entry stores the first 26 bytes of the long filename. If the name is longer than that, VFAT just keeps adding secondary directory entries until the entire name is concatenated. The 8.3 name is stored in the initial directory entry, so complete compatibility is maintained.
Why don't older programs get confused by all these extra directory entries? Cleverly, Microsoft took advantage of an obscure property of the FAT system. In the FAT file structure, each file has a 32-byte directory entry that specifies, among other things, the file's name, its extension, the date and time it was created, and the file's attributes: read-only, archive, system, hidden.
The obscurity is that, under DOS, it isn't logical for a file to have the following four attributes set: read-only, hidden, system, and volume label. In fact, DOS will just ignore any directory entry that has these four attributes set. So that's what VFAT does: It sets these four attributes on all the secondary directory entries so that they'll be ignored by all older programs.
This works for older programs because they use the built-in DOS enumeration functions to work with filenames. However, many older disk utilities (such as Norton Disk Doctor) bypass DOS and work with directory entries directly. Such utilities see VFAT's secondary directory entries as corrupted entries that aren't associated with any file. When they "fix" them, you lose your long filenames.
To avoid this problem, use only disk utilities that were made to run under VFAT. (If you don't have any VFAT-compatible utilities, you can use Microsoft's LFNBK utility to avoid problems with older disk utilities. See Chapter 15, "Protecting Your Windows 95 Investment," for details).
Back in 1981, when Bill Gates was asked about the 640 KB memory constraint in the original IBM PC architecture, he said, "640K ought to be enough for anybody." In fact, a case could be made that the entire history of the PC involves someone saying that "x ought to be enough for anybody" and then a few years later saying "x just doesn't cut it anymore." Hard disk size is a good example. When the FAT file system was modified a few years ago to accommodate disks with up to 2 GB capacity, such a vast number seemed laughably large at the time (After all, it wasn't that long before that DOS 4.0 had finally broken the 32 MB barrier!). Now, however, 2 GB disks are de rigueur on even modest systems and notebooks (and can be purchased for less than 10 cents a megabyte), and disks with 4 GB and even 9 GB capacities aren't all that unusual. So, once again, we're at architectural crossroads in the PC industry:
· Until now, manufacturers had been handling large (over 2 GB) hard disks by splitting them into multiple partitions.
· The FAT system is extremely wasteful at large partition sizes. On partitions that arc between 1 GB and 2 GB in size, FAT allocates a full 32 KB to even the tiniest file. The result is as much as 30 percent wasted hard disk space.
To get us through this crossroads and into the next era, Microsoft has updated the FAT portion of the file system to the new FAT32 architecture. This is one of the key new features found in OS~, and Microsoft promises it will be a feature in the next major release of Windows. How does FAT32 help? Here's a summary:
Support for larger hard disks: FAT32 can handle hard disks that have a capacity of up to 2 terabytes (2,024 GB). The '32" in FAT32 means that the sector numbers used in directory entries are now 32-bit values. This means that the file system can track 4,294,967,296 (2 to the power of 32) distinct values, which, at 512 bytes per sector, yields the 2-terabyte limit.
Smaller cluster sizes: Instead of the massive 32 KB clusters used in large FAT 16 partitions, FAT32 uses only 4 KB clusters in partitions up to 8 GB. This will improve storage efficiency on the vast majority of systems and should free up large amounts of disk space automatically.
Improved robustness: FAT32 implements three new features that should improve the reliability of the file system: a moveable root directory (useful for avoiding corrupt disk areas), the ability to use the backup copy of the FAT (FAT16 maintained two copies of the FAT but could use only one of them), and an internal backup copy of some critical FAT data structures.
Flexible partitioning: Unlike FAT16, FAT32 imposes no restrictions on the number of directory entries in a partition's root folder, and it allows the root to be located anywhere on the hard drive. These features mean, at least theoretically, that it's possible to dynamically resize a FAT32 partition without losing data (in other words, good riddance to the wretched FDISK utility!). At the time this chapter was written, however, no partitioning utilities that take advantage of this had been released.
Although Microsoft took great pains to avoid upsetting the file system apple cart with FAT32, any major change in this critical area is going to break a few applications and be cause for a few caveats. Here are a few notes to bear in mind when working with FAT32:
· The change from a 16-bit to a 32-bit cluster numbering scheme should have no effect on mainstream applications. Disk utilities are another story, however. Because these
programs expect a 2-byte cluster value, they won't work with FAT32. You'll need to get updated versions of your favorite utilities before you use them on your FAT32 drives.
· FAT32 comes with updated versions of its disk utilities, including the real-modeFDISK, FORMAT, SCANDISK, and DEFRAG commands, and the protected-mode Format, ScanDisk, and Disk Defragmenter applets.
· DriveSpace 3 does not work on FAT32 partitions.
· Existing file systems, including FAT16 and the NTFS used in Windows NT, aren't compatible with FAT32, so FAT32 drives won't be visible locally (You'll be able to see them across network connections, however.) This also means that you can't dual-boot on a FAT32 partition.
· Don't expect large changes in file system performance under FAT32. Although an improved caching system helps performance, this benefit is offset by the larger number of clusters that the system must deal with.
