Why doesn’t Windows 95 format floppy disks smoothly?


Welcome, Slashdot readers. Remember, this Web site is for entertainment purposes only.

Who spends all day formatting floppy disks? From the reaction of geekdom, it appears that there are lots of geeks who sit around formatting disks all day. (Psst, you can buy them pre-formatted.) But why did Windows 95 get all sluggish when you formatted a floppy disk?

It's that pesky MS-DOS compatibility again.

As we saw a while ago, MS-DOS acted as the 16-bit legacy device driver layer for Windows 95. Even though the operation was handled by the 32-bit file system, all I/O calls were routed through 16-bit code (if only briefly) so that 16-bit drivers, TSR, and the like would see what appeared to be "normal 16-bit behavior" and continue operating in the manner to which they had become accustomed.

In the old 16-bit days, disk formatting was done via software interrupt 13h, and many programs took advantage of this by hooking the interrupt so they would know whenever a floppy disk was being formatted. Some TSRs did this, as did backup programs (including backup programs designed for Windows 3.0 which included 32-bit Windows 3.x drivers—VxDs they were called—to monitor the floppy drive). But that doesn't explain everything. After all, Windows 95 sent all disk I/O through the 16-bit vectors, not just floppy disk formatting. Why does floppy disk formatting take such a toll on the system?

As I noted in the linked article, the 32-bit file system did a lot of fakery to make 16-bit code believe that MS-DOS was in charge, even though it wasn't. Anybody who's done TSR programming (wow, the phrase anybody who's done TSR programming used to cover a lot of people but nowadays describes a few dozen geezers, most of whom are trying very hard to forget those days) knows all about the INDOS flag. This was a flag that MS-DOS set when an MS-DOS I/O call was active. Since MS-DOS was not re-entrant, TSRs had to pay close attention to that flag to know whether it was safe to issue MS-DOS calls or not. This INDOS flag was the 16-bit manifestation of what the 32-bit kernel called simply The Critical Section, with the definite article, because the 32-bit kernel kept the two critical sections (the 32-bit one and the 16-bit one) in sync so that MS-DOS drivers and TSRs wouldn't themselves get re-entered. If one virtual machine claimed the critical section, another virtual machine that tried to claim it would wait until the first one released it. In that manner, the driver or TSR would not get re-entered.

As I already noted, back in the 16-bit days, the actual work of formatting was done by the ROM BIOS, and for compatibility reasons, floppy disk formatting was still sent through software interrupt 13h on the 16-bit side so any TSRs or drivers could see what was going on. There are a lot of crazy ROM BIOSes out there, and when a floppy disk format request was issued, the 32-bit kernel would do a bunch of extra work to ensure that the ROM BIOS got the execution environment it wanted. For example, the hardware timer ports were temporarily unvirtualized so as not to mess up the sensitive timing loops that ROM BIOSes used for floppy disk formatting.

Okay, let's add up the damage. When a floppy disk is formatting, the timer is unvirtualized so that the ROM BIOS timing loops will run accurately. Only the virtual machine that is formatting the floppy drive receives timer ticks; the others have to wait. No timer ticks means the scheduler doesn't get told when it's time to let another thread run. What's more, the critical section is held across this operation, which means that no other thread can issue I/O operations either. And on top of that, the floppy disk is a slow medium, so any operations that wait on the floppy disk will have to sit and wait for several seconds.

Well, at least floppy disks are formatted a track at a time, so the system doesn't get locked out for the entire duration of the format operation. The ROM BIOS would be told to format a track, and when it was done, the timers would be returned to normal (allowing the scheduler to do a little bit of scheduling), the critical section would be released (so that any pent-up I/O gets a chance to run), but then the FORMAT.COM program would turn around and format the next track, and the system would go back into hang on, let's not disturb the ROM BIOS while it does its thing mode for another track.

Now, as with the 32-bit file system, there was a 32-bit floppy driver that tried to catch the format operations on the back end, and if successful, it would take over the job of formatting one track from the ROM BIOS. It was a valiant effort, but it doesn't matter how high-performance your driver is; the speed of formatting a track is pretty much constrained by the mechanics of the floppy disk drive itself. (The person responsible for Windows 95's 32-bit floppy driver was no slouch. I'll try to remember to tell some more stories later.)

Sure, if Windows 95 didn't have to be compatible with 16-bit device drivers, TSRs, and squirly ROM BIOSes, it could have gone straight to the 32-bit floppy driver to do the formatting without having to do all this timer and critical section nonsense. But it turns out we already had a product that said good-bye to compatibility with 16-bit device drivers, TSRs, 16-bit Windows programs that talked to custom 32-bit Windows 3.x drivers, and squirly ROM BIOSes. It was called Windows NT.

If you want Windows NT you know where to find it.

Comments (49)
  1. Mark says:

    Is that a preemptive Slashdot disclaimer?  What if nobody submits your article to Slashdot?

    <i>If you want Windows NT you know where to find it.</i>

    Am I the only one who immediately thought of BitTorrent?

  2. Alexander Grigoriev says:

    Obligatory old joke:

    "Dad, show me the great multitasking Windows 95"

    "Wait, boy, until it’s done with the floppy".

  3. NB says:

    So how does Windows NT perform when formatting floppies? I have actually never had to do this myself.

  4. jim says:

    I remember when I first saw NT formatting a floppy that was one of the first things that gave me the "oh – this is really a different thing" feeling as compared to Windows 95. It was totally smooth and didn’t disrupt any other activity on the system in any noticeable way.

  5. manicmarc says:

    If I remember rightly, Windows 95 & 98 used to slow down considerably when using the floppy drive, whether it be in copying a file in Explorer or saving something in Word. I used to avoid opening files directly from a floppy for this reason.

    If you accidently took a disk out mid-way you’d get a blue screen, something I remember changing in Windows ME (instead, you got an actual window telling you what a silly thing you’d just done).

    The came XP and it was great, I can use a floppy AND play Flight Simulator!

    [Note that the blue screen was not a blue screen crash. It was a kernel message (which is always blue) saying, “Hey, put that floppy back in, I was using it!” You could cancel it and an error would be returned to the application. Windows 95 didn’t have a good way for kernel components to interact with the user; blue screen dialogs were all they had. -Raymond]
  6. steveshe says:

    What! Is Yuhong Bao on vacation? There is certainly fertile ground for his ancient remeberances of Windows 95,98,NT in this post. Such a shame that he will miss an on opportunity to actually comment on-topic :(

  7. ola ! says:

    @steveshe

    There is a rumor that MSR was getting closer to perfecting the death ray…

  8. 640k says:

    This doesn’t explain why Vista can’t multitask smoothly while formatting floppies/harddisks.

  9. Joel says:

    "This doesn’t explain why Vista can’t multitask smoothly while formatting floppies/harddisks."

    No OS can really do it smoothly if the disk is slow and lots of processes are contending to access the disk.  If I have process A that is formatting a disk (and thus generating a lot of I/O on that disk) and processes B, C and D which are making some use of the disk, whether for demand paging or other purposes, it is necessarily true that B, C and D will be more likely to have to wait for I/O to complete on the disk because of the large number of I/O requests coming from A (and also B, C and D, but to a lesser extent).  The scheduler has to make these processes wait and they will have to wait longer because of the I/O load, thus causing them to "slow down" or not display smooth performance because of little hiccups while trying to access the disk.

    Furthermore, a formatting program is likely to trash the page cache, resulting in an increased chance of other programs actually having to go to disk instead of reading from the cache.

    The only solution is to have I/O priorities and such, but even then, the disk is only so fast and invariably, the I/O caused by the formatter is going to result in some extra delay, especially if it results in extra seek time for the heads.

  10. Andrew says:

    Hehe, now I’m an old geezer. Thanks Raymond.

  11. Nicolas says:

    The irony is that back to 1998, i couldn’t figure out why, on the same hardware, my linux system was far more responsive while able to write faster on floppy disks. Now i know, but it made me boot more often my redhat that i would if it did not made me save several minutes to copy stuff on floppies. And then it made me familiar to linux, beginning the road to the switch.

  12. Anonymous Coward says:

    The last time I formatted a floppy disk I was still using a 286 with Norton Commander. Wow, that takes me back. Back then floppies were sold unformatted so I had to, but by the time I was using Windows 3.1 stores sold floppies pre-formatted and I never formatted a floppy again.

  13. Roastbeef says:

    Heh… I remember back in my OS/2 days that we’d make sure in a Win95 vs OS/2 demo to do a floppy format because OS/2 would handle it without a burp.

    (And some of us actually still do DOS TSR programming.  Where I work we do system testing of our chips first under DOS before moving on to more complicated environments, and so I still write/update the occasional DOS TSR.)

    -Another geezer

  14. mvadu says:

    By naming TSR you reminded me of my school days when I was trying to master Turbo C. I was doing Mouse Programming on MSDOS box (i think i booted to MSDOS on a Win98 machine, so its 32 bit, but the PC was an I-486) using far pointers and int-33h. It was fun!!

    I had a plastic sheet with a 8×8 grid where I will write down a cursor map and masking map (using 1 and 0, the whole shape should look like a mouse pointer) and covert it to byte array. When I switched to VB 6.0 one of the feature to amaze me was how easy to set a mouse cursor in Windows.

  15. John says:

    Who sits around formatting disks?  Everybody should.  Haven’t you heard about all these USB drives coming pre-installed with malware?  I don’t think it’s very likely to happen with floppy drives, but you can’t be too careful.

  16. Yuhong Bao says:

    [Note that the blue screen was not a blue screen crash. It was a kernel message (which is always blue) saying, “Hey, put that floppy back in, I was using it!” You could cancel it and an error would be returned to the application. Windows 95 didn’t have a good way for kernel components to interact with the user; blue screen dialogs were all they had. -Raymond]

    Yep, see SHELL_Message and SHELL_SYSMODAL_Message.

    [Thank you for showing off. -Raymond]
  17. Jonathan says:
    1. That makes me a 32-years-old old geezer?

    2. I remember the Win95 "blue screen of slight illness". I was surprised to get one during a CDR burn, and still have Win95 complete the burn successfully.

    3. I’m not sure it’s related, but why does modern Windows (XP, at least) halt when you insert a CD, or, god forbid, a slightly-scrached one? I imagine it’s only a shell-level hang, but still.

    4. Joel: I doubt many people format disks while reading them. Unless they’re formatting partition B while reading partition A on the same disk.

  18. Joel says:

    @Jonathan: yes, good point.  I guess I usually do formatting on the same disk as I’m also using by way of multiple partitions, so I subconsciously assumed that was always the case.  Oops!

  19. Lobo says:

    Formatting a floppy on Windows 95 was still paradise if you compare it to what it was to format a floppy on MacOS 7 or 8. THAT was painful. Formatting a floppy in a Mac back prevented you to use the finder *at all* under the man time.

  20. Ben Cooke says:

    It’s nice that this, unlike many of Raymond’s stories, has a happy ending: "it used to suck, but guess what: we fixed it!"

  21. James says:

    @Ben: an especially happy ending, since the "fix" predates the "suck."

  22. Aaargh! says:

    "Unless they’re formatting partition B while reading partition A on the same disk."

    You can’t format partitions, you can at most create new filesystems on them. Formatting is a low-level disk operation which erases everything on the disk. Nowadays, most harddisks don’t need to be formatted, and usually it voids the warranty if you do.

  23. Duane Barry says:

    Aaaargh:

    The last time I used the "format" command in Windows, it operated on logical partitions, AND gave me a choice of filesystems to use.

    So in the context of Windows (which, if you recall, is what this blog is about), you are wrong!!

  24. NB says:

    So what is Explorer really doing while formatting a partition then? :)

  25. Jerk says:

    http://en.wikipedia.org/wiki/Disk_formatting

    99.9% of the time when people talk about "formatting" they mean the high-level type; while you may be technically correct, in the real world "formatting" is synonymous with "creating a file system".  This begs the question: are you also going to whine about misuse of the phrase "begs the question"?

  26. Richard says:

    I must be the .1% of the population that still (on occasion) formats 3.5"

    1.44MB floppies.  What I’ve found is that the Windows NT family (up to an

    including Windows Vista) will often fail to format the floppy if the first

    track seems to be bad.  If I perform a "format /u" with the same media on DOS

    6.22 it will almost always correctly format the media (unless the 1st track

    is truly unformatable).  I keep DOS 6.22 around because the tools that run on

    it do a better job at managing/reading marginal media.  I’ve been unable to

    find any good tools for Windows NT.  As I recall, Windows 9x was no better

    than Windows NT with regard to marginal media.

  27. Ari says:

    I miss my old 5 1/4" floppies.

    No wait. I really don’t.

    Oh the joy of USB sticks that only have to be messed with once in a while and can actually be moved in and out of cold and humidity, as well as suffer slight physical accidents without getting bad sectors.

    And the joy of playing Sierra games from 10 5and1/4" floppies. Oh how I miss those days not one whit.

    Back in those days even a kid like me knew a bit about formatting and of course the quirks of Dos RAM management (Himem, XMM and EMM).

    No hard disk, booted of a floppy and trod through hip deep snow for kilometers to (illegaly) copy games. Now it all just comes down through the tubes.

  28. Mike says:

    I remember the W95 RC’s, with Beziers included (to display multithreading). During that timeframe, Windows 95 kicked some serious butt when it came to floppy operations too.

    It was only with the Release (IIRC) that floppy operations came to almost a halt.

    The comment about NT made me remember how *horribly* slow it (especially NT4 and later, but perhaps <=3.51 was as slow?) was on floppy operations.

  29. Neil says:

    I must be one of those few people who actually thought Windows 9x was faster at formatting than Winodws NT4.

  30. Neil says:

    I must be one of those few people who actually thought Windows 9x was faster at formatting than Windows NT4.

  31. Xepol says:

    Geez, I stopped using floppies a decade ago.  I’m still amazed when I see a pre-built machine with a floppy drive (it happens a lot less lately) – where would you even find the media??

    First I was liberated by Zip drives (which, admittedly, needed a floppy if you used the parallel port version instead of the IDE version), and then CDRs drove in that last nail.

    I can’t remember the last time I actually needed a floppy for anything at all (outside of a PDP-11 that is)

  32. Dean Harding says:

    Neil: It may have been faster overall, but the point is that you couldn’t do anything else while it was happening. On Windows NT, the rest of the system was still usable.

  33. Juan says:

    Anyone who reads this can correct me if I am wrong.

    @Jonathan: The reason why Windows XP (And 2000) hangs when inserting a damaged CD or USB drive has to do with completition ports (http://technet.microsoft.com/en-us/sysinternals/bb963891.aspx) and (http://msdn.microsoft.com/en-us/library/aa365198(VS.85).aspx). If you are a developer you can try to debug a piece of code inside a window. (you will see how the entire shell just "hangs" its painting.

    This is solved in Windows Vista shell (the entire shell). Now it notice when a I/O request hangs or any Shell Window it not responsible and just adds to its title the ‘(not responding)’ string and let you move it, minimize it, restore it and close it, so it is good for debugging a Window or realize that an usb flash drive has corrupted. – Iam just gessing – but I think the isolation of session 0 and the improvement completition ports APIs has something to do with that.

  34. Adam says:

    This reminds me of a trick I used to make Windows much more responsive while formatting a floppy – open up a DOS window and format it from there.

  35. Mike Dimmick says:

    @Juan: nice theory but wrong. The program has still hung but the window manager allows the window to be manipulated. The accelerated Aero interface on Windows Vista is a little better at this; Windows XP was the first to introduce it.

    If the disk is damaged, typically the driver or disk firmware will retry at slower and slower rates to try to recover what data it can. One of the big differences between IDE/SATA and SCSI disks is that SCSI firmware assumes it’s being used in a redundant array and fails fast, while IDE firmware will keep retrying, and in the process stalling all other I/O.

  36. ender says:

    I seem to remember that back in the Win9x days, the system was much more responsive if you formatted floppies through command prompt with format.com than by using Explorer.

  37. Juan says:

    @Mike: Thanks mike for the response. It makes more sense. Though I have been able to move windows even in non accelerated -in a ‘classic window’ theme-, so it could be something implemented at shell level.

  38. A says:

    Am I the only one who immediately thought of BitTorrent?

    Wow.  So your first thought was "I’ll go steal it"?

    Way to go, open source mentality!

  39. Yuhong Bao says:

    "I seem to remember that back in the Win9x days, the system was much more responsive if you formatted floppies through command prompt with format.com than by using Explorer."

    That is probably because formatting a floppy using Explorer ties up the System VM (I am not sure if the Win16Mutex is held during floppy formatting, can Raymond or someone else comment on this), while formatting a floppy using format.com is done in a separate DOS VM.

  40. SuperKoko says:

    "After all, Windows 95 sent all disk I/O through the 16-bit vectors, not just floppy disk formatting."

    Is it true?

    I thought Windows 95 automatically detected whether a TSR was redirecting a disk I/O interruption (INT 21h, INT 13h, etc.) and if none did, it would skip the 16 bits layer.

    Maybe I’m wrong.

  41. SMW says:

    I may be a bit late to the party here, but floppies still have one major need: RAID.

    You cannot (on Windows 2003 Server and Windows XP, anyway), put the OS on a RAID 1 system without a floppy.  It may be true for disks that are part of the system but don’t contain the OS (I have machines with both types of setups, but I don’t remember about the latter).

    The motherboard manufacturers provide the RAID drivers on CD, but the Windows OS installer can only accept them via floppy.  So of course you need an existing machine to transfer the drivers from the CD to a floppy.  I’ve seen this at work when setting up new machines, as we run Windows 2003 Server on dual-disk servers and typically mirror those drives.  Thankfully, the rack-based servers we use come with floppy drives.

  42. Yuhong Bao says:

    "I may be a bit late to the party here, but floppies still have one major need: RAID."

    MS used a new WinPE-based installation engine for Vista, and as a side effect were able to fix this.

  43. Yuhong Bao says:

    "Now, as with the 32-bit file system, there was a 32-bit floppy driver that tried to catch the format operations on the back end, and if successful, it would take over the job of formatting one track from the ROM BIOS."

    Why not have the 32-bit floppy driver revirtualize the timer port upon taking over the job?

    "During that timeframe, Windows 95 kicked some serious butt when it came to floppy operations too.

    It was only with the Release (IIRC) that floppy operations came to almost a halt."

    Is that what Win95 RC did?

  44. "Germanium" Jack says:

    The InDOS flag.  Shudder.  OK – True confessions time.  I am geezerish enough to have once written a TSR to add 3D graphics primitives by hacking in new functions to the early BIOS graphics function entry points for some weird graphics hardware.  The joy of writing your own polygon fill algorithms in carefully tweaked assembly language, and when the assembler’s output didn’t quite make you happy, hacking on the binary.  Feeling my age.  And yes, the fun of talking to the floppy drive through BIOS calls.  I still miss my PDP-11…

  45. Dave says:

    You cannot (on Windows 2003 Server and Windows XP, anyway),

    put the OS on a RAID 1 system without a floppy.

    Alternatively, you can use nLite to add the necessary drivers to the install CD (or at least your customised version of the install CD), which is much easier if you don’t have a floppy drive on the target system (and by "no floppy drive" I don’t just mean the physical artefact but not even a port to plug a floppy drive into).  A convenient side-effect of the nLite route is that you can also remove a ton of bloat that you didn’t want installed in the first place.

  46. Andreas says:

    I may be a bit late to the party here, but floppies still have one major need: RAID.

    Wow, at first I thought you wanted to put floppies in a RAID configuration. Reminds me of this fella who successfully managed to create an NTFS formatted floppy and lived to tell the tale.

    Btw Raymond, I’m not sure that at age 31 I want to refer to myself as an old geezer but I did my share of TSR programming, though just for fun and learnings!

  47. JamesW says:

    @Andreas

    "Wow, at first I thought you wanted to put floppies in a RAID configuration"

    You need OS X for the awesome power of floppy RAID!

    http://ohlssonvox.8k.com/fdd_raid.htm

  48. 640k says:

    No OS can really do it smoothly if the disk is slow and lots of processes are contending to access the disk.

    Yes, almost all non-windows OS can do it smoothly.

    If I have process A that is formatting a disk (and thus generating a lot of I/O on that disk)

    Formatting 1 track / second is NOT a lot of I/O.

    and processes B, C and D which are making some use of the disk…

    The number of apps which access a disk which is in the process of being formatted is probably near nil.

    The scheduler has to make these processes wait and they will have to wait longer because of the I/O load, thus causing them to "slow down" or not display smooth performance because of little hiccups while trying to access the disk.

    Waiting processes should not consume CPU time or else the OS is at fault.

    Furthermore, a formatting program is likely to trash the page cache…

    Caching of empty formatted sectors is stupid, but I’m not surprised windows does it.

    The only solution is to have I/O priorities and such…

    No need, other OSet can do it better without. Keep it simple.

  49. SuperKoko says:

    "Yes, almost all non-windows OS can do it smoothly."

    Using Gentoo Linux, kernel 2.6.27, with CFQ scheduler (Completely Fair Queue), it’s not exactly true. With other schedulers, it would be even worst.

    Computer: Laptop Pentium IV 2.67Ghz, 512MiB RAM, 80GiB PATA UDMA-100 Hitachi HD model IC25N080ATMR04.

    I/O processes:

    1) dd if=/dev/hda7 of=/dev/hda6

    2) emerge gcc (the dependency computation phase, which makes tons of I/O)

    3) mplayer local_file.avi

    The video isn’t smooth. Every 2 or 3 seconds intervals, it stops for 500 or 700ms in order to bufferize data, though it’s smooth between these delays.

    Note that 500ms is MUCH longer than the max access time of my disk.

    Now, going further:

    1) ionice -c3 dd if=/dev/hda7 of=/dev/hda6 # Idle I/O priority.

    2) ionice -c3 emerge gcc

    3) mplayer local_file.avi

    It’s much smoother, but there’re still 150 to 300ms delays, every 2 to 5 seconds intervals.

    Formatting 1 track / second is NOT a lot of I/O.

    Joel was refering to formatting hard drive partitions on Windows Vista, not to Win95+floppies.

    The number of apps which access a disk which is in the process of being formatted is probably near nil.

    You can format one partition while working on another.

    If, as you say, modern OS are great at scheluding I/O, this is a perfectly sensible operation.

    Waiting processes should not consume CPU time or else the OS is at fault.

    It doesn’t consume CPU time, but block applications when they perform I/O, such as media players.

    As Joel said, there’re little "hiccups" while trying to access the disk.

    I admit that, if the media player was specifically designed for this scenario, using asynchronous I/O (not natively supported by Linux, but faked by multithreaded applications) and a huge buffer, asking for data whenever it’s less than 80% full, it might be smooth. I’ve yet to see such a media player.

    Caching of empty formatted sectors is stupid, but I’m not surprised windows does it.

    I don’t know if Windows does it.

    Linux doesn’t, at least when copying from /dev/zero.

    No need, other OSet can do it better without. Keep it simple.

    I showed that, without I/O priorities Linux cannot perform three I/O operations at once.

    Worst, even something similar to Windows’ "formatting":

    dd if=/dev/zero of=/dev/hda6

    +

    mplayer local_file.avi

    Isn’t smooth: 500 to 700 ms delays every 2 to 4 seconds intervals.

    With I/O priorities, that’s better but not perfect.

    dd if=/dev/zero of=/dev/hda6

    +

    mplayer local_file.avi

    -> 100 to 400 ms delays every 2 to 6 seconds.

    Limitations: These tests are limited to one computer, with one OS. FreeBSD might show different performances. A newer computer might perform better.

    Your mileage may vary.

    PS: With xine, it’s much better. Probably because it uses a larger buffer and fills it earlier.

Comments are closed.