>>>>Just as a side note...I just ran an old QB program that uses various ROM BIOS interrupts to determine what's on the system (DOS version, hard drives, mouse, numeric co-processor, etc.). With the exception of it not recognizing the floppy type (it's one of those newer high capacity types) and it not being able to properly calculate the free and total disk space, it seems to work fine.
>>>
>>>NT virtualizes the environment for DOS systems, so if you use standard calls within a DOS session, you should be able to get most functionality. If you don't go through the standard interfaces and try to get at the raw hardware, that's where you'll be beaten to a loddy pulp...
>>
>>What about Win9x? That's what I was doing this under.
>
>Win9x to some extent virtualizes BIOS code access; in fact, what it does is drop the system briefly out of protected mode, at a tremendous cost in terms of system performance (if you remain in real mode for any amount of time, you risk losing interrupts that are only serviced by protected mode ISRs, and it costs a lot of cycles to switch in and out of real mode. This is exactly the performance hit you see when a non-compliant disk forces Win9x to operate in MS-DOS compatibility mode; in addition to mode switch overhead, only one task can have BIOS I/O services invoked at one time, since the AT BIOS doesn't serialize access itself, and uses a number of static memory references which just about guarentee that the code will smash itself up if it's being accessed by two independent tasks at once...

Thanks, Ed. All of this explains the tremendous performance hit I've experienced recently while running a DOS based program.