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

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"

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

Reply via email to