Hi, Very very nice discussion, I am enjoying this a lot, thanks!
Kenneth J. Davis escribió:
various details like that. And really if you wanted to be clever, maintain the needed information about open files and TSRs won't even notice the change, even if the file is now on a different drive (C:->D:).... The point is, in a known boot state this could all work fine, but in a random user's setup, some program out there is going to get confused and cause data loss (some undelete, raw disk accessing, ... utility) and given the effort involved for such tool versus the man power we have, the best idea is just plan for a reboot. This has the
In my opinion, there's no need to worry about external UNDELETE (ours could be adapted) or other raw disk accessing utilities. First of all, theoretically because proper DOS apps should not be using BIOS/Hardware (I know many do), but secondly because after all, none of them were actually working with Microsoft's DBLSPACE/DRVSPACE: if they can do it, we can do too. Just announcements here and there NOT to use partition mounting/unmounting with such tools.
As for the int19h issue, MS DOS actually hooks several (I think this is
Well, vectors 20h-39h are actually assigned to OS/DOS by the PC Architecture standard, right?
So to summarize, yes DOS could reload partition tables and reassign drive letters, to a certain extent some drivers such as CD or network drivers do this, current kernels do not do a complete scan and reassign drive letters though, doing so would require work from developers we don't have and if made into a resident DOS call would waste conventional memory for most people.
Well, we certainly have other priorities now, but not a reason not to add it to the post-1.0 list, for the next (forthcomming!) revision...
Aitor ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
