[Freedos-kernel] Re: reload partition table and reassign drive letters
Hi Jeremy, Date: Tue, 18 Oct 2005 08:24:41 -0400 From: Kenneth J. Davis [EMAIL PROTECTED] To: freedos-kernel@lists.sourceforge.net Subject: Re: [Freedos-kernel] reload partition table and reassign drive letters Reply-To: freedos-kernel@lists.sourceforge.net I've considered this in the past, but the consensus seems to be that it is best just to reboot. It is possible to assuming no TSRs are loaded that would be confused by such action, but if done in the kernel it would involve leaving normally init time (hence transient so does not normally occupy the precious low memory) code in. If you really really really need to do this, then for a controlled setup only (no TSRs or ones you know, and I do mean know, will not be confused by such action -- note FreeCom may be confused by such action) If FreeCom can handle drive letters coming and going due to network drives being connected/disconnected, how would fixed disks coming and going make a difference? I would have thought that FreeCom wouldn't pay much attention to what type of drive it was looking at. Clueless and hoping to learn something interesting :) David --- 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
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
[Freedos-kernel] re: reload partition table and reassign drive letters
Hi Bernd, I did not invent quickboot, fdapm hotboot just calls int 19 (load boot sector and run it). To make that work in real life, you would have to have all interrupt vectors DOS free at the moment, or at least some int 19 handler would have to be hooked by everything which hooks boot-relavant interrupt vectors. Most DOS components do not do that, maybe Quarterdeck quickboot has a sys driver which backups / restores values from early during boot to make int 19 work. Second point, reassign drive letters: You CAN steal drive letters from existing drivers, then fiddle with the drive table and so on, but I very much doubt that that would be useful. In the case of mounting a freshly made partition, it would be easier to ADD a drive letter in unused drive letter space with the described ramdisk style driver instead of modifying existing drive letters. Do not make things more complicated than they need to be. Eric --- 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
[Freedos-kernel] re: reload partition table and reassign drive letters
Hi, Jeremy is right, FreeDOS boots in seconds, so it is best to just reboot. Dynamic drive letter assignment is not what DOS programs are used to cope with. HOWEVER, useful aspects of re-read partitions would be: - you can scan a PCMCIA disk after initializing the disk controller - you can rescan a normal harddisk after loading an improved version of our UDMA2 driver, to gain access to the full disk even if the BIOS can only access the first 32, 64 or 128 Gigabytes. - possibly other things :-). About you first partition, then reboot, then restore a diskimage, then reboot, then edit the config, then reboot to Windows in your WinXP net installer system: You could avoid one or two steps by using a tool which can copy the image to raw space / which reads the partition table itself. I think this is quite normal for disk image tools: You do not copy the image to a drive letter, you copy it to a partition. So DOS'es drive letter system is not involved. A second reboot might be saved by using a DOS version of the mtools (known from Linux) to copy files to unmounted filesystems, e.g. to the restored partition before it even has a drive letter. By the way, WinXP should better use NTFS instead of FAT anyway. There are tools like ntfs4dos to copy files to NTFS. Eric --- 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
