Why did Windows 95 freeze when formatting a floppy disk?

Original author: Raymond Chen
  • Transfer
Raymond Chen answers a famous joke:
- Dad, show me which Windows is multitasking!
- Now, son, I’ll just format the floppy disk ...

Who formats diskette all day long? It turns out that many geeks are only busy with this. (Actually, you can buy floppy disks already formatted, only shhh!) But why did Windows 95 hang when formatting a floppy disk?

It's all about compatibility with MS-DOS.

As we saw a little earlier , MS-DOS in Windows 95 acted as a layer for old 16-bit drivers. Despite the fact that I / O operations were processed by a 32-bit file subsystem, they all went through 16-bit code so that 16-bit drivers, TSR, and similar processors saw “normal 16-bit operations” and worked in their usual way surrounded by.

In the 16-bit world, 13h software interrupt was involved in formatting, and many programs used this fact by intercepting the interrupt so as to gain control when formatting a floppy disk. Some TSR backup programs did this (backup programs developed for Windows 3.0 included 32-bit drivers for Windows 3.x, called VxD, for tracking disk operations). But this does not explain everything. In the end, Windows 95 drove all disk I / O, not just floppy disk formatting, through 16-bit code. Why did formatting floppy disks so significantly affect the system?

As I noted in the article from the link above, the 32-bit file subsystem carefully faked evidence, forcing the 16-bit code to believe that MS-DOS was responsible for everything, although this was not true. Anyone who was involved in TSR programming (wow, the definition of anyone who was involved in TSR programming once covered a lot of people, and today describes several dozen experienced programmers, most of whom would like to forget this as a nightmare), knows everything about the INDOS flag. MS-DOS set this flag during the processing of an I / O request. Since MS-DOS did not allow a nested call to itself, TSR had to carefully monitor this flag to know whether it was safe to access MS-DOS. The INDOS flag was a 16-bit reflection of the entity that the 32-bit kernel calledMain Critical Section ; The 32-bit kernel kept the main critical section and the INDOS flag in the same state, so as not to call the same MS-DOS or TSR driver in parallel several times. When one virtual machine captured the main critical section, any other virtual machine that attempted to do the same was forced to wait until the first virtual machine released the section. Thus, parallel calls to the driver or TSR were blocked.

As I already noted, in the 16-bit world, the ROM BIOS itself was engaged in formatting, and for compatibility purposes, floppy disk formatting was still sent via 13h software 16-bit interrupt so that all TSRs and drivers could see what was happening. Many BIOSes are crazy, so when requesting disk formatting, the 32-bit kernel did a lot of extra work so that the BIOS would get exactly the environment it wanted. In particular, the ports of the hardware timer passed from the manager of virtual machines under the full control of the BIOS, so as not to affect the operation of the cycles used by the BIOS for formatting delays for which runtime is critical.

So, let's calculate the total damage. While the floppy disk is being formatted, the timer is virtualized for the precision of the cycles the BIOS uses for delays. Only a virtual machine formatting a floppy disk receives signals from a timer; the rest have to wait. The absence of timer signals means that no one calls the scheduler with the message "it's time to let another thread work." Further, the main critical section is locked for the duration of the operation, which means that no other thread can start I / O operations. All this is compounded by the fact that the diskette is a slow device, and any operation that is waiting for the diskette to finish working has to stop and wait a few seconds.

It’s good, at least, that floppy disks are formatted along the track at a time, and the system is not blocked for the whole time of formatting. The BIOS instructs you to format one track, and at the end of the process, the timer returns to its normal state (which allows the scheduler to do its job), the main critical section is unlocked (and pending I / O operations get a chance to execute). But then the FORMAT.COM program returns and formats the next track, and the system goes back to the wait state , we will not distract the BIOS from work .

Similar to the case of the 32-bit file subsystem, there was a 32-bit floppy driver trying to intercept formatting operations at the very end. If this worked out, the driver did the job of formatting one track instead of the BIOS. A brave attempt, but no matter how high the driver may be, it does not matter; The formatting speed of a track is mainly limited by floppy disk mechanics.

Of course, if Windows 95 were not to support compatibility with 16-bit drivers, TSR and questionable BIOS, it could send formatting requests directly to the 32-bit floppy driver, without being distracted by the absurd operations with the timer and the main critical section. But actually we already had a system that refused compatibility with 16-bit drivers, TSR, 16-bit Windows-programs with its own 32-bit VxD-drivers and questionable BIOS. It was called Windows NT .

If you wanted Windows NT, you knew where to find it.

Also popular now: