Re: COFF
- From: "robertwessel2@xxxxxxxxx" <robertwessel2@xxxxxxxxx>
- Date: 30 Nov 2005 16:45:15 -0800
Bill Cunningham wrote:
> "Bill Cunningham" <nospam@xxxxxxxxx> wrote in message
> news:_5ojf.21132$KZ2.1772@xxxxxxxxxxx
> > > "
> > > The small program in the MBR will attempt to locate an active (bootable)
> > > partition in its partition table. If such a partition is found, the boot
> > > sector of that partition is read into memory at location 0000:7C00 and
> > > the MBR program jumps to memory location 0000:7C00. Each operating
> > > system has its own boot sector format. The small program in the boot
> > > sector must locate the first part of the operating system's kernel
> > > loader program (or perhaps the kernel itself or perhaps a "boot manager
> > > program") and read that into memory.
> > > "
> > >
> > > Randy
> > So there is no ID in the MBR which is 512 bytes if I'm correct that
> > identifies a filesystem? Does the MBR jump to an adress that identifies a
> > partition type or just to where the kernel image resides? I will read your
> > link thanks.
> >
> > Bill
>
> Ok that is a great page you've found. How did you find it? Anyway that
> address 0000:7c00 is that physical memory? Surely it must be Because this is
> before the memory manager creates virtual addresses. Can I look at the
> binary of hex values of 0000:7c00 with a hex editor?
If you have a debugger running in DOS (debug), or a kernel debugger
(SoftICE, for example), you can certainly look at that physical
storage. The problem is there's usually nothing actually there to look
at.
During the boot process the BIOS code loads the first sector of the
boot drive to 0:7c00, and then branches there. If it's not a
partitioned drive (a floppy, for example), the code that's load in
those 512 bytes has to know enough about the filesystem and operating
system in that volume in order to load the next chunk of boot code for
the OS. In many cases, that first boot sector (which is obviously
filesystem and OS specific), just loads several additional sectors from
a fixed location on the volume (for example, on FAT32, the rest of the
boot program is in the several sectors just after the first sector on
the volume). In other cases the volume layout is simple enough that
the half KB of code can immediately start loading code from a file (for
example, DOS boot sectors typically could find the appropriate file -
IO.SYS commonly - in the root directory). On a PC, all of the early
disk access is typically done via the BIOS Int 13 functions, so you'll
see Int 13 calls in the boot sector. In any event, once enough code is
loaded the actual filesystem is readable, and the boot process starts
rolling in earnest, with more and more chunks of the OS being loaded.
Again, the exact process is hugely OS and filesystem dependant.
When you have a partitioned volume, things are slightly more complex.
The BIOS still loads the first sector of the boot drive to 0:7c00, and
then jumps to it as normal (the BIOS doesn't actually understand disk
partitions), but the program in that sector is the partition boot
program, and at least for PCs, not particularly OS or filesystem
specific.
What the partition boot program does it move itself out of the way
(typically to 0:0600), select a partition to boot from, load the first
sector from that partition to 0:7c00 (this is why it had to move itself
out of the way - the OS boot sector loads to the same location), and
then jumps to it. In broad terms the OS boot sector doesn't really
know it was loaded by the BIOS (eg. from an unpartitioned disk) or from
the partition boot program, it just starts the OS boot process when
it's loaded.
Actually that's a bit of an oversimplification - the OS boot sector has
to know enough about partitions to read from the correct partition, not
the beginning of the disk. That's commonly taken care of when the
partition is formatted by writing a field into the OS boot sector with
that information (for example, FAT volumes contain a "number of hidden
sectors" field which defines how many sectors exist prior to the
partition on the disk). Alternatively, the partition boot program
passes a pointer to the partition entry (0:SI), which has the required
information.
If you want to see this code, you need something that can read the
sectors off the disk - the first sector of the hard disk will be the
partition boot code and partition table - on a floppy it'll just be
the OS boot sector.
.
- Follow-Ups:
- Re: COFF
- From: Bill Cunningham
- Re: COFF
- Prev by Date: Re: Python or Ruby or ..
- Next by Date: Re: Python or Ruby or ..
- Previous by thread: Re: COFF
- Next by thread: Re: COFF
- Index(es):
Relevant Pages
|
|
