>> UIDE has NEVER ignored if a diskette has change-line support! It >> does in fact check the BIOS data table at 0:48Fh for bit 0 (change >> line for diskette A:) or bit 4 (change line for diskette B:). If >> those bits are off, diskette A: or diskette B: will not be cached. > > That is an interesting bug in VirtualBox then (wrong 40:xx data) > but I support Tom here because int 13 is the "front entrance" to > knowing if change lines are supported. Whether and how this uses > the "back office" 40:xx data and whether this data reflects the > "official" statement returned by int 13 is not always reliable, > so asking int 13 is probably better ...
Who says there is a "front office" and "back office" way of dealing with diskette media-changes?? Both seem valid to me! And if the two methods do NOT return the same info, we should CORRECT whatever program (VirtualBox, in this case) which has CAUSED such a problem, rather than requiring all previously-GOOD software to get changed! > Also, it would be very easy for UIDE to ask int 13 instead of or > in addition to 40:48 bits. Would take more logic, and is NOT needed on any "hardware" PC. As I am NOT "working for VirtualBox" (or I damned-well HOPE not!), let THEM make changes to address the problems they have created! >> But, if what you wrote above is correct, VirtualBox expects people to >> use ONLY the "Int 13h" requests, when determining if a diskette has >> change-line support. And in any event, by indicating NO such support >> ... they make it impossible for UIDE to cache diskettes ... > > Indeed. But it is better to not cache than to damage data. Another statement on which you can bet your [rear-end]! > Given the new information from Tom, I agree that it is > not worth the effort to add heuristic cache flushing, > as it turned out that it IS possible to detect that no > change line exists in VirtualBox. So VirtualBox users > will not enjoy UIDE caching, but please do use int 13 > (instead of or even better in addition to 40:48) for > the detection of systems without change lines... That > will protect VirtualBox users from data loss dangers! So will UIDE/UIDE2 /E, and so I shall leave my drivers as-is. >> To which I shall add: Maybe you might have read the UIDE.ASM file >> before making any BASELESS and WRONG accusations about my drivers! > > The sources are circa 4000 lines long and do not even > mention "change line". Now that you explain how UIDE > works, I was able to find this snippet: > >> mov al,FMCMask ;Use diskette media-change bits >> and al,es:[MCHDWFL] ; for our number of diskettes. >> I_FScn: test al,001h ;Can next unit signal media-changes? >> jz s I_FMor ;No? CANNOT use this old "clunker"! > > where MCHDWFL equ 0048Fh. You claimed that you would > check 40:48, not 40:8f, but I could not find anything > in UIDE which checks 40:48 and RBIL does not give any > meaning for 40:48 either. Looking at RBIL for 40:8f, > I see that you can check whether drives support 80 > tracks and/or multiple baud rates, but not on XT and > nothing is said about change lines being flagged by > this byte according to RBIL. See my earlier post this morning re: the "BIOS Central" list of what is present in the BIOS data table at 0:48Fh. I am not surprised if change-line data is not specified for an XT as they were not available till 1985, back in the "AT" days! ------------------------------------------------------------------------------ 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 Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
