[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: Re: reload partition table and reassign drive letters
Hi, yes, FreeCOM can handle changing drive letters. The PROBLEM is that harddisk letters are handled by a kernel driver which can only do one hole-free range of drive letters. So if you could enable a new partition on the fly, all subsequent drive letters would move. HOWEVER, you are free to write a RAMDISK style driver which MOUNTS an arbitrary FAT partition: You only have to provide sector read/write and calculate the right (read: offset by partition start position) sector numbers, and the kernel will do the rest. Such a driver can even be loaded from the prompt with devload... 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: Re: reload partition table and reassign drive letters
Eric Auer schreef: Hi, yes, FreeCOM can handle changing drive letters. The PROBLEM is that harddisk letters are handled by a kernel driver which can only do one hole-free range of drive letters. So if you could enable a new partition on the fly, all subsequent drive letters would move. HOWEVER, you are free to write a RAMDISK style driver which MOUNTS an arbitrary FAT partition: You only have to provide sector read/write and calculate the right (read: offset by partition start position) sector numbers, and the kernel will do the rest. Such a driver can even be loaded from the prompt with devload... except it cannot re-assign already used driveletters I guess. Same as Jason Hood's disk mounting tools cannot use B:, the kernel already claims it as alternative for A:. There's no if B: refers to same drive as A:, then allow another disk mounting tool to install itself as B: (hm, nice idea. No idea if possible). Kernel can access the partition table, thus also count/determine how many FAT partitions are present. 1st FAT partition will be C:. So a certain range must be free [4 partitions: C..F ]. If C..F are still available, dismount + remount. I like this remount idea, it proves how much we consider the existing limits of DOS, even while writing replacement components that optionally may behave smarter/better as long as it doesn't hurt compatibility. Quarterdeck's quickboot was such an idea, and Eric implemented something like it in FDAPM (is there a single known case of hotboot works though?). Quickboot ment skip BIOS part of boot process upon warm reboot. DOS disk partitioning tools only insist on rebooting because the kernel only recognizes harddisk partitions upon initialisation of the kernel, not at runtime. If the FreeDOS kernel would allow rescanning somehow, FreeDOS Fdisk could be made to not reboot if user decides so. I realize the investment/profit ratio is very bad, which would mean this option would not be implemented any time soon, and would probably be a patch contributed by an 'external' developer instead of regular people working on the kernel. @echo off echo FAT partition on harddisk required, as drive C: if exist c:\nul goto skipfdsk fdisk rem let the used DOS kernel re-initialise driveletters assigned to disk partitions. Don't touch A,B, and driveletters installed by drivers. Fdisk /rescanharddisks if not exist c:\nul fdisk /reboot goto skipfdsk :skipfdsk a driver for mount/initialisation also sounds nice. Eric Bernd --- 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: Re: reload partition table and reassign drive letters
Hi! 20-Окт-2005 00:42 [EMAIL PROTECTED] (Bernd Blaauw) wrote to freedos-kernel@lists.sourceforge.net: style driver which MOUNTS an arbitrary FAT partition: You only BB except it cannot re-assign already used driveletters I guess. Same as There exists utilities, which swaps drive letters (for example, SSWAP.EXE from Stacker). So, this is possible to handle drive mappings with help of external utilities on the fly. Though, I suggest, this may be dangerous, if some other utility (like disk cache) links itself to drive letters. BB If C..F are still available, dismount + remount. --- 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
