From: olson30@netcom.com (John Sully)
Subject: Re: Can we get the details of the benchmark setup? Please!
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 17 Dec 1992 04:51:18 GMT

brian@jaguar.cs.utah.edu (Brian Sturgill) writes:

[ in response to Tim's remarks about NT and OS/2 boot manager... ]

>As to why doesn't this work?  Well first of all why should it work?
>NT is beta code and is intended only to coexist with Win3.1/DOS.
>Secondly, why are you so certain that MS's move is anti-OS/2?
>There may well be valid reasons why the bootstrap does this.
>It is clear that you have not even asked, but have already judged MS
>to be guilty.

>The wrong impression is that you explicitly said this was an intentional
>plot on the part of MS to do in OS/2 users (well you weren't quite
>that evil, but close :-)).  Even if MS explicitly checks for Boot Manager,
>this does not necessarily imply an evil plot, there may well be specific
>hardware configurations that boot manager interacts poorly with NT.
>Until you at least attempt to get a response out of Microsoft, I think
>you are doing people a disservice to "blame" MS.

Having recently (and not so recently) spent quite a bit of time nosing
around in and adding boot manager like facilities to the UNIX System 
V Release 4 bootloader I think that I can qualify as somewhat knowledgable
about how a PC bootloader works.  In fact this one is probably more
complex than most, since it is a protected mode loader, but the 
principle is the same in either case....

There is no reason for the NT loader (or kernel) to poke around in the
master boot block partition table looking for another OS's signature and
then refusing to run if that signature is found.  None.  Period.

The boot process is really quite simple and any program which has to
load the partition boot block of another OS has to do essentially the
same thing.  These steps are as follows:

	1.  Read the fdisk table at the end of sector 0 of the HD.
	2.  Read the first block of the partition you wish to boot.
	    This should be loaded at 0x7C00 and is the last element
	    of the partition structure.  It is also found as a funky
	    cylinder/head/sector address, but this is more direct, but
	    only if you have a loader which can do the appropriate 
	    translations.
	3.  Make sure it has the "magic number" 0xAA55 at location 510.
	4.  Copy the entry from the fdisk table for this partition to
	    a known location in memory.  Set DS:EDI to point to this
	    location.
	5.  Futz with the structure as DS:EDI and mark the in memory.*
	    copy as active, 0x80 (at some offset, I forget exactly).
	6.  Set your code segement to 0 and push the new CS (0) and
	    IP (7C00) on the stack and do an lret (you have to be in
	    real mode here).

	*   The code in the master boot block will only boot the
	    partition marked as active in the fdisk partition table
	    so it does not perform this step.

Once you have made it to 0:7c00 and are executing the partition boot
code, it must load the rest of itself (you only got the first 512 bytes,
now you have to get the rest) and begins executing.  Since the environment
presented by the master boot block is fairly primitive when compared with
the environment needed by a protected mode kernel such as NT, much setup
has to be done by the partition boot code before the kernel is loaded and
started executing.  

I do not see how simply having OS/2 boot manager on the system can
*possibly* affect NT's boot loader.  In fact, I do not see how having
the NT partition boot record loaded by OS/2 boot manager can possibly
affect it's operation.  

So, if Tim didn't say it, I will:  this reeks of the attitude displayed
in the infamous "Hard Drive" quote "it ain't done 'til Lotus won't run".
It is obvious that Microsoft spent some code in a portion of NT in which
space is at a premium to make sure that NT would not coexist with OS/2.
If they did it in the kernel, that's even worse, 'cause the damn thing
is running already.

John

Xref: sparky comp.os.os2.advocacy:10280 comp.os.os2.misc:39382