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.
Sure seems to, since before this thread, UIDE/UIDE2 have trapped only
BIOS Int 13h I-O requests, and no one has ever complained that it needs
to do anything more!
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.
Fine for them. But UIDE/UIDE2 are NOT block-device drivers, and never
will be, since they need NOT be!
... 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.
Then why, in fact, has no one ever complained about UIDE/UIDE2 diskette
problems before VirtualBox??
I also dispute being out of sync with the OS. On a PC system with NO
flaky diskette media-change lines, as I expect they all have been from
1985 on, SO WHAT if the DOS system does a timeout check?? It will find
no change in the diskette UNLESS the user actually DID insert a new one,
in which case the media-change line will also tell UIDE/UIDE2 that a new
diskette is present! So, where in all that did we get out of sync??
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).
You are BADLY MISTAKEN as anyone who read BTTR back in 2010 can tell you!!
I refuse to support removable HARD disks as I can't be sure ALL variants
of DOS have the logic to handle a media-change for a supposed HARD disk!
Until I am POSITIVE of this, I will NOT have UIDE/UIDE2 taking the blame
for any removable hard-disk NOT causing the DOS system to flush its disk
buffers if a disk gets changed!!
Also, to be fair in the particular situation that started this thread,
this may not actually be the VM's fault ... It could in fact be the VM's
fault, but it may not be.
Since all diskettes from 1985 onward have had change lines, my strong
suspicion is that VirtualBox simply is NOT posting a media-change bit
in the BIOS data table, like any real BIOS would do. That is one more
omission, or BAD BUG! if you will, in their emulation scheme!!
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)?
UIDE/UIDE2 trap only Int 13h calls, actually only I-O calls. Other
Int 13h requests (if any!) are passed directly to the BIOS and don't
execute on the UIDE/UIDE2 stack. My drivers will execute diskette or
non-UltraDMA (or /E disk) I-O requests by calling the BIOS, but that
needs no re-entrancy, as in such cases the BIOS becomes an extension
of UIDE/UIDE2.
So, since UIDE/UIDE2 do one at a time I-O requests only (including a
call the BIOS I-O request), and as they have NO need to handle other
Int 13h run-time calls, then Why-in-HELL do I need to have re-entrancy
in my drivers?? Bloody waste of time!!
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 your TSR/device driver.
And if an IRQ handler can do it, there's a possibility of re-entrancy.
And if the user does such a call from an ISR, while my drivers are in
fact still processing a PREVIOUS I-O request, where do I save the ISR
call's variables, where do I get enough stack space to handle TWO (or
maybe more) such re-entrant calls, etc.??
Also, what check cache status or housekeeping functions have you
found to use in UIDE/UIDE2?? As I follow the K.I.S.S. Principle,
TAKE A GOOD GUESS how many such functions there are, in UIDE/UIDE2!!
What you suggest as legitimate is really DANGEROUS and IS NOT what
most DOS device-drivers have EVER supported, including mine, given a
long-standing DOS convention known as one at a time I-O!!
--
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
