> 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
Freedos-user mailing list