Why did Windows 95 hang when formatting a floppy?

Raymond Chen responds to a well-known joke:
- Dad, show me what a multitasking Windows!
- Now, son, only I will format the floppy ...

Who is the whole day formats a floppy disk? It turns out that many geeks are just that busy. (Actually, you can buy diskettes already formatted, only tsss!) But why did Windows 95 hang up when formatting floppy disks?

It's all about MS-DOS compatibility.

As we saw a little earlier , MS-DOS in Windows 95 appeared as a layer for old 16-bit drivers. Despite the fact that, as a result, I / O operations were processed by the 32-bit file subsystem, they all passed through 16-bit code so that 16-bit drivers, TSR and similar processors could see “normal 16-bit operations” and work in their usual surrounded by
')
In the 16-bit world, software interrupt 13h was used for formatting, and many programs used this fact, intercepting the interrupt so as to get control when formatting a floppy disk. So did some TSR, backup programs (backup programs developed for Windows 3.0 included 32-bit drivers for Windows 3.x, called VxD, to track floppy disk operations). But this does not explain everything. In the end, Windows 95 drove all the disk I / O, and not just the formatting of floppy disks, through 16-bit code. Why is the formatting of floppy so significantly affect the system?

As I noted in the article at the link above, the 32-bit file subsystem carefully forged the evidence, forcing the 16-bit code to believe that MS-DOS was responsible for everything, although this was not true. Anyone who has been programming TSR (wow, the definition anyone who has been programming TSR has once covered a lot of people, and today describes dozens of experienced programmers, most of whom would like to forget it like a bad dream), knows everything about the INDOS flag. MS-DOS set this flag at the time the I / O request was processed. Since MS-DOS did not allow the nested call itself, TSR had to carefully monitor this flag in order to know if it was safe to access MS-DOS. The INDOS flag was a 16-bit reflection of the entity, which the 32-bit kernel called the Main Critical Section ; The 32-bit kernel kept the main critical section and the INDOS flag in the same state so as not to cause 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 tried to do the same had to wait until the first virtual machine released the section. Thus, parallel calls to the driver or TSR were blocked.

As I have already noted, in the 16-bit world, the ROM BIOS itself dealt with the formatting itself, and for compatibility purposes, the formatting of the diskettes was still sent through a 16-bit software interrupt 13h so that all TSRs and drivers could see what was happening. Many BIOSes are insane, so when requesting formatting a floppy disk, the 32-bit kernel did a lot of extra work for the BIOS to get exactly the environment it wanted. In particular, the hardware timer ports were transferred from the virtual machine manager to full BIOS control, so as not to interfere with the cycles used by the BIOS for formatting delays for which execution time is critical.

So, let's calculate the final damage. While the diskette is being formatted, the timer is deployed for the accuracy of cycles used by the BIOS for delays. Only a virtual machine that formats 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 begin I / O operations. All this is further aggravated by the fact that the diskette is a slow device, and any operation that waits for the end of work with the diskette has to stop and wait a few seconds.

At least it's good that floppy disks are formatted along a track at a time, and the system is not blocked for the entire time of formatting. The BIOS command is issued to format a single track, and at the end of the process the timer returns to normal (which allows the scheduler to do its work), the main critical section is unlocked (and pending I / O operations get a chance to perform). But then the FORMAT.COM program returns and formats the next track, and the system returns 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 format operations at the very end. If it worked, the driver did the job of formatting a single track instead of the BIOS. A valiant attempt, but no matter how high-performing the driver, it does not matter; track formatting speed is limited mainly by floppy mechanics.

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

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