From: Ed Beroset 
Subject: Re: Code in Boot Sector
Scott McNay wrote:
> 
>  *** Tim Hutzler wrote in a message to Scott Mcnay:
> 
> TH> Actually, BIOS is separate from the boot up and POST code,
> 
> In theory, yes.  In practice, you'll find them stuck in the same piece of
> silicon.  Also, in practice, they're not very separate at all, since the 
POST
> code initializes the data areas and does the initial configuration and
> performs minimal tests of function; without the POST doing this, the BIOS
> fuctions would not be able to function.  Similar for the boot code; the 
oot
> code would not be able to function without the BIOS proper, and the BIOS
> proper would be useless without the boot code loading up something that
> actually does something worthwhile.
> 
> Nowadays, the POST is a loader for the BIOS and the boot loader, which in 
turn
> loads up the OS, which in turn maps the BIOS out of the memory space. 
(thanks
> for the help, now scram!!) 
I'd agree with most of that except that the POST isn't really a loader
for the BIOS.  Folks in the BIOS business refer to the whole thing as
"BIOS" and differentiate the pieces as "POST" and "runtime."  No doubt
you'll recall that POST is an acronym for Power On Self-Test.  That used
to be a pretty simple set of functions, but on modern machines it
includes such esoteric stuff as configuring PCI, identifying the type
and number of IDE and/or SCSI drives attached, doing the first pass at
PnP device enumeration and setup and setting up power management
(especially on a laptop).  All that's in addition to the stuff that
needs to be tested, like memory, interrupt controller, DMA controller,
etc.  
The "runtime" section of the BIOS is the part that still must be
available when the OS loads.  For example, memory tests aren't used
directly by an operating system, so they're part of POST, while disk
interrupt servicing is required by the OS (at least during loading).
> (This discussion is probably more for the benefit of the lurkers here... ;)
Probably, but we can all learn something new, I bet.
> TH> However, there are BIOS areas that an operating doesn't mess
> TH> with, and that's because it is very specific to the
> TH> hardware, ie.
> TH> a particular motherboard chip set, or video chep set, or a
> TH> non-IDE interface like SCSI.
> 
> In the case of Windows 95, this is as untrue as can be managed;  If you 
ook
> in the device manager, you'll see that on most computers, most devices are
> recognized by name.  Win95 may not handle certain different devices
> differently, but it could; it is up to the driver author.
If you dig a little deeper, you'll find that some of those driver
authors cheated and are using DPMI services to call real mode
interrupts.  It's ugly and it's slow, but it's a very quick way to get a
driver shipping.  I imagine there are fewer of those ugly hacks out
there than there were in August 1995 when Win95 was first shipping.
> SM>The boot virus protection interferes with certain programs, 
> 
> Actually, it just occurred to me that if the BIOS manufacturers had an Auto
> feature, that would be best, so that if floppy boots are disabled, then the
> boot sector check would be disabled also, and vice versa.  
It's better not to be "Auto" in the way you describe.  If I want maximum
protection, I'd want floppy boots disabled and boot sector checking
enabled?  
> You'd probably STILL have to disable it for Win95 installation, though.
If, during the course of installation of any OS, one is going to rewrite
the MBR (e.g. repartitioning drives, installing new multi-OS loaders,
etc.) one should probably have the feature disabled.  Win95 in
particular does not play well with others and will write to the MBR even
when there isn't a real reason to do so.  Anyway, that's been my
experience, but I haven't installed Win95 on anything for quite some
time, so maybe that's changed.
Ed
-!-
---
---------------