> The FAT file system is defined by DOS, and I want UIDE/UIDE2 to
> have NO run-time "dependencies" on the DOS system.

Nice in theory, but unfortunately doesn't work in practice.

DOS's management of the change line is under the sole auspices of the block 
device driver, not hardware/BIOS (INT 13h).  Since the early 80's, the device 
drivers built into the DOS kernel for disks with removable media (floppies, 
removable hard drives) have not solely depended on the BIOS.

At a minimum, they have also used timing -- if a disk hasn't been accessed for 
a certain amount of time (usually about two seconds), the device driver will 
respond with "I don't know" when DOS asks it if the media has changed or not.  
This forces DOS to re-read the serial numbers and volume labels and whatever, 
basically treating things as though the media has changed (even if it actually 
hasn't).  If you're caching floppies, but ignoring the DOS device driver and 
just looking at the BIOS, you are out of sync with the OS.  If I'm not 
mistaken, this is the exact same reason you refuse to support removable hard 
drives with UIDE (you're afraid the BIOS change line might be invalid).

Also, to be fair in the particular situation that started this thread, this may 
not actually be the VM's fault.  Since the user is attempting to install a 
program from real floppies, it's possible that his floppy drive hardware does 
not correctly support the change line, and the VM/virtual BIOS is simply 
"passing through" what the floppy hardware/real BIOS/host OS is telling it.  It 
could in fact be the VM's fault, but it may not be.

> "NO re-entrant calls!", I say again!   Having UIDE/UIDE2 issue
> an Int 13h of their own WOULD require re-entrancy!

This has been discussed before, also.  With few exceptions, TSR's and device 
drivers should ALWAYS be re-entrant.  How can you guarantee, e.g., that a 
software interrupt (such as INT 13h) will never be called from inside a 
hardware (IRQ) interrupt handler (like INT 08h)?  Granted, an INT 13h call to 
actually read or write to a disk would not (normally) happen from inside an INT 
08, but there's no legitimate reason it can't check the state of the cache or 
other similar "housekeeping" functions.  You can/should not prevent IRQ 
handlers from calling functions/services provided by you TSR/device driver.  
And if an IRQ handler can do it, there's a possibility of re-entrancy. 

Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Freedos-user mailing list

Reply via email to