El vie, 17-04-2009 a las 20:01 -0400, John Stanley escribió: > Ok, that sounds good... I feel better about it then. I didn't mean > directly modifying bios data, but through doc'd bios ints of course. It > been a long, long time since I've looked at (or dealt with) bios code, > so I was was simply wondering if boot device naming could be modified > in a documented way nowadays-- after all, the functionality has been > available in the bios setup in pcs for at least 10 years or so.
Indeed. However, this is not necessary as most modern OSes only use the BIOS routines for the initial startup, switching sooner than later to their own device drivers. The problem with some of them, among them MS Windows, is that the loader stage fails to either notice the "boot drive number" info passed in %dl by the BIOS (or, in this case, by GRUB) and/or propagate it to latter stages of their multi-stage pre-boot process. As an example, FreeDOS ignores the parameter and fails to locate KERNEL.SYS, while ReactOS's freeldr uses it and is able to load its config file, but then fails to boot the (drive-#-hardcoded) paths in that same file. This sorry state of things motivates most BIOSes to actually "swap" your "designated boot device" with the actual first HD, so that systems that assume they were installed on hd0 will work. Drivemap basically replicates this functionality using the "canonical" real-mode interrupt handler chaining pattern: it intercepts calls to the BIOS drive access interrupt and calls the previous handler after performing its role. This is not a "dirty hack" (well, it _is_ by current standards), and in fact it was the way TSRs worked in DOS. Here's what happens when the Windows loader (or FreeDOS, etc.) tries to access the drives: ntldr --(int13h: r,0x80)--> drivemap_int13h --(lcall: f,r,0x81)-->BIOS Drivemap (and other TSRs) actually _simulate_ an interrupt call by pushing the flags on the stack, then doing a far call to the address of the handler they replaced (the address that occupied the related slot in the IVT when they were installed). This was, for example, how resident anti-virus programs were implemented in DOS, and I suppose that other programs like DoubleSpace and SmartDrive used it too. For modern OSes, once the initial stage has loaded the kernel and the relevant modules, it usually fires up its own disk drivers that reflect the "true" (as defined by the disk controller) order of the HDs, so neither the BIOS nor drivemap affect that. Moreover, many OSes currently select their root device based on its UUID, label, etc, so there is no problem switching the BIOS routines because they won't be used again after the initial loader is finished. The exception is, of course, FreeDOS, where the drives stay swapped for the whole session because it has no disk drivers other than those provided by BIOS. I hope this has reassured you that neither mmap nor drivemap are doing any "dark things" nor "1980s DOS/BIOS black magic". The only BIOS data table modified (by mmap) should be the "available free memory" at the BDA, which is a completely documented procedure and quite about the only way of telling a DOS "do not use this memory". Uhh... btw, I think I found the problem with mmap and FreeDOS: both the mmap int handler and the drivemap int handler reserve their memory as high as possible under 1M. Is FreeDOS aware of this? I mean, we can tell it not to touch memory under 640K through the BDA and INT12, but how do we tell it not to touch the 640K-1M area? I will check if this is the cause of the disaster... tomorrow - it's 4AM and I'm sleepy. Goodbye! -- -- Lazy, Oblivious, Rational Disaster -- Habbit
signature.asc
Description: Esto es una parte de mensaje firmado digitalmente
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
