Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox U IDE2 init problem

[Bret J. <bre...@ju...>]

Jack:

> 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.