>> You are WRONG, Tom!! > > Is he ? or are you being RUDE, Jack?
Tom could have written me privately, before publicly saying UIDE assumes change-line support, but did not. I responded in kind! > Not Tom, but I'd like to learn from /what exact source/ you got the > definition for those bits. My error; the byte accessed by UIDE is 0:48Fh as I noted earlier, when I also noted the "BIOS Central" website as my source. > Now, puhlease! don't feel accused - I'm sure you did not make those bits > up and that they work in your test machines and even for the bulk of > your users. That you wait for users' complaints before checking the > soundness of your assumptions is another question entirely. Unless "BIOS Central" posts incorrect data, my assumptions WERE sound! > You are entitled to choose any method that works on recent gear if you > find it convenient. Thank you, and so I shall keep UIDE/UIDE2 as-is. > But rather than pretending to support floppies on the whole range of > DOS-capable PCs, and claiming that those that do not conform to your > model are junk (or is it the users' fault ?) - you /must/ find a way to > programmatically assert that your far from universal method /will/ work > and take measures otherwise. IMHO you can't leave it to the (clueless, > always...) user to assert his or her PC is not conforming to UIDE's > model. There is NOTHING wrong with "UIDE's model", unless you can positively REFUTE the data provided by "BIOS Central", which is what I used back in 2006 when I added caching to my drivers. They have worked on all "hardware" PCs since then, so I shall NOT assume to be using any "far from universal" method. And, I say again: Hardware change-lines do work, have since 1985, and any which do not are a MAINTENANCE problem for the user, NOT any reason to re-engineer UIDE. ------------------------------------------------------------------------------ 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
