Re: [Freedos-kernel] Re: reload partition table and reassign drive letters
The main issue with FreeCom would be the location of its resources changing. As long as the comspec env variable still pointed to the same (or an identical) copy of the strings, it would probably be ok, but honestly I don't know if FreeCom closes/opens or keeps open the file with its resources. There may or may not be other issues. Jeremy --- 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
Re: [Freedos-kernel] Re: reload partition table and reassign drive letters
Hello Kenneth, The main issue with FreeCom would be the location of its resources changing. under normal circumstances, FreeCom-xmsswap will have it's resources loaded at startup and touch them never again. Tom --- 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
Re: [Freedos-kernel] re: reload partition table and reassign drive letters
firstly, I never said FreeCom couldn't handle drive letter changes, I said if one did something, then they need to make sure it can; in particular the way it loads strings; although from my experience not being able to load its strings usually just results in FreeCom issuing useless messages (eg try to do dir get a bunch string #XX instead). I stand by my take the code from the kernel and make it an external program if you really want it. Its not overly difficult, just make sure all files are closed first, change the internal structures (hence the kernel version check), and as far as the kernel is concerned nothing happened, but now you may have different drive letters. Of course you would want to be sure to handle the case of LASTDRIVE too small and 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 advantage of almost always working, requires no kernel specific knowledge (so same boot disk can easy be changed to use FD/MS/PC/DR/EDR/ROM/??? DOS) and is not too difficult; for floppies simply require it to be writable and store the current state (this is what was done at my old job for repartiting/restoring/upgrading the PCs [of course they were all IBM machines so it was easy to detect the proper machine for driver/BIOS issues]) and for CDs there are methods. As for the int19h issue, MS DOS actually hooks several (I think this is one) and assuming it eventually gets called by whoever hooks it after, does several things to aid in rebooting; restoring a couple of the int vectors and if himem was loaded it clears the vdisk entry so it will reload on next boot (unlike with FD where you get the driver already loaded error). 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. Jeremy --- 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
Re: [Freedos-kernel] re: reload partition table and reassign drive letters
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
