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
