RYAN Alan Porter (unrelated AFAIK) asks:

2) How the hell to intercept the read/write routines?

I can help with the guts of DOS, BIOS, network interfaces, etc. My development time is committed, but feel free to email me with questions, folks. The simplest approach is probably Microsoft's Network Redirector interface. It's used for MSCDEX, and just about every LAN OS except Novell's, including Microsoft's own LAN Manager. A good reference is "Undocumented DOS" by Andrew Schulman et al. This is the only option discussed here I haven't used personally. It looks ideal for this application. Another possibility is hooking the DOS API itself. This certainly works well; it's the way Netware does it. I've found it a lot of work. See IBM's "Disk Operating System" manual for details. There was a mainframe manual by the same name, so be sure you're getting the PC version. Just under DOS itself is what Microsoft officially refers to as Device Drivers. Device drivers actually can be hooked in at many levels, of course, not just here. In this context MS calls disk drives "block devices". Block device drivers, or character device drivers for that matter, are not at all tough to write. They're probably a good second choice after the Network Redirector. A reference is the book "Writing MSDOS Device Drivers" by Robert Lai. DOS internally often calls software interrupts 25 and 26 for disk io. These are apparently inconsistent from DOS version to version. Skip this layer. If you need to go this far down, go all the way to INT 13. The lowest level of disk io short of hardware is INT 13. A good reference is Phoenix's "CBIOS Reference Manual". Watch out for quirks in INT 13's stack handling. There's also a good bit you have to do to keep DOS and your driver from tripping over each other. Unless others feel it's appropriate to use this bandwidth, email me for details. Doug