Re: CryptoStacker, long

[Doug Porter <76244.315@CompuServe.COM>]

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