I was working at Compaq in 1998 or so, and they had this thing called "SmartStart", which was a CD-ROM with drivers for Windows, SCO OpenServer, SCO Unixware, Netware, etc. Especially important were the storage drivers, because they had to be injected into the OS install to allow the OS to be installed on Compaq's newest RAID controllers, which the OS didn't have drivers for. There was a build process for all the SCO OpenServer and SCO Unixware drivers that was done once a week, through a checklist of manual steps. This was a process that took a few hours. Among the steps for this process was creating floppy disc images, and Openserver didn't have a loopback device, so we just left a floppy in the drive to write out images to physical media and read them back in via dd. Some step in the process seemed to want an actual floppy device. This was problematic because the floppy discs would fail from time to time and they were terribly slow.

I was kind of wanting to move from the SmartStart team to the storage driver team, but I didn't really know too much about drivers, so I started digging into how to write drivers for SCO OpenServer, and made a little driver where you could write 256 bytes into it, it would store this in memory, and then you could read them back out. Suddenly, an idea occurred to me... what if instead of 256 bytes, I made the buffer 1.44M bytes, the size of a floppy? I'd have a RAM disk that I could use in the build process instead of physical floppies. (The native RAM disk wouldn't work for reasons I now forget). So I tried it. It failed, on some ioctl call. I coded up some dummy code for this ioctl in my driver, and... it worked. And it was way faster than the actual floppy drive (obviously). So I ended up completely automating the build process, eliminating the error prone and slow floppy drive, and having now written a driver, I ended up getting off the SmartStart team and onto the storage driver team, which was way better.