Re: Does "Windows XP Mode" REALLY work?

PDFrank wrote:

> Running Windows 7 Home Premium SP1
>
> I have a few good legacy programs that don't run right under Windows 7,
> even under "compatibility mode."
>
> They ran fine under XP.
>
> The software companies that wrote the programs went bye-bye.
>
> $89.95 is the price to upgrade to 7 Professional.
>
> Is it possible that they still might not run right even in "XP Mode"?

There is no guarantee that any program, even one written for the OS,
will run under an *emulated* instance of that OS. Except for the CPU,
all the hardware inside a VM is emulated. The only way that you can
guarantee that your old apps working under Windows XP will work in the
future is to keep using Windows XP. If the host is critical then keep
it the way it works with your critical applications.

You could use a multi-boot manager (I dislike the pseudo-boot manager
provided by Microsoft since it requires an OS to load before you get to
pick the OS that you really want to load), like gag.sourceforge.net. Or
you could use disk bays that let you swap out which hard disk with which
OS you want to load on boot. Or you could disable one controller (to
disable one disk) and enable another controller (to enable a different
disk) in the BIOS. Or you could use a muli-ganged mechanical switch to
disconnect power from one hard disk and enable it to another to let you
switch as to which disk gets used on boot to load the OS on the enabled
disk. Or ... there's probably other scenarios that I haven't covered.

XP Mode is only available in some editions of Windows 7 but you never
mentioned which edition you have. So you have to pay more up front to
get the Pro, Enterprise, or Biz editions of Windows 7 to use XP Mode but
then you're using a VM (virtual machine) instance of Windows XP and not
all old programs like to run inside a VM, especially if they want to
directly control the hardware (and they won't like the emulated
hardware). So it depends on what you have. If you want to ensure your
old apps continue to be usable then keep running them under a *real*
instance of the OS with which they operate. Don't expect backwards
compatibility or emulated environments to work with old programs.

So what was the real reason why you went to Windows 7? Did your old
hardware actually die and wasn't repairable, like replacing a failed
hard disk? New doesn't mean better. It just means different. If you
had no real criteria that mandated a move to a different OS or to a
different version of it then there was no reason to move. You can try
using a VM, like XP Mode, VMware Server, VirtualBox, DOSbox, or whatever
but anything running inside a VM will be slower. Emulated hardware
doesn't work as fast as real hardware because of the extra layer of
software to emulate the hardware. You could use a real instance of
Windows XP on another partition or hard disk (and use several methods to
switch between them to pick which OS to load) but perhaps you still have
the old computer so just leave it running Windows XP with those old
applications. I still have a really old host just to run DOS-mode apps,
another old host to run Windows 98 and Windows XP (by multi-booting
between partitions on different HDDs), and another (at a different site)
that runs Windows 7 (just so I can keep up to speed and do development
testing but not because any of my apps require it).

Hi, VanguardLH.

> (I dislike the pseudo-boot manager provided by Microsoft since it requires
> an OS to load before you get to pick the OS that you really want to load)

Not true. The Win7 boot process loads only the single 383,786-byte file,
"bootmgr", which reads the BCD (Boot Configuration Data) from the
poorly-named \Boot folder. After the user chooses (by default or by
selection) to load Win7, then the boot process continues to find and load
the files in Win7's \Windows folder tree. But none of Win7 gets loaded at
all if the user chooses to load a "previous version of Windows".

To load a "previous" version, bootmgr loads the WinXP startup files (NTLDR,
NTDETECT.COM and Boot.ini) and uses those to locate and load WinXP - or
whatever the user chooses. (My experience has been only with Windows.
Except for testing, I haven't run WinXP regularly since Vista went RTM in
2006. Even though I have Win7 Ultimate, I have not tried Windows XP Mode.)
In either case, only ONE OS gets loaded. Any other OS is simply ignored.

At one point during the Vista beta in 2006, I had both 32-bit and 64-bit
versions of WinXP AND of each of 3 builds of the Vista beta installed.
"Octo-booting"! ;^}

While the details are different, Microsoft's basic idea for multi-booting
has been the same at least since I first used it to dual-boot Win95/WinNT4.0
in 1998: Start with minimal files in the System Partition; use those to
present the OS menu, then load the user's choice of OS from its own Boot
Volume. Never load any full OS before presenting the menu. (As you
probably know, the terms Boot Volume and System Partition are backwards from
the common usage; see KB314470 for the definitions.)

I do use the "tell the BIOS to boot from the other disk" method, sometimes,
but that is just for insurance in case my main HDD has a problem.
Microsoft's method works fine for me.

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2011 (Build 15.4.3538.0513) in Win7 Ultimate x64 SP1


"VanguardLH" wrote in message news:j562k2$4rp$...

PDFrank wrote:

> Running Windows 7 Home Premium SP1
>
> I have a few good legacy programs that don't run right under Windows 7,
> even under "compatibility mode."
>
> They ran fine under XP.

> The software companies that wrote the programs went bye-bye.
>
> $89.95 is the price to upgrade to 7 Professional.
>
> Is it possible that they still might not run right even in "XP Mode"?

There is no guarantee that any program, even one written for the OS,
will run under an *emulated* instance of that OS. Except for the CPU,
all the hardware inside a VM is emulated. The only way that you can
guarantee that your old apps working under Windows XP will work in the
future is to keep using Windows XP. If the host is critical then keep
it the way it works with your critical applications.

You could use a multi-boot manager (I dislike the pseudo-boot manager
provided by Microsoft since it requires an OS to load before you get to
pick the OS that you really want to load), like gag.sourceforge.net. Or
you could use disk bays that let you swap out which hard disk with which
OS you want to load on boot. Or you could disable one controller (to
disable one disk) and enable another controller (to enable a different
disk) in the BIOS. Or you could use a muli-ganged mechanical switch to
disconnect power from one hard disk and enable it to another to let you
switch as to which disk gets used on boot to load the OS on the enabled
disk. Or ... there's probably other scenarios that I haven't covered.

XP Mode is only available in some editions of Windows 7 but you never
mentioned which edition you have. So you have to pay more up front to
get the Pro, Enterprise, or Biz editions of Windows 7 to use XP Mode but
then you're using a VM (virtual machine) instance of Windows XP and not
all old programs like to run inside a VM, especially if they want to
directly control the hardware (and they won't like the emulated
hardware). So it depends on what you have. If you want to ensure your
old apps continue to be usable then keep running them under a *real*
instance of the OS with which they operate. Don't expect backwards
compatibility or emulated environments to work with old programs.

So what was the real reason why you went to Windows 7? Did your old
hardware actually die and wasn't repairable, like replacing a failed
hard disk? New doesn't mean better. It just means different. If you
had no real criteria that mandated a move to a different OS or to a
different version of it then there was no reason to move. You can try
using a VM, like XP Mode, VMware Server, VirtualBox, DOSbox, or whatever
but anything running inside a VM will be slower. Emulated hardware
doesn't work as fast as real hardware because of the extra layer of
software to emulate the hardware. You could use a real instance of
Windows XP on another partition or hard disk (and use several methods to
switch between them to pick which OS to load) but perhaps you still have
the old computer so just leave it running Windows XP with those old
applications. I still have a really old host just to run DOS-mode apps,
another old host to run Windows 98 and Windows XP (by multi-booting
between partitions on different HDDs), and another (at a different site)
that runs Windows 7 (just so I can keep up to speed and do development
testing but not because any of my apps require it).

R. C. White wrote:

> Hi, VanguardLH.
>
>> (I dislike the pseudo-boot manager provided by Microsoft since it requires
>> an OS to load before you get to pick the OS that you really want to load)
>
> Not true. The Win7 boot process loads only the single 383,786-byte file,
> "bootmgr", which reads the BCD (Boot Configuration Data) from the
> poorly-named \Boot folder. After the user chooses (by default or by
> selection) to load Win7, then the boot process continues to find and load
> the files in Win7's \Windows folder tree. But none of Win7 gets loaded at
> all if the user chooses to load a "previous version of Windows".
>
> To load a "previous" version, bootmgr loads the WinXP startup files (NTLDR,
> NTDETECT.COM and Boot.ini) and uses those to locate and load WinXP - or
> whatever the user chooses. (My experience has been only with Windows.
> Except for testing, I haven't run WinXP regularly since Vista went RTM in
> 2006. Even though I have Win7 Ultimate, I have not tried Windows XP Mode.)
> In either case, only ONE OS gets loaded. Any other OS is simply ignored.
>
> At one point during the Vista beta in 2006, I had both 32-bit and 64-bit
> versions of WinXP AND of each of 3 builds of the Vista beta installed.
> "Octo-booting"! ;^}
>
> While the details are different, Microsoft's basic idea for multi-booting
> has been the same at least since I first used it to dual-boot Win95/WinNT4.0
> in 1998: Start with minimal files in the System Partition; use those to
> present the OS menu, then load the user's choice of OS from its own Boot
> Volume. Never load any full OS before presenting the menu. (As you
> probably know, the terms Boot Volume and System Partition are backwards from
> the common usage; see KB314470 for the definitions.)
>
> I do use the "tell the BIOS to boot from the other disk" method, sometimes,
> but that is just for insurance in case my main HDD has a problem.
> Microsoft's method works fine for me.
>
> RC

Since you mentioned the size, just how does 383,786 byte fit into a 446
byte bootstrap area of the MBR? And if that partition becomes unusable
then you cannot get at the bootmgr program or the \boot folder. That
you have to do anything inside any particular partition shows that
Microsoft again hasn't a clue on how to do multi-booting. The 446 bytes
in the MBR is all you get for the [initial] bootstrap program (and
perhaps their first cylinder since enumeration for partitions begins at
cylinder 1 and how some real multi-boot managers manage to overcome the
446 byte maximum in the MBR). An MBR bootstrap program is binary and
relies on no file system whereas the bootmgr file and \boot folder
obviously have to be read through a file system or get laid down within
a file system to be found by something that will interpret the file
system to obtain the file and folder. Also, just WHAT is going to load
that file's image into memory and then pass control to it? The
bootstrap program in the MBR? Yeah, right. That passes control to the
boot *sector* of the currently active-marked partition which loads a
kernel or something of the OS that then loads the binary image. What's
in the boot sector *is* part of the OS in that partition. What did you
think was *loading* bootmgr into memory to then run it? Magic?

Real multi-boot managers don't reside within any partition. Real multi-
boot managers don't rely on any file system within a partition (because
they're not in a partition where formatting is performed).

Hi, VanguardLH.

I started this Reply a couple of days ago, then got interrupted and
distracted. But it's an important point that should not be just dropped.

> What did you think was *loading* bootmgr into memory to then run it?
> Magic?

Of course not. It's the BIOS in the computer's ROM/NVRAM, which contains
the startup code - which starts the hard disks spinning and "pulls the
computer system up by its own bootstraps". Like the old analogy of the ship
that first sends a small line to dockhands, who then pull the small line
which is attached to a bigger line and then the really big one.

At power-on, the computer knows NOTHING except what is in the BIOS. All
that says is to find the first physical sector on the first physical disk,
read its contents (the MBR code) into RAM, then transfer control to Byte
Zero and start executing. Those instructions say to read the Partition
Table and see which partition has the code (80h) marking it as the Active
(bootable) partition, then to read the first physical sector of THAT
partition into RAM and execute those instructions. That sector is the Boot
Sector, and it includes the NAME of the bootmgr (or NTLDR) file, not the
whole file, of course. At this point, the computer does not yet have a file
system installed and is not yet smart enough to read any other partitions,
so a file by that name must be in that first partition (the System
Partition). But once that bootmgr file is read and loaded, and starts
executing, it knows how to find the BCD...and the snowball starts growing as
it rolls downhill from there. Not magic. Just seems like it. ;<}


> Since you mentioned the size, just how does 383,786 byte fit into a 446
> byte bootstrap area of the MBR?

It doesn't, of course. All that the MBR does (for our discussion) is point
to the Boot Sector of the Active Partition. The MBR does not even have the
name of the file. The whole bootmgr file is not in the boot sector, either.
Only the name "BOOTMGR" is in the boot sector. The name "NTLDR" is in the
boot sector for a WinXP Boot Volume.

The MBR and the Boot Sector are different, both in function and in location.
The MBR is on the first physical sector of the DISK, (Track 0, Sector 0) and
there is only ONE on each DISK. The Boot Sector is the first physical
sector on each PARTITION, and there may be up to 4 on each disk. Since no
partition can start at Sector 0 of a disk, the Boot Sector must be on some
track other than Track 0. If the first partition starts on Track 64, then
the first Boot Sector will be at Sector 0 of Track 64. The MBR can never be
in a Boot Sector. The MBR cannot even be in the System Partition; it is in
the zero track, ahead of the first partition - outside any partition so that
the file system doesn't even know about it.


In Windows 7 Inside Out, the process is summarized, starting with:
"The startup process in Windows 7 begins when your computer performs its
power-on self test (POST), which is followed by the POST for each adapter
card that has a BIOS, such as advanced storage adapters and video cards. The
system BIOS then reads the master boot record (MBR)—the first physical
sector on the hard disk defined as the boot device—and transfers control to
the code in the MBR, which is created during setup of Windows 7 or Windows
Vista. This is where Windows takes over the startup process."

At this very early stage in the boot process, as you said, there is no file
system, so we can't use extensions or even Drive letters. The partition
location comes from the Partition Table, which is also in the first physical
sector of the disk, along with the MBR code, and the first hex byte in the
table for ONE of those partitions is "80", indicating that THIS partition is
the one to be
used to boot the computer. And in computer language, this is not the Boot
Partition; it is the System Partition. (As Ed Bott and other writers remind
us, we BOOT from the SYSTEM partition and install the operating SYSTEM in
the BOOT volume.) This Active Partition - the System Partition - is the one
that must hold bootmgr and/or NTLDR, either of which will point the way to
the Boot Volume, which can be any primary partition or any logical drive in
an extended partition on any HDD in the computer. In the Boot Volume we
will find the Boot Folder for ONE installation of Windows. If we have both
WinXP and Win7 installed, they should be in separate volumes; the Root of
each volume will contain a \Windows folder tree holding the many folders and
files making up that OS. If we have both 32-bit and 64-bit versions of Win7
installed, each should have its own Boot Volume and Boot Folder.

None of this complexity is in the MBR. Those few bytes are only pointers
used by the system, not by Windows, to find and load the complex structures
needed, step by step, to load our chosen operating system.

Win7 I/O continues:
"Here’s what happens next:
"1. The MBR reads the boot sector—the first sector of the active
partition—which contains code that starts the Windows Boot Manager program,
Bootmgr.
"2. The Windows Boot Manager reads the contents of the Boot Configuration
Data store, which contains configuration information about all operating
systems installed on the computer. It uses this data to build and display
the boot menu."

At this stage, no OS has been loaded - unless you consider "bootmgr" and the
BCD to be "the OS". These files come with Win7, just as NTLDR comes with
WinXP, but none of them are in the \Windows boot folder. They load the OS,
but they are not included in it. So I don't think it's correct to say that
"it requires an OS to load before you get to pick the OS". This preliminary
load is less than 400 KB, not the multi-GBs of the OS itself. Even a
single-boot setup loads these few startup files first, so that it can find
and load the OS. And if you use the "tell the BIOS to boot from the other
disk" method and multi-boot by starting each boot from a different HDD, the
computer will first load bootmgr/NTLDR to find out where the \Windows folder
resides on the disk.


I've edited this post so much that now I'm confusing myself. So I'll quit
here and wait for comments.

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2011 (Build 15.4.3538.0513) in Win7 Ultimate x64 SP1


"VanguardLH" wrote in message news:j56aod$jcb$...

R. C. White wrote:

> Hi, VanguardLH.
>
>> (I dislike the pseudo-boot manager provided by Microsoft since it
>> requires
>> an OS to load before you get to pick the OS that you really want to load)
>
> Not true. The Win7 boot process loads only the single 383,786-byte file,
> "bootmgr", which reads the BCD (Boot Configuration Data) from the
> poorly-named \Boot folder. After the user chooses (by default or by
> selection) to load Win7, then the boot process continues to find and load
> the files in Win7's \Windows folder tree. But none of Win7 gets loaded at
> all if the user chooses to load a "previous version of Windows".
>
> To load a "previous" version, bootmgr loads the WinXP startup files
> (NTLDR,
> NTDETECT.COM and Boot.ini) and uses those to locate and load WinXP - or
> whatever the user chooses. (My experience has been only with Windows.
> Except for testing, I haven't run WinXP regularly since Vista went RTM in
> 2006. Even though I have Win7 Ultimate, I have not tried Windows XP
> Mode.)
> In either case, only ONE OS gets loaded. Any other OS is simply ignored.
>
> At one point during the Vista beta in 2006, I had both 32-bit and 64-bit
> versions of WinXP AND of each of 3 builds of the Vista beta installed.
> "Octo-booting"! ;^}
>
> While the details are different, Microsoft's basic idea for multi-booting
> has been the same at least since I first used it to dual-boot
> Win95/WinNT4.0
> in 1998: Start with minimal files in the System Partition; use those to
> present the OS menu, then load the user's choice of OS from its own Boot
> Volume. Never load any full OS before presenting the menu. (As you
> probably know, the terms Boot Volume and System Partition are backwards
> from
> the common usage; see KB314470 for the definitions.)
>
> I do use the "tell the BIOS to boot from the other disk" method,
> sometimes,
> but that is just for insurance in case my main HDD has a problem.
> Microsoft's method works fine for me.
>
> RC

Since you mentioned the size, just how does 383,786 byte fit into a 446
byte bootstrap area of the MBR? And if that partition becomes unusable
then you cannot get at the bootmgr program or the \boot folder. That
you have to do anything inside any particular partition shows that
Microsoft again hasn't a clue on how to do multi-booting. The 446 bytes
in the MBR is all you get for the [initial] bootstrap program (and
perhaps their first cylinder since enumeration for partitions begins at
cylinder 1 and how some real multi-boot managers manage to overcome the
446 byte maximum in the MBR). An MBR bootstrap program is binary and
relies on no file system whereas the bootmgr file and \boot folder
obviously have to be read through a file system or get laid down within
a file system to be found by something that will interpret the file
system to obtain the file and folder. Also, just WHAT is going to load
that file's image into memory and then pass control to it? The
bootstrap program in the MBR? Yeah, right. That passes control to the
boot *sector* of the currently active-marked partition which loads a
kernel or something of the OS that then loads the binary image. What's
in the boot sector *is* part of the OS in that partition. What did you
think was *loading* bootmgr into memory to then run it? Magic?

Real multi-boot managers don't reside within any partition. Real multi-
boot managers don't rely on any file system within a partition (because
they're not in a partition where formatting is performed).

R. C. White wrote:

> Hi, VanguardLH.
>
> I started this Reply a couple of days ago, then got interrupted and
> distracted. But it's an important point that should not be just dropped.
>
>> What did you think was *loading* bootmgr into memory to then run it?
>> Magic?
>
> Of course not. It's the BIOS in the computer's ROM/NVRAM, which contains
> the startup code - which starts the hard disks spinning and "pulls the
> computer system up by its own bootstraps". Like the old analogy of the ship
> that first sends a small line to dockhands, who then pull the small line
> which is attached to a bigger line and then the really big one.
>
> At power-on, the computer knows NOTHING except what is in the BIOS. All
> that says is to find the first physical sector on the first physical disk,
> read its contents (the MBR code) into RAM, then transfer control to Byte
> Zero and start executing. Those instructions say to read the Partition
> Table and see which partition has the code (80h) marking it as the Active
> (bootable) partition, then to read the first physical sector of THAT
> partition into RAM and execute those instructions. That sector is the Boot
> Sector, and it includes the NAME of the bootmgr (or NTLDR) file, not the
> whole file, of course. At this point, the computer does not yet have a file
> system installed and is not yet smart enough to read any other partitions,
> so a file by that name must be in that first partition (the System
> Partition). But once that bootmgr file is read and loaded, and starts
> executing, it knows how to find the BCD...and the snowball starts growing as
> it rolls downhill from there. Not magic. Just seems like it. ;<}
>
>> Since you mentioned the size, just how does 383,786 byte fit into a 446
>> byte bootstrap area of the MBR?
>
> It doesn't, of course. All that the MBR does (for our discussion) is point
> to the Boot Sector of the Active Partition. The MBR does not even have the
> name of the file. The whole bootmgr file is not in the boot sector, either.
> Only the name "BOOTMGR" is in the boot sector. The name "NTLDR" is in the
> boot sector for a WinXP Boot Volume.
>
> The MBR and the Boot Sector are different, both in function and in location.
> The MBR is on the first physical sector of the DISK, (Track 0, Sector 0) and
> there is only ONE on each DISK. The Boot Sector is the first physical
> sector on each PARTITION, and there may be up to 4 on each disk. Since no
> partition can start at Sector 0 of a disk, the Boot Sector must be on some
> track other than Track 0. If the first partition starts on Track 64, then
> the first Boot Sector will be at Sector 0 of Track 64. The MBR can never be
> in a Boot Sector. The MBR cannot even be in the System Partition; it is in
> the zero track, ahead of the first partition - outside any partition so that
> the file system doesn't even know about it.

So you do now how bootstrapping works and so far we agree.

> At this stage, no OS has been loaded - unless you consider "bootmgr" and the
> BCD to be "the OS".

Who do you think writes the boot sector of the OS partition? Where did
you think that code came from? It wasn't there just because you created
a partition. That *is* part of THAT operating system in that partition.
Even you admit that in your above description. If you install a
different OS, you get a different boot loader in the boot sector. So,
yes, that is part of the OS (along with it passing control to the
bootmgr program which is NOT in the boot sector). What is in the boot
sector was put there by the OS in that partition and is used by the OS
in that partition. The boot sector in the Windows partition didn't come
from Redhat or SuSE.

If you didn't install an OS in a partition but marked that partition as
active in the partition table in the MBR, well, you know the result
which is you get an error that you cannot find an OS to load.

The BIOS loading its boot code that then loads the MBR's bootstrap code
which reads the partition table to find which one is active is outside
the OS. Once the MBR bootstrap program loads the boot sector of the
active partition then, yes, you have started loading the OS in that
partition. Whether you want to differentiate it from the kernel for the
OS and as a separate boot code used before the kernel doesn't obviate
that the boot loader in the boot sector came from that OS. You are
loading something of that OS in that partition before you even get to
pick which OS you really wanted to load.

You have a hallway of doors but before you can open any one of them you
first have to open the one marked "Windows" which then has a panel of
buttons from which you can unlock the door that you really wanted to
open in the first place. You didn't have to walk through the door to go
move around the furniture but you had to first open THAT door before any
of the others were available for selection. Multi-boot provides you a
selection before any OS or any part of it loads. It's a select-then-
boot scheme. Microsoft's scheme is boot-then-select. With multi-boot,
you can walk up to any door and open that one. With Microsoft, you
first have to open their door before you can decide to walk in or hit a
button to open one of the other doors.

Real multi-boot managers let you pick which OS to load before ANY boot
sector for the OS in ANY partition on ANY drive gets loaded. They don't
go loading any part of an OS to offer the user which one to load. They
don't care what's in the partition. Their purpose is load into memory
WHATEVER is in the boot sector and pass control to it. With Microsoft's
scheme, and after wiping that partition or installing a different OS
(different as in going pre-Vista for Windows or different as in going to
Linux), you would lose all your multi-boot selections because wiping
that partition resulted in losing their bootmgr and its database.

Though we're discussing the old BIOS/MBR scheme, just wait until
end-user hosts start coming out with GUID Partition Table and UEFI with
the boot manager built-in.

http://en.wikipedia.org/wiki/GUID_Partition_Table
http://en.wikipedia.org/wiki/Extensi...e#Boot_manager

Luckily I haven't had to support or use any of those type hosts ... yet.

Hi, VanguardLH.

OK. I think we are in full agreement except for the one point - which is
really just semantics.

Your comment was that Microsoft's multi-boot manager "requires an OS to load
before you get to pick the OS that you really want to load". I would have
said that it "requires an OS-selection tool to load before it loads a full
OS".

And I'm not looking forward to moving from MBR-type disks to GPT disks.
I've been reading about those ever since at least the WinXP Resource Kit
back in 2003. But I've never seen one or even been close to one in real
life - so far as I know. I haven't even tried to understand those yet. My
new mobo (MSI 890FXA-GD70 - http://us.msi.com/product/mb/890FXA-GD70.html )
has EFI built in, I think, but I haven't tried to do anything with that. I
don't support any computers but mine and, except for brief transition
periods, I've never had more than one at a time. (That netbook that I got
last year so I could learn a little about networking doesn't really count as
another computer.)

RC
--
R. C. White, CPA
San Marcos, TX

Microsoft Windows MVP (2002-2010)
Windows Live Mail 2011 (Build 15.4.3538.0513) in Win7 Ultimate x64 SP1


"VanguardLH" wrote in message news:j5c8ab$jf9$...

R. C. White wrote:

> Hi, VanguardLH.
>
> I started this Reply a couple of days ago, then got interrupted and
> distracted. But it's an important point that should not be just dropped.
>
>> What did you think was *loading* bootmgr into memory to then run it?
>> Magic?
>
> Of course not. It's the BIOS in the computer's ROM/NVRAM, which contains
> the startup code - which starts the hard disks spinning and "pulls the
> computer system up by its own bootstraps". Like the old analogy of the
> ship
> that first sends a small line to dockhands, who then pull the small line
> which is attached to a bigger line and then the really big one.
>
> At power-on, the computer knows NOTHING except what is in the BIOS. All
> that says is to find the first physical sector on the first physical disk,
> read its contents (the MBR code) into RAM, then transfer control to Byte
> Zero and start executing. Those instructions say to read the Partition
> Table and see which partition has the code (80h) marking it as the Active
> (bootable) partition, then to read the first physical sector of THAT
> partition into RAM and execute those instructions. That sector is the
> Boot
> Sector, and it includes the NAME of the bootmgr (or NTLDR) file, not the
> whole file, of course. At this point, the computer does not yet have a
> file
> system installed and is not yet smart enough to read any other partitions,
> so a file by that name must be in that first partition (the System
> Partition). But once that bootmgr file is read and loaded, and starts
> executing, it knows how to find the BCD...and the snowball starts growing
> as
> it rolls downhill from there. Not magic. Just seems like it. ;<}
>
>> Since you mentioned the size, just how does 383,786 byte fit into a 446
>> byte bootstrap area of the MBR?
>
> It doesn't, of course. All that the MBR does (for our discussion) is
> point
> to the Boot Sector of the Active Partition. The MBR does not even have
> the
> name of the file. The whole bootmgr file is not in the boot sector,
> either.
> Only the name "BOOTMGR" is in the boot sector. The name "NTLDR" is in the
> boot sector for a WinXP Boot Volume.
>
> The MBR and the Boot Sector are different, both in function and in
> location.
> The MBR is on the first physical sector of the DISK, (Track 0, Sector 0)
> and
> there is only ONE on each DISK. The Boot Sector is the first physical
> sector on each PARTITION, and there may be up to 4 on each disk. Since no
> partition can start at Sector 0 of a disk, the Boot Sector must be on some
> track other than Track 0. If the first partition starts on Track 64, then
> the first Boot Sector will be at Sector 0 of Track 64. The MBR can never
> be
> in a Boot Sector. The MBR cannot even be in the System Partition; it is
> in
> the zero track, ahead of the first partition - outside any partition so
> that
> the file system doesn't even know about it.

So you do now how bootstrapping works and so far we agree.

> At this stage, no OS has been loaded - unless you consider "bootmgr" and
> the
> BCD to be "the OS".

Who do you think writes the boot sector of the OS partition? Where did
you think that code came from? It wasn't there just because you created
a partition. That *is* part of THAT operating system in that partition.
Even you admit that in your above description. If you install a
different OS, you get a different boot loader in the boot sector. So,
yes, that is part of the OS (along with it passing control to the
bootmgr program which is NOT in the boot sector). What is in the boot
sector was put there by the OS in that partition and is used by the OS
in that partition. The boot sector in the Windows partition didn't come
from Redhat or SuSE.

If you didn't install an OS in a partition but marked that partition as
active in the partition table in the MBR, well, you know the result
which is you get an error that you cannot find an OS to load.

The BIOS loading its boot code that then loads the MBR's bootstrap code
which reads the partition table to find which one is active is outside
the OS. Once the MBR bootstrap program loads the boot sector of the
active partition then, yes, you have started loading the OS in that
partition. Whether you want to differentiate it from the kernel for the
OS and as a separate boot code used before the kernel doesn't obviate
that the boot loader in the boot sector came from that OS. You are
loading something of that OS in that partition before you even get to
pick which OS you really wanted to load.

You have a hallway of doors but before you can open any one of them you
first have to open the one marked "Windows" which then has a panel of
buttons from which you can unlock the door that you really wanted to
open in the first place. You didn't have to walk through the door to go
move around the furniture but you had to first open THAT door before any
of the others were available for selection. Multi-boot provides you a
selection before any OS or any part of it loads. It's a select-then-
boot scheme. Microsoft's scheme is boot-then-select. With multi-boot,
you can walk up to any door and open that one. With Microsoft, you
first have to open their door before you can decide to walk in or hit a
button to open one of the other doors.

Real multi-boot managers let you pick which OS to load before ANY boot
sector for the OS in ANY partition on ANY drive gets loaded. They don't
go loading any part of an OS to offer the user which one to load. They
don't care what's in the partition. Their purpose is load into memory
WHATEVER is in the boot sector and pass control to it. With Microsoft's
scheme, and after wiping that partition or installing a different OS
(different as in going pre-Vista for Windows or different as in going to
Linux), you would lose all your multi-boot selections because wiping
that partition resulted in losing their bootmgr and its database.