MGL originally placed here my older routines to read/write directly to controller and afterwards I added a fat12/16/32 emulator. However, I decided to throw it all away and better to discuss why I throw it away. Because it simply can't work...
Let's start with a little question: Do you use direct disk access in your piece of work? (or would you like to?) Don't do that! There are many reasons why - but you have to think a bit and you'll sure find some of them.

A time ago virii beats each other in tricks how to pass blocking systems, to write on such a disks, or not to be caught by resident scanners. Today this idea also looks good - to access disks without having operatings system know about it, you'll not be found by any resident avir of course (under Windows as well). Its like entry-point tunneling routines. They usualy works - but only under laboratory contitions. And you have to be prepared for real life. If vx can't surrive in real, it is unusable - no matter if it replicates on your machine once it doesn't work on others.

The reason is simple - Microsoft designed all its residental drivers and windows modules in a same way - placing all one over another, without exactly defined interface, so anyone can do what he wants as long as he is consisted with upper and lower level. Yeah, it works well, but you have to: take care about order of loading of such a modules, know what is each module for and what data it has cached. And this is why it can't work under DOS nor Windows.
In dos, for example, nearly every filesystem-based utility had to be resident on interrupt 21 creating some sort of chain of drivers, one depending on another. There is also posibility to register some of your dispatchers directly into dos, but you had to know internal dos stuff to do so - and it is of course slightly limited (but is a bit a thing I mean). Well, so there are many drivers hooked over int 21, cache, novell netware disk, resident antivirus (thats why we talk about it too). You can write some cute program that can work on disc without all this I mentioned (no matter if you are just bypassing some drivers, or directly emulation filesystem) - on more complicated systems like I mentioned before you will cause a disk-crash. At first, you can't access disks created by such drivers. Then, driver might have something in their buffers, and you have no possibility to tell them to flush them. In this case, for example writing to disk a data area that is also cached by some cache program, and in couple seconds later, cache flushes its buffer to disc discarding your change. And if it happens in FAT - you can easily imagine what can happen. Of course, there is possibility to comunicate with such a programs, but as there is no common interface, you can't communicate with all-in-the-world drivers. And your virus can be easily noticed by a disk inconsistency or even disk crash this way.
Conclusion? Well, you can do some direct things under dos, but remember always to keep everything consistent - not only with programs you have on you computer, but with programs other users may have.

Under Windows 9x is this situation a bit simmilar. At first, to avoid direct hardware manipulating and to keep system more consistent there is a hardware virtualization. But you surely know how to fool it - it is quite easy as you can enter Ring 0. As more things are integrated into windows now (networking, variouse disks are attached using hardware device manager, cache is build-in, etc) these things becomes more unimportant every day. And finally, third-party programmers now produces plug-ins for this OS (Windows) instead of extensions (like for DOS). However, I heard some ideas to access disk directy but the reasons why it will not work are same as above. Also a disk access dispatcher entrypoint can be rehooked as well under Windows but if you want to bypass software that is resident in this way, keep in mind you have to do it consistently as well...

And... Good luck and don't be caught by lusers due to problem in your piece of work you didn't figure about...

flush