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