INTRODUCTION ============Microsoft Windows operating system version 3.1 has a number ofenhancements over previous versions that improve both its usabilityand its performance. Foremost among these enhancements are Windows3.1's improved features for accessing and utilizing the hard drive ofyour PC. SMARTDRIVE 4.0 DISK CACHE =========================Microsoft's first release of the Windows graphical environmentincluded a disk caching program called SMARTDrive 3.03. SMARTDrive hasbeen improved with each subsequent release of Windows and has beenentirely redesigned in Windows version 3.1. SMARTDrive 4.0 in Windows3.1 provides faster and more intelligent disk caching that takesbetter advantage of the revolutionary way that Windows and Windows-based applications use extended memory.SMARTDrive 4.0 gives Windows 3.1: - Improved performance by speeding up hard disk and RAM access. - Improved stability in 386 enhanced mode by double buffering data when needed.The remainder of this section compares the performance of SMARTDrive4.0 to SMARTDrive 3.x and illustrates how SMARTDrive 4.0 works at amore technical level.WHAT IS SMARTDRIVE?===================SMARTDrive is a disk caching program that intercepts system calls tothe hard disk to control read/write access to the disk. SMARTDriveintercepts any calls to the hard disk and loads the needed data into acache it establishes in RAM. (Unless specified otherwise, SMARTDriveautomatically determines a reasonable cache size based on the amountof free extended memory available when it initially loads; the maximumamount it will take is around 2 MB.) Subsequent calls to the hard diskare intercepted by SMARTDrive, which scans the cache for the requesteddata. If the data is already present in the cache, SMARTDrive canaccess it directly in RAM. If the data is not in the cache, SMARTDriveaccesses the hard disk and loads the necessary data into the cache.The least recently used data residing in RAM is cached back to thehard disk to make room for the new data. By loading blocks of datafrom the hard disk into RAM, SMARTDrive helps decrease the number ofcalls to the hard disk. This can dramatically speed up applicationsthat repeatedly access the hard disk for data because accessing thehard disk is considerably slower than accessing RAM. Essentially,SMARTDrive attempts to maintain information in RAM that an applicationneeds at any given time from the hard disk.SMARTDRIVE 3.X==============To understand why SMARTDrive needed to be redesigned, lets look athow SMARTDrive 3.x works and examine some of the shortcomings of itsdesign. First, SMARTDrive 3.x is a read-only track cache, which meansthat it caches on a track basis and for read operations only. Thismeans that the internal data structures of the SMARTDrive program aretied to the logical geometry of the disk (that is, what MS-DOS sees).In the diagram below, you can see that SMARTDrive 3.x caches at theROM BIOS INT13 level and uses the BIOS-specified disk geometry todecide the size of its caching element (that is, track size). INT13 isthe most common method for interacting with hard disks (and hasevolved into the industry standard). SMARTDrive under Windows 3.0 canbe 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 DriveSMARTDRIVE 4.0==============SMARTDrive 4.0 is designed as a block-oriented disk cache. It hooksinto the system at the MS-DOS device driver level rather than at theROM BIOS INT13 level (as with SMARTDrive 3.x). Each block devicedriver on the MS-DOS device driver chain is "front-ended" by aSMARTDrive 4.0 module that provides the actual caching. This newdesign yields the following benefits: - It is independent of the INT13 interface. - It is independent of disk geometry. Application (Read/Write INT21) |- - - - - - - - - - - - - - - | MS-DOS Call HD Driver | ---------> SMARTDrive 4.0 HOOKS Driver ---------< | HD Driver INT 13 | ROM BIOS | Hard DriveIndependent of INT13 Interface------------------------------Many device drivers do not use the INT13 (BIOS) interface (forexample, Bernoulli drives, some hard cards, and many SCSI and WORMdrives). This means that SMARTDrive 4.0 can cache these devices,whereas SMARTDrive 3.x cannot. SMARTDrive 4.0 can cache any diskcontroller that uses an MS-DOS block device driver.Independent of Disk Geometry----------------------------Some disk managers and disk controllers use a disk geometry mappingscheme that causes the logical geometry to be different from thephysical geometry (for example, many PS/2 systems, Ontrack's DiskManager, and several disk controllers). The INT13-based disk cachesare sensitive to this and often have problems. For example, some diskmanagement software actually changes the ROM BIOS-specified diskgeometry, which confuses INT13-based disk caches (including SMARTDrive3.x).There usually is an interface to determine the true geometry, but thisrequires detection of the specific disk manager driver and generallycomplicates the disk cache software. Often, logical tracks actuallycross physical track boundaries, causing the track caches to incurperformance penalties (intertrack seeks and rotational latencies, forexample). To get around the ROM BIOS 1024-cylinder limitation, diskmanagers and controllers sometimes fold multiple tracks into onelogical track. This results not only in problems with the physicaltrack boundaries as noted above, buts forces track caches to have avery large track buffer as well. In some cases, this buffer can be aslarge as 31.5K and must reside in conventional memory. The design ofSMARTDrive 4.0 eliminates this geometry mismatch problem.OTHER SMARTDRIVE 4.0 FEATURES=============================Write-Behind Cache------------------SMARTDrive 4.0 is a write-behind cache, also known as lazy write. Awrite-behind cache adds significant performance improvements whereverfiles are being written to disk. For example, an application writesdata to what it thinks is the hard disk. SMARTDrive takes this dataand places it in the cache, rather than physically writing it to thedisk. This write-behind data stays in the cache until one of thefollowing occurs:1. The cache fills up. The oldest block in the cache is freed up, and if it is write-behind data, physically written to the disk.2. The system goes idle. SMARTDrive writes the oldest write-behind data block to the physical disk. As long as the system is idle, SMARTDrive continues to write to the disk until all the write- behind 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 write- behind data to the physical disk. This is a synchronous operation-- SMARTDrive does not give up control until all data is written.4. A block is older than five seconds. If a block is older than five seconds, it is written to the physical disk.Shrink Algorithm----------------Similar to SMARTDrive 3.x, SMARTDrive 4.0 implements a shrinkalgorithm that frees memory for Windows (that is, the cache set up bySMARTDrive is removed from memory). The difference is that SMARTDrive4.0 watches for the Windows startup broadcast while SMARTDrive 3.xprovides an IOCTL interface. The net effect is identical, but theSMARTDrive 4.0 code is much simpler. Upon exiting Windows, the processis reversed and the memory is reacquired by SMARTDrive 4.0.Automatic Load High-------------------When an upper memory block (UMB) provider (such as EMM386.EXE) isloaded, SMARTDrive 4.0 (SMARTDRV.EXE) automatically attempts to loaditself high. Unlike the Windows 3.0 SMARTDrive, SMARTDrive 4.0 canonly be loaded into extended memory.DOUBLE BUFFERING AND BUS MASTERING==================================The second major benefit of SMARTDrive 4.0 is the protection itprovides through double buffering. Double buffering is a response tobus mastering, which is supported by certain (usually older) diskcontrollers. Bus mastering refers to a situation in which the harddisk controller takes over the bus to directly transfer data to orfrom system RAM, bypassing the CPU entirely. A problem occurs whenWindows 3.x virtual machines and/or popular memory managers (such asEMM386.EXE and QEMM.SYS) are running in virtual 8086 mode. The read orwrite address that is passed to MS-DOS from the bus master controlleris often not the same as the actual physical memory address. This cancause data to be read from the wrong location, or worse, can causedata to be written to the wrong RAM address, resulting in erraticsystem behavior and potential file corruption.When paging is enabled on an 80386 or faster processor, it is possiblefor the physical address (the actual location of the memory) to bedifferent from the virtual address (the address that programs areusing to access memory). Paging is enabled by all device drivers thatcan provide load high capability and by Windows in 386 enhancedmode. For example, say SMARTDrive wants to write to an area of memorythat has a virtual address in conventional memory, but a physicaladdress in extended memory. When the hard drive controller takes overthe bus and transfers data from the UMB to the disk, the controllerdoes not use the CPU, so there is no address translation, resulting inthe wrong data being written to disk. To avoid this problem, doublebuffering copies the data into a buffer in conventional memory andthen passes the information to the hard disk controller. So, thevirtual address always equals the physical address when using devicesthat only recognize conventional memory.Installing Double Buffering---------------------------To install the SMARTDrive double-buffering feature, add the followingline to your CONFIG.SYS file: device=c:\windows\smartdrv.exe /double_bufferIncluding this line does not install the cache, only the double-buffering driver. The cache must be installed from the AUTOEXEC.BATfile or MS-DOS command line.Most disk controllers do not need double buffering. These include allMFM, RLL, and IDE controllers as well as many ESDI and SCSI devices.The Setup program in Windows 3.1 will install the double buffer in thefollowing cases:1. If the computer has an 80386 or faster processor2. If 32-Bit Disk Access was not installed in the SYSTEM.INI file (see next section)You should install the double buffer in these cases in the interest ofadded safety. Another new feature of SMARTDrive 4.0 that helps youdetermine if double buffering is necessary is the smartdrv command.Once your system is running with SMARTDrive loaded, type "smartdrv"(without the quotation marks) at the MS-DOS prompt and press ENTER.Information similar to the following is displayed: Microsoft SMARTDrive Disk Cache version 4.0 Copyright 1991, 1992 Microsoft Corp. Cache size: 1,048,576 bytes Cache size while running Windows: 1,048,576 bytes Disk 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 beingcached, one of three values is displayed--"yes," indicating thatdouble buffering is needed; "no," indicating that double buffering isnot needed; or "---," indicating that SMARTDrive has not yetdetermined the necessity of double buffering. If the buffering columndisplays a "no" for each drive, the double buffer driver isunnecessary, 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 installsSMARTDrive (SMARTDRV.EXE) in the first line of your AUTOEXEC.BAT file.In general, you should let the Setup program configure SMARTDrive'scache size for you. However, please note it is critical thatSMARTDRV.EXE load after any block devices that reside on your system,such as: - Hard disk partitioning software (for example, DMDRVR.BIN and SSTOR.SYS) - Hard disk drivers (for example, SCSI drives, hard cards, and Bernoulli drives) - Data encryption software (for example, Stacker and DoubleDisk)The configuration of SMARTDRV.EXE is controlled by command-lineparameters. Most configuration options can be modified withoutrestarting; however, without the Windows Resource Kit utilitySMARTDrive Monitor (SMARTMON.EXE), the configuration cannot be alteredwhile 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 Disk Access.32-Bit Disk Access is not a program but rather a term used to refer toa system of Windows components working together. The main purpose ofthese components is to allow Windows to interact directly with thehard disk, bypassing the BIOS, which is normally used forcommunicating with the hard disk. Under 386 enhanced mode Windows,where 32-Bit Disk Access is supported, you get the following benefits: - Faster hard disk access - Ability to run more MS-DOS-based applications - Faster overall system response, even when running MS-DOS-based applications in the background - More powerful off-the-shelf disk utilities to choose from, since independent software vendors (ISVs) are writing programs that take advantage of this new set of servicesWHAT IS 32-BIT DISK ACCESS?=========================== - A SYSTEM OF WINDOWS COMPONENTS. Some of these components are called 32-Bit Disk 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 Disk Access serves as a device driver that interacts with the hard disk controller. 32-Bit Disk Access watches for INT13H calls and handles them if they are for the disk it represents; otherwise, it passes the calls on to the BIOS in the usual way, as if 32-Bit Disk 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 work 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 disk controllers, with the exception of ESDI and SCSI controllers. - AN OPEN STANDARD FOR CERTAIN CONTROLLERS. 32-Bit Disk Access is an open standard that is being promoted to all manufacturers of hard disk controllers. This means that every manufacturer has the opportunity to write a device driver that supports 32-Bit Disk Access functionality for its hardware. Many hardware manufacturers are writing 32-Bit Disk 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 Disk Access device driver installed, you lose the hardware-access benefits provided by 32-Bit Disk Access, but your system is otherwise unaffected. Windows 3.1 without 32-Bit Disk Access has the same disk access capabilities of Windows 3.0.DISK ACCESS UNDER MS-DOS========================The 32-Bit Disk Access feature bypasses the system BIOS to moredirectly control hard disk access. It acts, in a sense, as the harddisk controller. Before discussing how disk access has changed underWindows 3.1, let's look at how MS-DOS handles calls to the hard disk.In the MS-DOS-based PC, when an application wants to read from thedisk, it tracks the following sequence: H/W INT21H INT13H I/O ------> -----> -----> ----- ------ ---- ---------- -----| APP | |MS-DOS| |BIOS| |Controller| ->|Drive| ----- ------ ---- ---------- -----1. The application makes an INT21H call to MS-DOS.2. MS-DOS locates the requested part of the file on the hard disk.3. MS-DOS issues an INT13H call to talk to the hard disk BIOS. The BIOS contains a program to control each device in the system.4. The BIOS driver talks directly to the hard disk controller. Each hard disk controller requires its own BIOS driver, but these BIOS drivers are usually not specific to the hard disk itself, but rather to the controller board (or adapter) that connects the hard disk to the rest of the system.This system works well, because MS-DOS is able to identify the filesand directories and keep track of their locations, regardless of thetype of hard disk MS-DOS is accessing. But, on the other hand, thesystem BIOS is wholly linked to the hard disk, which provides diskindependence for the applications but does not allow the BIOS todifferentiate between a call from MS-DOS or a program such asSMARTDrive.But remember that not all disk device drivers reside in ROM. If youpurchase an off-the-shelf disk drive and install it, your computer'sROM BIOS may not know how to communicate with it. If this is the case,you must install a device driver that is specific to your new harddisk. This additional device driver is usually installed in yourCONFIG.SYS file when you install the software that comes with yourhard disk. With some devices, such as a CD-ROM drive, a device driverthat provides the BIOS interface and INT13H interface to the CD-ROMdrive appears in your AUTOEXEC.BAT file. This type of device drivertraps INT13H calls to the hard disk and makes sure the calls areunderstood by the hard disk. Usually, the device driver handles anyattempts to access the hard disk; the calls never get passed on to thereal ROM BIOS. If the call is not for the device that the devicedriver represents, then the INT13H call is passed on to the BIOS,where it is handled in the usual way. 32-Bit Disk Access represents away for Windows to provide a BIOS that better suits customers' devicesupport needs.32-BIT DISK ACCESS SPEEDS UP DISK ACCESS========================================On many machines, the resident hard disk BIOS is slow and inefficient.Since 32-Bit Disk Access is specific to devices, it is often moreefficient, leading to very impressive performance increases. 32-BitDisk Access also allows Windows 3.1 to handle BIOS requests inprotected mode, rather than in real mode, which may also speed up diskaccess. The following diagram charts the flow of calls under Windowsin standard mode: H/W INT21H INT13H I/O ------> -----> -----> ----- ------ ---- ---------- -----| APP | |MS-DOS| |BIOS| |Controller| ->|Drive| ----- ------ ---- ---------- -----Under 386 enhanced mode Windows, the flow of calls is morecomplicated: ------------------------------------------------- | 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. Windowshas to switch back into real mode (or virtual 8086 mode) to run oldercode (for MS-DOS and the BIOS calls, for example). Switching modes isvery time consuming. For example, when a non-Windows applicationrunning under 386 enhanced mode tries to read from a file, thefollowing occurs: Windows starts out in virtual mode running the application. Windows makes 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 look 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 back to virtual mode to let MS-DOS handle the call. MS-DOS reads a particular location on the disk and then generates an INT13H call to talk to the BIOS. Windows in 386 enhanced mode then traps the call again and switches to protected mode to perform certain tasks, hands the call back to the real BIOS, and switches back to virtual mode. The BIOS handles the call and accesses the hard disk controller to set the physical read in motion. Once the BIOS reads the call, Windows goes back to protected mode to perform more tasks 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 tasks, and then finally switches back to virtual mode to communicate with the application that issued the call to begin with.All this mode switching takes time but is necessary due to the natureof the 80386 processor, MS-DOS, and the PC BIOS. With a 32-Bit DiskAccess device installed, Windows can start trapping INT13H calls andhandling them entirely in protected mode. With 32-Bit Disk Access, thecall diagram now looks like this: ---------------------------- H/W ---------- ----- |Enhanced Mode |32-Bit Disk| I/O |Controller| ->|Drive| |Virtual Devices | Access| -----> ---------- ----- -----------------------------Protected / \ / Mode / \ / -----------/-------\- ----/---------------------------------------Virtual / \ / Mode / \ / ----- INT21H ------ INT13H ---- | APP | |MS-DOS| |BIOS| ----- ------ ----With 32-Bit Disk Access, Windows no longer has to go through two modetransitions--one mode to get to the BIOS and the other mode to getback. Only two mode switches per INT13H call, rather than four, arenow being performed.32-BIT DISK ACCESS SUPPORT FOR NON-WINDOWS APPLICATIONS=======================================================Sometimes Windows shows an adequate amount of free memory and largeWindows-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 slowdown and constantly access the hard disk after a non-Windowsapplication is started.These discrepancies occur because of the difference between virtualmemory (which is often large) and physical memory (RAM, which isusually limited). On a given machine, virtual memory might be fourtimes the size of RAM. But, while virtual memory works well forWindows-based applications, it doesn't always meet all the system'smemory needs for MS-DOS-based applications.Because each non-Windows application runs in its own virtual machine,each application takes up 640K or more of virtual memory. When thevirtual machine is actually running, all of the program code needs tooccupy RAM. Parts of the non-Windows application cannot be paged outwhile keeping other parts in RAM, as is the case with Windows-basedapplications. The virtual machine in which the non-Windows applicationruns must be treated as a single block. This is true even if theapplication is currently inactive in the background.With Windows-based applications, most of the program remains residenton the hard disk, while only the parts that are actually being usedare loaded in RAM. Problems occur when Windows tries to do this withnon-Windows-based applications.If a part of the application that is not currently being used--a databuffer, for example--is paged out, it can always be read back inwhenever the application needs to access it. However, if theapplication makes a call to MS-DOS to read some data from the diskinto a buffer, MS-DOS starts handling the call by making a call toINT13H to talk to the BIOS, which in turn talks to the hard diskcontroller, resulting in the transfer of data into the buffer. So whenthe application needs to transfer the page into the buffer, which iscurrently out on disk, the application tries to call MS-DOS to readthe 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 applicationfails. 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 bereentered either. This situation results in a type of deadlock: theapplication can't let the current call finish until the page is put inthe buffer, but the page cannot be placed in the buffer until thecurrent call finishes.The only way to ensure that this deadlock situation does not occur isto make sure that Windows never has to page anything in while theapplication is in the middle of an MS-DOS or BIOS call. BecauseWindows cannot predict ahead of time what the application will try toaccess, the only way to be 100-percent safe from deadlocking is tomake sure everything the application might try to access is already inRAM (that is, never paged out to disk). In other words, all 640K-plusof the virtual machine in which the non-Windows application is runninghas to remain resident in RAM, thereby using up a lot of physicalmemory. Running several non-Windows-based applications at once useslarge amounts of RAM, so you may soon end up with only a small amountof free RAM left for everything else you're trying to do, such as runWindows-based applications. When you check the Program Manager Aboutdialog box (from the Help menu), it shows that you have plenty ofmemory--virtual memory--and you do. But if you try to start anothernon-Windows application, which requires yet another 640K of RAM, theapplication won't start. So, Windows starts running sluggishly and/ormay generate the "Out of Memory" message.So how does 32-Bit Disk Access help? Windows 3.0 offered a contiguouspaging file (which is created with Swapfile) for any pages using theINT13H BIOS calls. Windows 3.1 handles the same task by making callsto the 32-Bit Disk Access system. Unlike MS-DOS or the BIOS, the 32-Bit Disk Access system can queue up multiple requests and iscompletely reentrant. Windows no longer needs to rely on MS-DOS or theBIOS; so regardless of what the application is doing, Windows canalways page calls in from the hard disk. Free from a potentialdeadlock situation, Windows 3.1 can now make the virtual machines thatare running completely pageable. Non-Windows-based applications nolonger need to take up so much RAM, since they can now use virtualmemory the way Windows-based applications do. When Windows needs someRAM space, it can now page out pieces of these virtual machines.With Windows 3.1 and 32-Bit Disk Access, you can run multiple non-Windows-based applications and Windows-based applications withoutgenerating an "Out of Memory" message. When the About box tells youthat you have 14 MB of memory, you can actually use all 14 MB forrunning 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 Disk Access in Windows canpage non-Windows-based applications to free up enough RAM for thoseapplications when they need to use it. The 32-Bit Disk Access featurealso improves Windows performance all around, making the system runmuch more quickly.Switching between non-Windows-based applications by pressing ALT+TABis faster with 32-Bit Disk Access. Without 32-Bit Disk Access, a non-Windows application can only be swapped out to disk if it isconfigured to not run in the background. This means when you pressALT+TAB to switch to such an application, Windows has to read theentire program into RAM, causing the task switching to take a longtime. When Windows is paging using 32-Bit Disk Access, Windows canload in just the small amount of information that the application isactually using, so task switching becomes almost instant. And, sinceonly a small part of the application needs to be in RAM at one time,Windows may not have to access the hard disk at all.THE COMPONENTS OF THE 32-BIT DISK ACCESS SYSTEM===============================================The 32-Bit Disk Access system is composed of the following 386enhanced mode virtual devices: - WDCTRL, which is the 32-Bit Disk Access device that talks to standard Western Digital 1003 or ST506 hard disk controllers (about 90 percent of the installed base). WDCTRL is only installed if Setup detects a compatible hard disk controller. - BlockDev, which coordinates calling block I/O services between devices and the 32-Bit Disk Access devices that provide those services for specific hard disk controllers. BlockDev is always installed. - PageFile, which handles the virtual memory paging file and calls through BlockDev if any 32-Bit Disk Access devices are available. PageFile is always installed. - INT13, which traps and emulates INT13H BIOS calls by calling BlockDev. INT13 is only installed if at least one 32-Bit Disk Access device is present.Because WDCTRL is the only 32-Bit Disk Access device included in theWindows box, the standard Windows components only support 32-Bit DiskAccess for Western Digital-standard controllers. When you run Setup,it automatically detects these controllers and adds the followinglines to the [386Enh] section of your SYSTEM.INI file: device=*int13 device=*wdctrlIf you want to disable 32-Bit Disk Access, start the Control Panel andchoose the 386 Enhanced icon, or comment the lines out of your systemby placing a semicolon (;) at the beginning of both lines. You do notneed to delete any files from your hard disk, as the 32-Bit DiskAccess 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 thesystem. Usually, this is caused by hard disk controllers that appearto be Western Digital 1003 compatible but are really not. WDCTRL hasbeen put though rigorous testing to make sure it is as safe aspossible, and is designed with a built-in safety measure--every timeit starts, it performs elaborate tests to make sure it can communicatein the same language as the hard disk controller before it attempts toread and write data. WDCTRL starts testing by taking a peripheral lookat some data on the hard disk for tell-tale traces of a WesternDigital 1003-compatible controller. If the controller passes thattest, WDCTRL then starts calling up larger pieces of data to try toelicit the correct response. Finally, after much redundant checking,WDCTRL tries actually reading data from the disk. If it is able toread data, WDCTRL then tries to write data and read it back. Onlyafter the read/write test is passed does WDCTRL continue and startWindows, reassured that it will not cause any catastrophic errors onthe hard disk.However, there are still a few exceptions. There are drives thatappear to be WD1003 compatible but are not, and which cannot bedetected by WDCTRL. In addition, there can be problems even withcompatible controllers on some portable computers, specifically thosethat power down the hard disk to conserve power without telling therunning software. If the disk is powered down and then back up whileit is being tracked by WDCTRL, the tracking information will beincorrect, and serious damage can result. For these reasons, 32-BitDisk Access is not turned on by default. When you install Windows, 32-Bit Disk Access is disabled until you make the decision to enable itthrough Control Panel. Only original equipment manufacturers (OEMs)who preinstall Windows 3.1 on a 100-percent-compatible system can turn32-Bit Disk Access on before the user receives the system withoutjeopardizing the user's hard disk.When something does go wrong, WDCTRL may do different things,depending on where it is in its verification code. The initial testshave reported WDCTRL as extremely safe. The controllers that WDCTRLfails with are considered incompatible with 32-Bit Disk Access, soWDCTRL simply does not load when it senses these unsupportedcontrollers. This procedure is invisible to the user; he or she justwon't receive the benefits of 32-Bit Disk Access. If WDCTRL fails atest after it is installed, Windows displays an error message thatwarns that something is wrong, most likely that the hard disk mighthave been damaged, and advises to restart the machine (so that WDCTRLdoes not load, and 32-Bit Disk Access is disabled).THIRD-PARTY 32-BIT DISK ACCESS DEVICES======================================Windows 3.1 ships with only one 32-Bit Disk Access device--WDCTRL.However, Microsoft is working with most of the major hardware andsoftware vendors to help them design 32-Bit Disk Access devices fortheir products. Concerns regarding distribution and quality of testingfor these third-party devices are currently being addressed.
Article ID: 83325 - Last Review: 06/17/2014 21:44:00 - Revision: 2.0
ame='ms.dqp0';m.content='true';document.getElementsByTagName('head').appendChild(m);" onload="var m=document.createElement('meta');m.name='ms.dqp0';m.content='false';document.getElementsByTagName('head').appendChild(m);" src="http://c1.microsoft.com/c.gif?">