Anda di halaman 1dari 13

INTRODUCTION ============

Microsoft Windows operating system version 3.1 has a number of enhancements over previous versions that improve both its usability and its performance. Foremost among these enhancements are Windows 3.1's improved features for accessing and utilizing the hard drive of your PC. SMARTDRIVE 4.0 DISK CACHE ========================= Microsoft's first release of the Windows graphical environment included a dis caching program called SMARTDrive 3.03. SMARTDrive has been improved with each subsequent release of Windows and has been entirely redesigned in Windows version 3.1. SMARTDrive 4.0 in Windows 3.1 provides faster and more intelligent dis caching that ta es better advantage of the revolutionary way that Windows and Windowsbased applications use extended memory. SMARTDrive 4.0 gives Windows 3.1: - Improved performance by speeding up hard dis and RAM access. - Improved stability in 386 enhanced mode by double buffering data when needed. The remainder of this section compares the performance of SMARTDrive 4.0 to SMARTDrive 3.x and illustrates how SMARTDrive 4.0 wor s at a more technical level. WHAT IS SMARTDRIVE? =================== SMARTDrive is a dis caching program that intercepts system calls to the hard dis to control read/write access to the dis . SMARTDrive intercepts any calls to the hard dis and loads the needed data into a cache it establishes in RAM. (Unless specified otherwise, SMARTDrive automatically determines a reasonable cache size based on the amount of free extended memory available when it initially loads; the maximum amount it will ta e is around 2 MB.) Subsequent calls to the hard dis are intercepted by SMARTDrive, which scans the cache for the requested data. If the data is already present in the cache, SMARTDrive can access it directly in RAM. If the data is not in the cache, SMARTDrive accesses the hard dis and loads the necessary data into the cache. The least recently used data residing in RAM is cached bac to the hard dis to ma e room for the new data. By loading bloc s of data from the hard dis into RAM, SMARTDrive helps decrease the number of calls to the hard dis . This can dramatically speed up applications that repeatedly access the hard dis for data because accessing the hard dis is considerably slower than accessing RAM. Essentially, SMARTDrive attempts to maintain information in RAM that an application needs at any given time from the hard dis . SMARTDRIVE 3.X ==============

To understand why SMARTDrive needed to be redesigned, lets loo at how SMARTDrive 3.x wor s and examine some of the shortcomings of its design. First, SMARTDrive 3.x is a read-only trac cache, which means that it caches on a trac basis and for read operations only. This means that the internal data structures of the SMARTDrive program are tied to the logical geometry of the dis (that is, what MS-DOS sees). In the diagram below, you can see that SMARTDrive 3.x caches at the ROM BIOS INT13 level and uses the BIOS-specified dis geometry to decide the size of its caching element (that is, trac size). INT13 is the most common method for interacting with hard dis s (and has evolved into the industry standard). SMARTDrive under Windows 3.0 can be loaded into either extended memory or expanded memory. Application (Read/Write INT21) | - - - - - - - - - - - - - - - - | MS-DOS Call HD Driver | HD Driver INT 13 | ---------> SMARTDrive 3.x Chains INT13 ---------< | ROM BIOS | Hard Drive SMARTDRIVE 4.0 ============== SMARTDrive 4.0 is designed as a bloc -oriented dis cache. It hoo s into the system at the MS-DOS device driver level rather than at the ROM BIOS INT13 level (as with SMARTDrive 3.x). Each bloc device driver on the MS-DOS device driver chain is "front-ended" by a SMARTDrive 4.0 module that provides the actual caching. This new design yields the following benefits: - It is independent of the INT13 interface. - It is independent of dis geometry. Application (Read/Write INT21) | - - - - - - - - - - - - - - | MS-DOS Call HD Driver | ---------> SMARTDrive 4.0 HOOKS Driver ---------<

| HD Driver INT 13 | ROM BIOS | Hard Drive Independent of INT13 Interface -----------------------------Many device drivers do not use the INT13 (BIOS) interface (for example, Bernoulli drives, some hard cards, and many SCSI and WORM drives). This means that SMARTDrive 4.0 can cache these devices, whereas SMARTDrive 3.x cannot. SMARTDrive 4.0 can cache any dis controller that uses an MS-DOS bloc device driver. Independent of Dis Geometry ---------------------------Some dis managers and dis controllers use a dis geometry mapping scheme that causes the logical geometry to be different from the physical geometry (for example, many PS/2 systems, Ontrac 's Dis Manager, and several dis controllers). The INT13-based dis caches are sensitive to this and often have problems. For example, some dis management software actually changes the ROM BIOS-specified dis geometry, which confuses INT13-based dis caches (including SMARTDrive 3.x). There usually is an interface to determine the true geometry, but this requires detection of the specific dis manager driver and generally complicates the dis cache software. Often, logical trac s actually cross physical trac boundaries, causing the trac caches to incur performance penalties (intertrac see s and rotational latencies, for example). To get around the ROM BIOS 1024-cylinder limitation, dis managers and controllers sometimes fold multiple trac s into one logical trac . This results not only in problems with the physical trac boundaries as noted above, buts forces trac caches to have a very large trac buffer as well. In some cases, this buffer can be as large as 31.5K and must reside in conventional memory. The design of SMARTDrive 4.0 eliminates this geometry mismatch problem. OTHER SMARTDRIVE 4.0 FEATURES ============================= Write-Behind Cache -----------------SMARTDrive 4.0 is a write-behind cache, also nown as lazy write. A write-behind cache adds significant performance improvements wherever files are being written to dis . For example, an application writes data to what it thin s is the hard dis . SMARTDrive ta es this data and places it in the cache, rather than physically writing it to the dis . This write-behind data stays in the cache until one of the following occurs: 1. The cache fills up. The oldest bloc in the cache is freed up, and

if it is write-behind data, physically written to the dis . 2. The system goes idle. SMARTDrive writes the oldest write-behind data bloc to the physical dis . As long as the system is idle, SMARTDrive continues to write to the dis until all the writebehind data is written. This write-behind data also comes from Windows-based and MS-DOS-based applications that are idle. 3. SMARTDrive detects that you have pressed CTRL+ALT+DEL. When you restart by pressing CTRL+ALT+DEL, SMARTDrive writes all writebehind data to the physical dis . This is a synchronous operation-SMARTDrive does not give up control until all data is written. 4. A bloc is older than five seconds. If a bloc is older than five seconds, it is written to the physical dis . Shrin Algorithm ---------------Similar to SMARTDrive 3.x, SMARTDrive 4.0 implements a shrin algorithm that frees memory for Windows (that is, the cache set up by SMARTDrive is removed from memory). The difference is that SMARTDrive 4.0 watches for the Windows startup broadcast while SMARTDrive 3.x provides an IOCTL interface. The net effect is identical, but the SMARTDrive 4.0 code is much simpler. Upon exiting Windows, the process is reversed and the memory is reacquired by SMARTDrive 4.0. Automatic Load High ------------------When an upper memory bloc (UMB) provider (such as EMM386.EXE) is loaded, SMARTDrive 4.0 (SMARTDRV.EXE) automatically attempts to load itself high. Unli e the Windows 3.0 SMARTDrive, SMARTDrive 4.0 can only be loaded into extended memory. DOUBLE BUFFERING AND BUS MASTERING ================================== The second major benefit of SMARTDrive 4.0 is the protection it provides through double buffering. Double buffering is a response to bus mastering, which is supported by certain (usually older) dis controllers. Bus mastering refers to a situation in which the hard dis controller ta es over the bus to directly transfer data to or from system RAM, bypassing the CPU entirely. A problem occurs when Windows 3.x virtual machines and/or popular memory managers (such as EMM386.EXE and QEMM.SYS) are running in virtual 8086 mode. The read or write address that is passed to MS-DOS from the bus master controller is often not the same as the actual physical memory address. This can cause data to be read from the wrong location, or worse, can cause data to be written to the wrong RAM address, resulting in erratic system behavior and potential file corruption. When paging is enabled on an 80386 or faster processor, it is possible for the physical address (the actual location of the memory) to be different from the virtual address (the address that programs are using to access memory). Paging is enabled by all device drivers that can provide load high capability and by Windows in 386 enhanced mode. For example, say SMARTDrive wants to write to an area of memory that has a virtual address in conventional memory, but a physical

address in extended memory. When the hard drive controller ta es over the bus and transfers data from the UMB to the dis , the controller does not use the CPU, so there is no address translation, resulting in the wrong data being written to dis . To avoid this problem, double buffering copies the data into a buffer in conventional memory and then passes the information to the hard dis controller. So, the virtual address always equals the physical address when using devices that only recognize conventional memory. Installing Double Buffering --------------------------To install the SMARTDrive double-buffering feature, add the following line to your CONFIG.SYS file: device=c:\windows\smartdrv.exe /double_buffer Including this line does not install the cache, only the doublebuffering driver. The cache must be installed from the AUTOEXEC.BAT file or MS-DOS command line.

1. If the computer has an 80386 or faster processor 2. If 32-Bit Dis Access was not installed in the SYSTEM.INI file (see next section) You should install the double buffer in these cases in the interest of added safety. Another new feature of SMARTDrive 4.0 that helps you determine if double buffering is necessary is the smartdrv command. Once your system is running with SMARTDrive loaded, type "smartdrv" (without the quotation mar s) at the MS-DOS prompt and press ENTER. Information similar to the following is displayed: Microsoft SMARTDrive Dis Cache version 4.0 Copyright 1991, 1992 Microsoft Corp. Cache size: 1,048,576 bytes Cache size while running Windows: 1,048,576 bytes Dis Caching Status drive read cache write cache buffering --------------------------------------------------A: yes no no B: yes no no C: yes yes yes D: yes yes --For help, type "Smartdrv /?". Note the column labeled "buffering." For each drive that is being cached, one of three values is displayed--"yes," indicating that double buffering is needed; "no," indicating that double buffering is not needed; or "---," indicating that SMARTDrive has not yet determined the necessity of double buffering. If the buffering column

Most dis MFM, RLL, The Setup following

controllers do not need double buffering. These include all and IDE controllers as well as many ESDI and SCSI devices. program in Windows 3.1 will install the double buffer in the cases:

displays a "no" for each drive, the double buffer driver is unnecessary, and you can safely remove it from your CONFIG.SYS file. Setting Up SMARTDrive 4.0 ------------------------The Setup program in Microsoft Windows 3.1 automatically installs SMARTDrive (SMARTDRV.EXE) in the first line of your AUTOEXEC.BAT file. In general, you should let the Setup program configure SMARTDrive's cache size for you. However, please note it is critical that SMARTDRV.EXE load after any bloc devices that reside on your system, such as: - Hard dis partitioning software (for example, DMDRVR.BIN and SSTOR.SYS) - Hard dis drivers (for example, SCSI drives, hard cards, and Bernoulli drives) - Data encryption software (for example, Stac er and DoubleDis ) The configuration of SMARTDRV.EXE is controlled by command-line parameters. Most configuration options can be modified without restarting; however, without the Windows Resource Kit utility SMARTDrive Monitor (SMARTMON.EXE), the configuration cannot be altered while running Windows. Also note that SMARTDrive: - Needs a minimum cache size of 16K. - Creates a cache size of 16K by default if you supply an invalid cache size. - Gives you benefits up to a cache size of 2 MB, whereupon the benefits typically plateau. 32-BIT DISK ACCESS ================== Another new feature of Windows 3.1 is its use of 32-Bit Dis Access. 32-Bit Dis Access is not a program but rather a term used to refer to a system of Windows components wor ing together. The main purpose of these components is to allow Windows to interact directly with the hard dis , bypassing the BIOS, which is normally used for communicating with the hard dis . Under 386 enhanced mode Windows, where 32-Bit Dis Access is supported, you get the following benefits: - Faster hard dis access - Ability to run more MS-DOS-based applications - Faster overall system response, even when running MS-DOS-based applications in the bac ground - More powerful off-the-shelf dis utilities to choose from, since independent software vendors (ISVs) are writing programs that ta e advantage of this new set of services WHAT IS 32-BIT DISK ACCESS? =========================== - A SYSTEM OF WINDOWS COMPONENTS. Some of these components are called 32-Bit Dis Access devices, but they are useless without the rest of the components to support them. Each of these components is discussed below.

- A REPLACEMENT FOR THE HARD DISK BIOS. 32-Bit Dis Access serves as a device driver that interacts with the hard dis controller. 32-Bit Dis Access watches for INT13H calls and handles them if they are for the dis it represents; otherwise, it passes the calls on to the BIOS in the usual way, as if 32-Bit Dis Access were not available. - AN EXACT MATCH FOR THE HARD DISK CONTROLLER (NOT THE SPECIFIC HARD DISK). There are some standards for hardware communication that wor on many different controllers. The most widely adopted standard is that introduced by Western Digital in its 1003 controllers. This is the standard supported by Windows 3.1 and more than 90 percent of hard dis controllers, with the exception of ESDI and SCSI controllers. - AN OPEN STANDARD FOR CERTAIN CONTROLLERS. 32-Bit Dis Access is an open standard that is being promoted to all manufacturers of hard dis controllers. This means that every manufacturer has the opportunity to write a device driver that supports 32-Bit Dis Access functionality for its hardware. Many hardware manufacturers are writing 32-Bit Dis Access device drivers that will be available at the time Windows 3.1 ships or shortly thereafter. - AN OPTION, NOT A SYSTEM REQUIREMENT. Without the 32-Bit Dis Access device driver installed, you lose the hardware-access benefits provided by 32-Bit Dis Access, but your system is otherwise unaffected. Windows 3.1 without 32-Bit Dis Access has the same dis access capabilities of Windows 3.0. DISK ACCESS UNDER MS-DOS ======================== The 32-Bit Dis Access feature bypasses the system BIOS to more directly control hard dis access. It acts, in a sense, as the hard dis controller. Before discussing how dis access has changed under Windows 3.1, let's loo at how MS-DOS handles calls to the hard dis . In the MS-DOS-based PC, when an application wants to read from the dis , it trac s the following sequence: INT21H ------> ----| APP | ---------|MS-DOS| ------

INT13H -----> ---|BIOS| ----

H/W I/O -----> -------------|Controller| ->|Drive| --------------

1. The application ma es an INT21H call to MS-DOS. 2. MS-DOS locates the requested part of the file on the hard dis . 3. MS-DOS issues an INT13H call to tal to the hard dis BIOS. The BIOS contains a program to control each device in the system. 4. The BIOS driver tal s directly to the hard dis controller. Each hard dis controller requires its own BIOS driver, but these BIOS drivers are usually not specific to the hard dis itself, but

rather to the controller board (or adapter) that connects the hard dis to the rest of the system. This system wor s well, because MS-DOS is able to identify the files and directories and eep trac of their locations, regardless of the type of hard dis MS-DOS is accessing. But, on the other hand, the system BIOS is wholly lin ed to the hard dis , which provides dis independence for the applications but does not allow the BIOS to differentiate between a call from MS-DOS or a program such as SMARTDrive. But remember that not all dis device drivers reside in ROM. If you purchase an off-the-shelf dis drive and install it, your computer's ROM BIOS may not now how to communicate with it. If this is the case, you must install a device driver that is specific to your new hard dis . This additional device driver is usually installed in your CONFIG.SYS file when you install the software that comes with your hard dis . With some devices, such as a CD-ROM drive, a device driver that provides the BIOS interface and INT13H interface to the CD-ROM drive appears in your AUTOEXEC.BAT file. This type of device driver traps INT13H calls to the hard dis and ma es sure the calls are understood by the hard dis . Usually, the device driver handles any attempts to access the hard dis ; the calls never get passed on to the real ROM BIOS. If the call is not for the device that the device driver represents, then the INT13H call is passed on to the BIOS, where it is handled in the usual way. 32-Bit Dis Access represents a way for Windows to provide a BIOS that better suits customers' device support needs. 32-BIT DISK ACCESS SPEEDS UP DISK ACCESS ======================================== On many machines, the resident hard dis BIOS is slow and inefficient. Since 32-Bit Dis Access is specific to devices, it is often more efficient, leading to very impressive performance increases. 32-Bit Dis Access also allows Windows 3.1 to handle BIOS requests in protected mode, rather than in real mode, which may also speed up dis access. The following diagram charts the flow of calls under Windows in standard mode: INT21H ------> ----| APP | ---------|MS-DOS| -----INT13H -----> ---|BIOS| ----

H/W I/O -----> -------------|Controller| ->|Drive| --------------

Under 386 enhanced mode Windows, the flow of calls is more complicated: ------------------------------------------------Enhanced Mode Virtual Devices | ------------------------------------------------Protected / \ / \ Mode / \ / \ ----------/-----\------/--------\----------------------------------Virtual / \ / \ |

Mode / \ / \ ----- INT21H ------ INT13H ---H/W -------------| APP | |MS-DOS| |BIOS| I/O |Controller|-->|Drive| ------------- -----> -------------Windows 3.1 and Windows applications run in protected mode. Windows has to switch bac into real mode (or virtual 8086 mode) to run older code (for MS-DOS and the BIOS calls, for example). Switching modes is very time consuming. For example, when a non-Windows application running under 386 enhanced mode tries to read from a file, the following occurs: Windows starts out in virtual mode running the application. Windows ma es an INT21H call to read from the file. 386 enhanced mode traps this interrupt and switches to protected mode, where a number of virtual device drivers loo at the call and try to qualify it. If none of the device drivers intercepts the call, the call is accepted and is subsequently handed off to MS-DOS. Windows then switches bac to virtual mode to let MS-DOS handle the call. MS-DOS reads a particular location on the dis and then generates an INT13H call to tal to the BIOS. Windows in 386 enhanced mode then traps the call again and switches to protected mode to perform certain tas s, hands the call bac to the real BIOS, and switches bac to virtual mode. The BIOS handles the call and accesses the hard dis controller to set the physical read in motion. Once the BIOS reads the call, Windows goes bac to protected mode to perform more tas s and then returns to virtual mode to let MS-DOS see the returned call. Windows returns the INT21H call, switches to protected mode to perform yet more tas s, and then finally switches bac to virtual mode to communicate with the application that issued the call to begin with. All this mode switching ta es time but is necessary due to the nature of the 80386 processor, MS-DOS, and the PC BIOS. With a 32-Bit Dis Access device installed, Windows can start trapping INT13H calls and handling them entirely in protected mode. With 32-Bit Dis Access, the call diagram now loo s li e this: ---------------------------H/W -------------|Enhanced Mode |32-Bit Dis | I/O |Controller| ->|Drive| |Virtual Devices | Access| -----> -----------------------------------------Protected / \ / Mode / \ / -----------/-------\- ----/--------------------------------------Virtual / \ / Mode / \ / ----- INT21H ------ INT13H ---| APP | |MS-DOS| |BIOS| ------------With 32-Bit Dis Access, Windows no longer has to go through two mode transitions--one mode to get to the BIOS and the other mode to get bac . Only two mode switches per INT13H call, rather than four, are now being performed.

32-BIT DISK ACCESS SUPPORT FOR NON-WINDOWS APPLICATIONS ======================================================= Sometimes Windows shows an adequate amount of free memory and large Windows-based applications run just fine, yet an "Out of Memory" message is generated when a non-Windows application is started. Also, in spite of the available memory, Windows-based applications may slow down and constantly access the hard dis after a non-Windows application is started. These discrepancies occur because of the difference between virtual memory (which is often large) and physical memory (RAM, which is usually limited). On a given machine, virtual memory might be four times the size of RAM. But, while virtual memory wor s well for Windows-based applications, it doesn't always meet all the system's memory needs for MS-DOS-based applications. Because each non-Windows application runs in its own virtual machine, each application ta es up 640K or more of virtual memory. When the virtual machine is actually running, all of the program code needs to occupy RAM. Parts of the non-Windows application cannot be paged out while eeping other parts in RAM, as is the case with Windows-based applications. The virtual machine in which the non-Windows application runs must be treated as a single bloc . This is true even if the application is currently inactive in the bac ground. With Windows-based applications, most of the program remains resident on the hard dis , while only the parts that are actually being used are loaded in RAM. Problems occur when Windows tries to do this with non-Windows-based applications. If a part of the application that is not currently being used--a data buffer, for example--is paged out, it can always be read bac in whenever the application needs to access it. However, if the application ma es a call to MS-DOS to read some data from the dis into a buffer, MS-DOS starts handling the call by ma ing a call to INT13H to tal to the BIOS, which in turn tal s to the hard dis controller, resulting in the transfer of data into the buffer. So when the application needs to transfer the page into the buffer, which is currently out on dis , the application tries to call MS-DOS to read the page. Because MS-DOS is already occupied, the application can't call MS-DOS; and MS-DOS is not reentrant, so the second call from the application fails. Nor can the application have the page read by calling the BIOS, because the BIOS is also in the middle of a call, so it can't be reentered either. This situation results in a type of deadloc : the application can't let the current call finish until the page is put in the buffer, but the page cannot be placed in the buffer until the current call finishes. The only way to ensure that this deadloc situation does not occur is to ma e sure that Windows never has to page anything in while the application is in the middle of an MS-DOS or BIOS call. Because Windows cannot predict ahead of time what the application will try to access, the only way to be 100-percent safe from deadloc ing is to ma e sure everything the application might try to access is already in RAM (that is, never paged out to dis ). In other words, all 640K-plus of the virtual machine in which the non-Windows application is running

has to remain resident in RAM, thereby using up a lot of physical memory. Running several non-Windows-based applications at once uses large amounts of RAM, so you may soon end up with only a small amount of free RAM left for everything else you're trying to do, such as run Windows-based applications. When you chec the Program Manager About dialog box (from the Help menu), it shows that you have plenty of memory--virtual memory--and you do. But if you try to start another non-Windows application, which requires yet another 640K of RAM, the application won't start. So, Windows starts running sluggishly and/or may generate the "Out of Memory" message. So how does 32-Bit Dis Access help? Windows 3.0 offered a contiguous paging file (which is created with Swapfile) for any pages using the INT13H BIOS calls. Windows 3.1 handles the same tas by ma ing calls to the 32-Bit Dis Access system. Unli e MS-DOS or the BIOS, the 32Bit Dis Access system can queue up multiple requests and is completely reentrant. Windows no longer needs to rely on MS-DOS or the BIOS; so regardless of what the application is doing, Windows can always page calls in from the hard dis . Free from a potential deadloc situation, Windows 3.1 can now ma e the virtual machines that are running completely pageable. Non-Windows-based applications no longer need to ta e up so much RAM, since they can now use virtual memory the way Windows-based applications do. When Windows needs some RAM space, it can now page out pieces of these virtual machines. With Windows 3.1 and 32-Bit Dis Access, you can run multiple nonWindows-based applications and Windows-based applications without generating an "Out of Memory" message. When the About box tells you that you have 14 MB of memory, you can actually use all 14 MB for running your applications, whether they are Windows or non-Windows. Improved Performance for Non-Windows Applications Under Windows --------------------------------------------------------------In the previous example, we saw how 32-Bit Dis Access in Windows can page non-Windows-based applications to free up enough RAM for those applications when they need to use it. The 32-Bit Dis Access feature also improves Windows performance all around, ma ing the system run much more quic ly. Switching between non-Windows-based applications by pressing ALT+TAB is faster with 32-Bit Dis Access. Without 32-Bit Dis Access, a nonWindows application can only be swapped out to dis if it is configured to not run in the bac ground. This means when you press ALT+TAB to switch to such an application, Windows has to read the entire program into RAM, causing the tas switching to ta e a long time. When Windows is paging using 32-Bit Dis Access, Windows can load in just the small amount of information that the application is actually using, so tas switching becomes almost instant. And, since only a small part of the application needs to be in RAM at one time, Windows may not have to access the hard dis at all. THE COMPONENTS OF THE 32-BIT DISK ACCESS SYSTEM =============================================== The 32-Bit Dis Access system is composed of the following 386 enhanced mode virtual devices:

- WDCTRL, which is the 32-Bit Dis

Access device that tal s to

standard Western Digital 1003 or ST506 hard dis controllers (about 90 percent of the installed base). WDCTRL is only installed if Setup detects a compatible hard dis controller. - Bloc Dev, which coordinates calling bloc I/O services between devices and the 32-Bit Dis Access devices that provide those services for specific hard dis controllers. Bloc Dev is always installed. - PageFile, which handles the virtual memory paging file and calls through Bloc Dev if any 32-Bit Dis Access devices are available. PageFile is always installed. - INT13, which traps and emulates INT13H BIOS calls by calling Bloc Dev. INT13 is only installed if at least one 32-Bit Dis Access device is present.

device=*int13 device=*wdctrl If you want to disable 32-Bit Dis Access, start the Control Panel and choose the 386 Enhanced icon, or comment the lines out of your system by placing a semicolon (;) at the beginning of both lines. You do not need to delete any files from your hard dis , as the 32-Bit Dis Access devices are contained within the file WIN386.EXE. 32-BIT DISK ACCESS AND HARD DISK PROTECTION =========================================== Microsoft identified machines where the use of WDCTRL can stop the system. Usually, this is caused by hard dis controllers that appear to be Western Digital 1003 compatible but are really not. WDCTRL has been put though rigorous testing to ma e sure it is as safe as possible, and is designed with a built-in safety measure--every time it starts, it performs elaborate tests to ma e sure it can communicate in the same language as the hard dis controller before it attempts to read and write data. WDCTRL starts testing by ta ing a peripheral loo at some data on the hard dis for tell-tale traces of a Western Digital 1003-compatible controller. If the controller passes that test, WDCTRL then starts calling up larger pieces of data to try to elicit the correct response. Finally, after much redundant chec ing, WDCTRL tries actually reading data from the dis . If it is able to read data, WDCTRL then tries to write data and read it bac . Only after the read/write test is passed does WDCTRL continue and start Windows, reassured that it will not cause any catastrophic errors on the hard dis . However, there are still a few exceptions. There are drives that appear to be WD1003 compatible but are not, and which cannot be detected by WDCTRL. In addition, there can be problems even with compatible controllers on some portable computers, specifically those that power down the hard dis to conserve power without telling the running software. If the dis is powered down and then bac up while

Because WDCTRL is the only 32-Bit Dis Access device included in the Windows box, the standard Windows components only support 32-Bit Dis Access for Western Digital-standard controllers. When you run Setup, it automatically detects these controllers and adds the following lines to the [386Enh] section of your SYSTEM.INI file:

it is being trac ed by WDCTRL, the trac ing information will be incorrect, and serious damage can result. For these reasons, 32-Bit Dis Access is not turned on by default. When you install Windows, 32Bit Dis Access is disabled until you ma e the decision to enable it through Control Panel. Only original equipment manufacturers (OEMs) who preinstall Windows 3.1 on a 100-percent-compatible system can turn 32-Bit Dis Access on before the user receives the system without jeopardizing the user's hard dis . When something does go wrong, WDCTRL may do different things, depending on where it is in its verification code. The initial tests have reported WDCTRL as extremely safe. The controllers that WDCTRL fails with are considered incompatible with 32-Bit Dis Access, so WDCTRL simply does not load when it senses these unsupported controllers. This procedure is invisible to the user; he or she just won't receive the benefits of 32-Bit Dis Access. If WDCTRL fails a test after it is installed, Windows displays an error message that warns that something is wrong, most li ely that the hard dis might have been damaged, and advises to restart the machine (so that WDCTRL does not load, and 32-Bit Dis Access is disabled). THIRD-PARTY 32-BIT DISK ACCESS DEVICES ====================================== Windows 3.1 ships with only one 32-Bit Dis Access device--WDCTRL. However, Microsoft is wor ing with most of the major hardware and software vendors to help them design 32-Bit Dis Access devices for their products. Concerns regarding distribution and quality of testing for these third-party devices are currently being addressed.