Hello Friends,
I am writing a disk encryption filter driver, so my plan is to encrypt the whole disk including
MBR, Partition table also. My driver gets loaded after disk driver. I having a doubt about the initial
access to the disk. Does disk driver and other initial driver gets loaded using BIOS functions ?
( or does BIOS is used for accessing the disk till the disk driver is not loaded ?).
Thanks for the help
Ashish
You can not encrypt the entrie disk or else the BIOS will not be able to
boot it.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Amit Gorantivar
Sent: Wednesday, August 02, 2000 8:59 AM
To: File Systems Developers
Subject: [ntfsd] Doubt regarding BIOS…
Hello Friends,
I am writing a disk encryption filter driver, so my plan is to encrypt
the whole disk including
MBR, Partition table also. My driver gets loaded after disk driver. I
having a doubt about the initial
access to the disk. Does disk driver and other initial driver gets loaded
using BIOS functions ?
( or does BIOS is used for accessing the disk till the disk driver is not
loaded ?).
Thanks for the help
Ashish
Yes i doubt this, so i am planning to add the encryption and decryption capabilities to the bios.
so it will be able to boot. But my problem is I don’t know till what time NT uses the BIOS so it
get loaded properly.
thanks
Maliye
-----Original Message-----
From: Jamey Kirby
To: File Systems Developers
Date: Wednesday, August 02, 2000 6:11 PM
Subject: [ntfsd] RE: Doubt regarding BIOS…
You can not encrypt the entrie disk or else the BIOS will not be able to boot it.
Jamey
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com]On Behalf Of Amit Gorantivar
Sent: Wednesday, August 02, 2000 8:59 AM
To: File Systems Developers
Subject: [ntfsd] Doubt regarding BIOS…
Hello Friends,
I am writing a disk encryption filter driver, so my plan is to encrypt the whole disk including
MBR, Partition table also. My driver gets loaded after disk driver. I having a doubt about the initial
access to the disk. Does disk driver and other initial driver gets loaded using BIOS functions ?
( or does BIOS is used for accessing the disk till the disk driver is not loaded ?).
Thanks for the help
Ashish
>access to the disk. Does disk driver and other initial driver gets loaded
using
BIOS functions ?
( or does BIOS is used for accessing the disk till the disk driver is not
loaded ?).
BIOS is used only by NTLDR - and IIRC on early stages even by it.
NT has (had?) a requirement that, if your boot disk is SCSI, the SCSI
miniport
which handles the boot disk must be copied to the root directory of the boot
drive under the name NTBootDD.sys. This is done automatically by the setup
process.
NTLDR has the SCSIPORT exports and looks like NTBootDD.sys is bound to
them the same way as the SCSI miniport is bound in the running OS.
This looks rather suspicious. I suspect that even NTLDR does not use BIOS
for
disk access in the later stages - when loading boot drivers+kernel+HAL+NLS
tables+SYSTEM registry, for instance. Looks like even NTLDR uses BIOS only
on the earliest stage.
If one will look inside the NTLDR image - it contains 2 parts - the stupid
binary
code without any headers + the PE part.
I suspect the boot process is the following:
Certainly, only people from MS here can clarify more.
Max
Thanks Max and everybody,
In fact we have the Expanssion BIOS developed which takes control over the
normal BIOS and traps all the read/write requests going through the BIOS.
This Expanssion BIOS also performs the encryption/decryption on these
requests.
Till now we were under the impression that all the read/write requests going
to the disk will go through BIOS before NT disk driver is loaded which
doesn’t seem to be true.
Now I want to know is there any way to trap the read/write requests to the
disk after the BIOS looses control and before NT Disk driver is loaded ? or
can we work around this problem by not encrypting some part of the hard disk
?
Thanks and Regards
Maliye
-----Original Message-----
From: Maxim S. Shatskih
To: File Systems Developers
Date: Thursday, August 03, 2000 3:26 PM
Subject: [ntfsd] Re: Doubt regarding BIOS…
>>access to the disk. Does disk driver and other initial driver gets loaded
>using
>>BIOS functions ?
>>( or does BIOS is used for accessing the disk till the disk driver is not
>>loaded ?).
>
>
>BIOS is used only by NTLDR - and IIRC on early stages even by it.
>NT has (had?) a requirement that, if your boot disk is SCSI, the SCSI
>miniport
>which handles the boot disk must be copied to the root directory of the
boot
>drive under the name NTBootDD.sys. This is done automatically by the setup
>process.
>NTLDR has the SCSIPORT exports and looks like NTBootDD.sys is bound to
>them the same way as the SCSI miniport is bound in the running OS.
>This looks rather suspicious. I suspect that even NTLDR does not use BIOS
>for
>disk access in the later stages - when loading boot drivers+kernel+HAL+NLS
>tables+SYSTEM registry, for instance. Looks like even NTLDR uses BIOS only
>on the earliest stage.
>If one will look inside the NTLDR image - it contains 2 parts - the stupid
>binary
>code without any headers + the PE part.
>
>I suspect the boot process is the following:
>- NTLDR is installed on the disk only by NT setup - either by installation
>or by
>“repair system files” feature.
>- this installation retrieves the sector numbers of the whole NTLDR (by
>FSCTL_GET_RETRIEVAL_POINTERS possibly) and writes the sector
>numbers somewhere to NTLDR starting part.
>- the first sector of NTLDR is written to the boot block.
>- the boot block loads the first part of the NTLDR using int13 and the
>sector
>map described above.
>- the first part of NTLDR is smart enough to load its own PE part +
>NTBootDD.sys and link them together. I also suspect the boot menu is shown
>by it - there are still ways to DOS and other loaders like LILO from this
>stage.
>I suspect the CPU is in real mode at this time.
>- then the PE part of NTLDR (which obviously executes in 32bit flat
>protected
>mode, maybe with paging enabled) loads the kernel+HAL+boot drivers+NLS
>tables+SYSTEM registry bunch and transfers control to kernel image entry
>point, passing some “loader block” there.
>- the kernel is obviously loaded at the start of extended memory - 1MB
>physical. Its base is 0x80100000 in the running OS - and 0x80000000-
>0xa0000000 region is directly mapped to first 512MB physical using the 4M
>Pentium pages (sometimes - depends on memory size - must be >32MB on
>NT4 - and CPU type). Helen Custer also noticed than a) NT was first
designed
>for MIPS b) MIPS has the 3rd gigabyte virtual mapped to 1st gigabyte
>physical
>in read/write-kernel-only mode. This mapping is hardwired to the MIPS CPU -
>cannot be altered.
>So, this is logical that x86 NT also uses this.
>- the HAL is loaded somewhere in the conventional DOS memory below the
>kernel.
>- who enables paging? NTLDR or the kernel? This question is still open.
IMHO
>NTLDR - the kernel’s entry point must be called with the kernel image
having
>proper base of 0x80100000. This is impossible without paging.
>
>Certainly, only people from MS here can clarify more.
>
> Max
>
>
>—
>You are currently subscribed to ntfsd as: amitg@i3-micro.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
> Now I want to know is there any way to trap the read/write requests to the
disk after the BIOS looses control and before NT Disk driver is loaded ?
or
Don’t know. Disk filtering can help.
Max
I rewritten the disk performance monitor driver with the capabilities of
enc/decryption.
But the main problem is it loads after the disk driver is loaded. my plan
was to encrypt
the whole hardisk including my driver and every thing. But this bios this
doesn’t solving
my problem completelly. is there any idea to solve this.
Thanks
maliye
-----Original Message-----
From: Maxim S. Shatskih
To: File Systems Developers
Date: Thursday, August 03, 2000 4:18 PM
Subject: [ntfsd] Re: Doubt regarding BIOS…
>> Now I want to know is there any way to trap the read/write requests to
the
>> disk after the BIOS looses control and before NT Disk driver is loaded ?
>or
>
>Don’t know. Disk filtering can help.
>
> Max
>
>
>—
>You are currently subscribed to ntfsd as: amitg@i3-micro.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>
Maybe replace SCSIPORT.SYS?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Amit Gorantivar
Sent: Thursday, August 03, 2000 6:56 AM
To: File Systems Developers
Subject: [ntfsd] Re: Doubt regarding BIOS…Thanks Max and everybody,
In fact we have the Expanssion BIOS developed which takes control over the
normal BIOS and traps all the read/write requests going through the BIOS.
This Expanssion BIOS also performs the encryption/decryption on these
requests.Till now we were under the impression that all the read/write
requests going
to the disk will go through BIOS before NT disk driver is loaded which
doesn’t seem to be true.Now I want to know is there any way to trap the read/write requests to the
disk after the BIOS looses control and before NT Disk driver is
loaded ? or
can we work around this problem by not encrypting some part of
the hard disk
?Thanks and Regards
Maliye-----Original Message-----
From: Maxim S. Shatskih
> To: File Systems Developers
> Date: Thursday, August 03, 2000 3:26 PM
> Subject: [ntfsd] Re: Doubt regarding BIOS…
>
>
> >>access to the disk. Does disk driver and other initial driver
> gets loaded
> >using
> >>BIOS functions ?
> >>( or does BIOS is used for accessing the disk till the disk
> driver is not
> >>loaded ?).
> >
> >
> >BIOS is used only by NTLDR - and IIRC on early stages even by it.
> >NT has (had?) a requirement that, if your boot disk is SCSI, the SCSI
> >miniport
> >which handles the boot disk must be copied to the root directory of the
> boot
> >drive under the name NTBootDD.sys. This is done automatically by
> the setup
> >process.
> >NTLDR has the SCSIPORT exports and looks like NTBootDD.sys is bound to
> >them the same way as the SCSI miniport is bound in the running OS.
> >This looks rather suspicious. I suspect that even NTLDR does not use BIOS
> >for
> >disk access in the later stages - when loading boot
> drivers+kernel+HAL+NLS
> >tables+SYSTEM registry, for instance. Looks like even NTLDR uses
> BIOS only
> >on the earliest stage.
> >If one will look inside the NTLDR image - it contains 2 parts -
> the stupid
> >binary
> >code without any headers + the PE part.
> >
> >I suspect the boot process is the following:
> >- NTLDR is installed on the disk only by NT setup - either by
> installation
> >or by
> >“repair system files” feature.
> >- this installation retrieves the sector numbers of the whole NTLDR (by
> >FSCTL_GET_RETRIEVAL_POINTERS possibly) and writes the sector
> >numbers somewhere to NTLDR starting part.
> >- the first sector of NTLDR is written to the boot block.
> >- the boot block loads the first part of the NTLDR using int13 and the
> >sector
> >map described above.
> >- the first part of NTLDR is smart enough to load its own PE part +
> >NTBootDD.sys and link them together. I also suspect the boot
> menu is shown
> >by it - there are still ways to DOS and other loaders like LILO from this
> >stage.
> >I suspect the CPU is in real mode at this time.
> >- then the PE part of NTLDR (which obviously executes in 32bit flat
> >protected
> >mode, maybe with paging enabled) loads the kernel+HAL+boot drivers+NLS
> >tables+SYSTEM registry bunch and transfers control to kernel image entry
> >point, passing some “loader block” there.
> >- the kernel is obviously loaded at the start of extended memory - 1MB
> >physical. Its base is 0x80100000 in the running OS - and 0x80000000-
> >0xa0000000 region is directly mapped to first 512MB physical using the 4M
> >Pentium pages (sometimes - depends on memory size - must be >32MB on
> >NT4 - and CPU type). Helen Custer also noticed than a) NT was first
> designed
> >for MIPS b) MIPS has the 3rd gigabyte virtual mapped to 1st gigabyte
> >physical
> >in read/write-kernel-only mode. This mapping is hardwired to the
> MIPS CPU -
> >cannot be altered.
> >So, this is logical that x86 NT also uses this.
> >- the HAL is loaded somewhere in the conventional DOS memory below the
> >kernel.
> >- who enables paging? NTLDR or the kernel? This question is still open.
> IMHO
> >NTLDR - the kernel’s entry point must be called with the kernel image
> having
> >proper base of 0x80100000. This is impossible without paging.
> >
> >Certainly, only people from MS here can clarify more.
> >
> > Max
> >
> >
> >—
> >You are currently subscribed to ntfsd as: amitg@i3-micro.com
> >To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> >
> >
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
hail,
NTLDR has the SCSIPORT exports and looks like NTBootDD.sys is bound to
them the same way as the SCSI miniport is bound in the running OS.
This looks rather suspicious. I suspect that even NTLDR does not use BIOS
for
disk access in the later stages - when loading boot drivers+kernel+HAL+NLS
tables+SYSTEM registry, for instance. Looks like even NTLDR uses BIOS only
on the earliest stage.
Does this really means (as i suppose) NTLDR uses low-level IO commands
to r/w hdd by accessing hdd-controller directly? I just am not sure for
100% :T
I suspect the boot process is the following:
- NTLDR is installed on the disk only by NT setup - either by installation
or by
“repair system files” feature.- this installation retrieves the sector numbers of the whole NTLDR (by
FSCTL_GET_RETRIEVAL_POINTERS possibly) and writes the sector
numbers somewhere to NTLDR starting part.- the first sector of NTLDR is written to the boot block.
- the boot block loads the first part of the NTLDR using int13 and the
sector
map described above.- the first part of NTLDR is smart enough to load its own PE part +
NTBootDD.sys and link them together. I also suspect the boot menu is shown
by it - there are still ways to DOS and other loaders like LILO from this
stage.
one interesting link (Exploring the Windows NT boot sequence)
http://www.elementkjournals.com/ewn/9312/ewn30021.htm
says that :
NTLDR is a special program Microsoft includes with Windows NT. When the
system first loads NTLDR, the memory of the machine is still in real mode,
which uses segments and offsets.
NTLDRs first task is to switch the memory into 32-bit flat mode. Once
NTLDR accomplishes that, it initializes the appropriate mini file
system. Mini file systems are special versions of the FAT, HPFS, and NTFS
file systems. The mini file systems are part of the NTLDR module.
So, does NTLDRs mini-fs-drivers really uses INs and OUTs ?
progLammer
NTLDR and early stages of system initialization in NT itself use INT13H
calls. Also, bootdd.sys is only used if the boot.ini file uses the “scsi()”
or “signature()” syntax to specify the OS location - if you use “multi()”
syntax, then NT initialisation continues to use INT13 calls to read the disk
all the way through loading the boot drivers and initial PnP enumeration and
only switches to using the loaded SCSI driver when this is done.
Simon Graham
Stratus Computer
-----Original Message-----
From: Saulius Krasuckas [mailto:Saulius.Krasuckas@ff.vu.lt]
Sent: Friday, August 04, 2000 1:28 AM
To: File Systems Developers
Subject: [ntfsd] Re: Doubt regarding BIOS…
hail,
NTLDR has the SCSIPORT exports and looks like NTBootDD.sys is bound to
them the same way as the SCSI miniport is bound in the running OS.
This looks rather suspicious. I suspect that even NTLDR does not use BIOS
for
disk access in the later stages - when loading boot drivers+kernel+HAL+NLS
tables+SYSTEM registry, for instance. Looks like even NTLDR uses BIOS only
on the earliest stage.
Does this really means (as i suppose) NTLDR uses low-level IO commands
to r/w hdd by accessing hdd-controller directly? I just am not sure for
100% :T
I suspect the boot process is the following:
- NTLDR is installed on the disk only by NT setup - either by installation
or by
“repair system files” feature.- this installation retrieves the sector numbers of the whole NTLDR (by
FSCTL_GET_RETRIEVAL_POINTERS possibly) and writes the sector
numbers somewhere to NTLDR starting part.- the first sector of NTLDR is written to the boot block.
- the boot block loads the first part of the NTLDR using int13 and the
sector
map described above.- the first part of NTLDR is smart enough to load its own PE part +
NTBootDD.sys and link them together. I also suspect the boot menu is shown
by it - there are still ways to DOS and other loaders like LILO from this
stage.
one interesting link (Exploring the Windows NT boot sequence)
http://www.elementkjournals.com/ewn/9312/ewn30021.htm
says that :
NTLDR is a special program Microsoft includes with Windows NT. When the
system first loads NTLDR, the memory of the machine is still in real mode,
which uses segments and offsets.
NTLDRs first task is to switch the memory into 32-bit flat mode. Once
NTLDR accomplishes that, it initializes the appropriate mini file
system. Mini file systems are special versions of the FAT, HPFS, and NTFS
file systems. The mini file systems are part of the NTLDR module.
So, does NTLDRs mini-fs-drivers really uses INs and OUTs ?
progLammer
You are currently subscribed to ntfsd as: xxxxx@stratus.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> NTLDR accomplishes that, it initializes the appropriate mini file
system. Mini file systems are special versions of the FAT, HPFS, and NTFS
file systems. The mini file systems are part of the NTLDR module.So, does NTLDRs mini-fs-drivers really uses INs and OUTs ?
Surely not. FS - even miniFS - relies on underlying disk driver to do INs
and
OUTs.
Thus the need in NTBootDD.sys - your boot device can be some weird SCSI
controller, for instance. Surely NTLDR cannot contain the code for all
possible
SCSI HBAs.
Max
Maxim, once you wrote:
> This looks rather suspicious. I suspect that even NTLDR does not use BIOS
> for
> disk access in the later stages - when loading boot drivers+kernel+HAL+NLS
> tables+SYSTEM registry, for instance. Looks like even NTLDR uses BIOS only
> on the earliest stage.
. NTLDR does not use BIOS (in the later stages)
. it uses something else (in the later stages)
one interesting link (Exploring the Windows NT boot sequence)
says that :NTLDRs first task is to switch the memory into 32-bit flat mode. Once
NTLDR accomplishes that, it initializes the appropriate mini file
system. Mini file systems are special versions of the FAT, HPFS, and NTFS
file systems. The mini file systems are part of the NTLDR module.
after you wrote:
> So, does NTLDRs mini-fs-drivers really uses INs and OUTs ?
Surely not. FS - even miniFS - relies on underlying disk driver to do INs
and
OUTs.
.NTLDR uses ide disk driver (or NTBootDD.SYS for scsi devices)
ok, i understood, and sorry - i’m profane in NT 
Thus the need in NTBootDD.sys - your boot device can be some weird SCSI
controller, for instance. Surely NTLDR cannot contain the code for all
possible SCSI HBAs.
ok, agree… but:
On Fri, 4 Aug 2000, Graham, Simon wrote:
NTLDR and early stages of system initialization in NT itself use INT13H
calls. Also, bootdd.sys is only used if the boot.ini file uses the “scsi()”
or “signature()” syntax to specify the OS location - if you use “multi()”
syntax, then NT initialisation continues to use INT13 calls to read the disk
all the way through loading the boot drivers and initial PnP enumeration and
only switches to using the loaded SCSI driver when this is done.
So, Simon says “NT … continues to use INT13 calls”
And Maxim says “NTLDR relies on underlying disk driver”
Which one of you, guys, are right? Maybe both - have i missed something?
Or maybe underlying disk driver uses only INT13 by self - not IN/OUT
operations to read disk?
sorry for disturbing, but i really wanted to clear out the way NT-booting
goes…
proglammer
Well, we’re both right of course 
Actually, it depends on the way the boot.ini file is coded. If the boot line
uses the multi() syntax, for example:
multi(0)disk(0)rdisk(0)partition(1)\WINNT=“Microsoft Windows 2000 Server”
/fastdetect
then even if the device is a SCSI disk, NTLDR and early NT initialization
uses INT13 calls (and your SCSI adapter has to have BIOS option ROM support
for this).
On the other hand, if you use the scsi() syntax, NTLDR loads ntbootdd.sys
(which is just a copy of the standard device driver for your scsi adapter)
and then uses it to read the disk…
/simgr
-----Original Message-----
From: Saulius Krasuckas [mailto:Saulius.Krasuckas@ff.vu.lt]
Sent: Sunday, August 06, 2000 4:18 PM
To: File Systems Developers
Subject: [ntfsd] Re: Doubt regarding BIOS…
Maxim, once you wrote:
> This looks rather suspicious. I suspect that even NTLDR does not use
BIOS
> for
> disk access in the later stages - when loading boot
drivers+kernel+HAL+NLS
> tables+SYSTEM registry, for instance. Looks like even NTLDR uses BIOS
only
> on the earliest stage.
. NTLDR does not use BIOS (in the later stages)
. it uses something else (in the later stages)
one interesting link (Exploring the Windows NT boot sequence)
says that :NTLDRs first task is to switch the memory into 32-bit flat mode. Once
NTLDR accomplishes that, it initializes the appropriate mini file
system. Mini file systems are special versions of the FAT, HPFS, and NTFS
file systems. The mini file systems are part of the NTLDR module.
after you wrote:
> So, does NTLDRs mini-fs-drivers really uses INs and OUTs ?
Surely not. FS - even miniFS - relies on underlying disk driver to do
INs
and
OUTs.
.NTLDR uses ide disk driver (or NTBootDD.SYS for scsi devices)
ok, i understood, and sorry - i’m profane in NT
Thus the need in NTBootDD.sys - your boot device can be some weird SCSI
controller, for instance. Surely NTLDR cannot contain the code for all
possible SCSI HBAs.
ok, agree… but:
On Fri, 4 Aug 2000, Graham, Simon wrote:
NTLDR and early stages of system initialization in NT itself use INT13H
calls. Also, bootdd.sys is only used if the boot.ini file uses the
“scsi()”
or “signature()” syntax to specify the OS location - if you use “multi()”
syntax, then NT initialisation continues to use INT13 calls to read the
disk
all the way through loading the boot drivers and initial PnP enumeration
and
only switches to using the loaded SCSI driver when this is done.
So, Simon says “NT … continues to use INT13 calls”
And Maxim says “NTLDR relies on underlying disk driver”
Which one of you, guys, are right? Maybe both - have i missed something?
Or maybe underlying disk driver uses only INT13 by self - not IN/OUT
operations to read disk?
sorry for disturbing, but i really wanted to clear out the way NT-booting
goes…
proglammer
You are currently subscribed to ntfsd as: xxxxx@stratus.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Hello Friends Thanks for the great help in this matter.
I varified the sequence, and it works in the same way as Simon summaries .
Thanks again
Maliye
-----Original Message-----
From: Graham, Simon
To: File Systems Developers
Date: Monday, August 07, 2000 4:17 PM
Subject: [ntfsd] Re: Doubt regarding BIOS…
>Well, we’re both right of course
>
>Actually, it depends on the way the boot.ini file is coded. If the boot
line
>uses the multi() syntax, for example:
>
>multi(0)disk(0)rdisk(0)partition(1)\WINNT=“Microsoft Windows 2000 Server”
>/fastdetect
>
>then even if the device is a SCSI disk, NTLDR and early NT initialization
>uses INT13 calls (and your SCSI adapter has to have BIOS option ROM support
>for this).
>
>On the other hand, if you use the scsi() syntax, NTLDR loads ntbootdd.sys
>(which is just a copy of the standard device driver for your scsi adapter)
>and then uses it to read the disk…
>
>/simgr
>
>-----Original Message-----
>From: Saulius Krasuckas [mailto:Saulius.Krasuckas@ff.vu.lt]
>Sent: Sunday, August 06, 2000 4:18 PM
>To: File Systems Developers
>Subject: [ntfsd] Re: Doubt regarding BIOS…
>
>
>Maxim, once you wrote:
>
>> > This looks rather suspicious. I suspect that even NTLDR does not use
>BIOS
>> > for
>> > disk access in the later stages - when loading boot
>drivers+kernel+HAL+NLS
>> > tables+SYSTEM registry, for instance. Looks like even NTLDR uses BIOS
>only
>> > on the earliest stage.
>
> . NTLDR does not use BIOS (in the later stages)
> . it uses something else (in the later stages)
>
>> one interesting link (Exploring the Windows NT boot sequence)
>> says that :
>>
>> NTLDRs first task is to switch the memory into 32-bit flat mode. Once
>> NTLDR accomplishes that, it initializes the appropriate mini file
>> system. Mini file systems are special versions of the FAT, HPFS, and NTFS
>> file systems. The mini file systems are part of the NTLDR module.
>
>after you wrote:
>
>> > So, does NTLDRs mini-fs-drivers really uses INs and OUTs ?
>>
>> Surely not. FS - even miniFS - relies on underlying disk driver to do
>INs
>> and
>> OUTs.
>
> .NTLDR uses ide disk driver (or NTBootDD.SYS for scsi devices)
>
> ok, i understood, and sorry - i’m profane in NT
>
>> Thus the need in NTBootDD.sys - your boot device can be some weird SCSI
>> controller, for instance. Surely NTLDR cannot contain the code for all
>> possible SCSI HBAs.
>
> ok, agree… but:
>
>On Fri, 4 Aug 2000, Graham, Simon wrote:
>
>> NTLDR and early stages of system initialization in NT itself use INT13H
>> calls. Also, bootdd.sys is only used if the boot.ini file uses the
>“scsi()”
>> or “signature()” syntax to specify the OS location - if you use “multi()”
>> syntax, then NT initialisation continues to use INT13 calls to read the
>disk
>> all the way through loading the boot drivers and initial PnP enumeration
>and
>> only switches to using the loaded SCSI driver when this is done.
>
>
> So, Simon says “NT … continues to use INT13 calls”
> And Maxim says “NTLDR relies on underlying disk driver”
>
> Which one of you, guys, are right? Maybe both - have i missed something?
> Or maybe underlying disk driver uses only INT13 by self - not IN/OUT
>operations to read disk?
>
>sorry for disturbing, but i really wanted to clear out the way NT-booting
>goes…
>
>proglammer
>
>
>—
>You are currently subscribed to ntfsd as: xxxxx@stratus.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>—
>You are currently subscribed to ntfsd as: amitg@i3-micro.com
>To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>