> http://www.bttr-software.de/products/drvexch/ I guess, written by you > or one of the other BTTR regulars? :) > > I think it has a safeguard against C: though due to often-valid > assumption that people actually boot from C: > > Perhaps Robert Riebisch knows more about the program as he hosts it. > Couldn't find a specific author.
Yes and no. It's from us, yeah. You're also right in that the specific author apparently isn't obviously stated in the documentation. In any case, open up the source code and the copyright statement shows it's from Michal. But then again, I could have told you it's not from me, because the latest version is from long before I ever heard of the project ;-) I can't find anything about such an alleged safeguard. Skimming the documentation and source code did not reveal it either. However, I'm not particularly familiar with the source code and don't regularly use DRVEXCH. In any case, DRVEXCH provides the basic operation of swapping DPBs and CDS entries, but it doesn't affect Int13 unit numbers in any way. (It is also controlled entirely by user instructions, instead of automatic detection/guessing.) There's an interesting point to be made here: DRVEXCH can't affect non-block-device (that is, redirector) CDS entries. This is the case because at least some redirectors do not use data inside the CDS entries to detect their drives; instead, they save the DOS drive number of their drives in their internal data and compare that against the drive number accessed by DOS. So while exchanging redirector CDS entries using (a modified) DRVEXCH would make DOS detect which drives are to be redirected correctly, the redirector could fail to properly detect the exchanged drives. At least SHSUCDX works in this way, and it is reasonable to expect that other redirectors do as well. I don't know whether any redirector (the original Microsoft network clients or MSCDEX?) implement drive dispatching in such a way that they do not store any DOS drive numbers in their internal data, which would be necessary to make them work with (a modified) DRVEXCH flawlessly. It might indeed even be impossible to implement redirectors in that way. DRVEXCH works well with DOS-provided CDS entries referencing DOS-provided DPBs, but it might make other block device drivers behave funny, such as Bret's USBDRIVE. If USBDRIVE internally stores DOS drive numbers (which I think it did when I reviewed it last), then basically the same problem as for the redirectors applies. In this case, it would be less critical though, because simply accessing the drives should still work (because the same block device driver and block device unit are used by DOS's file system driver). However, whenever USBDRIVE tries to access its CDS entries or DPBs, it might work with the wrong ones, and therefore, for example, fail to remove its CDS entries from the system. For both redirectors and other software keeping track of DOS drive numbers internally, the workaround is to never change these DOS drive numbers with DRVEXCH. Instead, use DRVEXCH to move away the regular DOS drives, then instruct that particular redirector/other software to install or move its drives to the freed drives. Regards, Christian ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
