If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#201
|
|||
|
|||
Boot.ini question
Rod Speed wrote:
Just you with a problem with basic english. Now this together with the following is almost funny... Its obvious what 'it varys' means. ge |
#202
|
|||
|
|||
Boot.ini question
Hi Rod.
I believe you got something wrong, but I cannot find where exactly is the problem. I guess you are missing a piece of the puzzle. Please take a moment to check your points about the PC boot process (going through INT 19h, MBR, active partition, boot record code, then "booting the OS".) OTOH, if you are trying to make a point based purely on published MS' position, please ignore my post. In , Rod Speed va escriu What is true? That few if any current bios can boot a logical drive in an extended dos partition. I'll not put "I disagree" since you do not care. I'll not put "Wrong" (or worse) as you'll, since that is not my conception of discussion. Yet I feel this is incorrect. If you want to do that, you need to use ntldr or another loader to do that because the bios cannot do that. It is well known it can be done with plain DOS (with customized bootcode in the MBR, as I described), which is NOT using a sophisticated boot loader. almost no current bios allows those to be booted by the bios. Because that is not BIOS' job, Why not when the bios can boot any physical drive it can see. Because BIOS sees "physical drives", and it sees them as continuum (LBA or CHS organized) of sectors, without disruption. It does not know about partitions, slices or anything finely grained (and much less extended or logical partitions, or filesystems, obviously). EFI, when considered as BIOS' successor in interest, will. But practice shows the need/interest for it is low. rather the one for the code inside the boot records (MBR and the one for the active partition); Thats just the way ntldr does it. It doesnt have to be done that way. That is factually correct (for example, the original code for booting 386*BSD 0.0 did it another way). Yet it is _also_ the way it is done by every MS operating system to date on the PC architecture (well, I have doubt about Xenix System III, though.) And the vast majority of the current OSes on PC. ntldr allowed booting of physical drives which could not be specified in the bios as what the user wanted to boot from too, other than the C: drive, with older bios where you couldnt specify other than the C: to boot from. Hmmm. I believe I understand where you are heading. More or less, you see the Ntldr solution as superior to the MBR+bootrecord way of booting an OS (while still using these piece). Yes, it makes sense to view it that way. Yet, it is an architectural (higher level) view of the picture. Below the scene, there is still a MBR code and so on, and you really can achieve the same effect using other "tricks", *without* making any assumption about the BIOS support. There is no technical reason why the bios could not allow the user to specify a logical drive in an extended dos partition to boot from, it just isnt what is possible with most if any bios. ??? I do not know of ANY bios that allow the user to specify which _partition()_ one wants to boot NT from. As we were speaking about, BIOS stands at the _rdisk()_ level, that's one level higher. MBR partition scheme is NOT firmware dependant (only the 55AAh signature is), it is a purely software concept (introduced with DOS 2 / IBM XT), and it is a damned good/clever idea: without it, we could only have ONE operating system on a given box (or perhaps one per bootable drive, assuming BIOS support to select among the available). if there is code at the beginning of the extended partition(s) snip Irrelevant to what the whole point of the ntldr system was. Yes :-) good to agree with you on this one. Big snip; now we were about Boot.ini In fact the multi structure can be used for some SCSI drives, as well as ATA drives. This requires so-called "BIOS support" to be provided by the SCSI hardware (adapter usually). The multi and scsi protocols arent identical, for a reason. Quite true ;-). Multi() uses BIOS calls, using protected-to-real mode switches to call Int 13h, something that is impossible to do at a later stage (when the kernel has been started). Scsi() OTOH uses (normally) the same driver as will be used in normal operation. This in turn requires Ntldr to fake the kernel, at least the storage IRP stack and the most basic resources management, including memory allocation; plus starting and stoping the driver. The fact there are two indices is a given input, not a decision of the team. That sentence makes no sense. The ARC paths are of the form xxx(X)disk(Y)rdisk(Z)partition(N). With multi(X), no meaning is given to either X or Y, they are always 0. multi(0) has to be kept for coherency reasons, but why using disk(0)? My answer, because ARC (the preexisting MIPS standard) specified the general syntax. Using ARC paths including for i386 also was. Neither does that. I mean, Cutler's team chose to use ARC paths at Ntldr/Boot.ini level, when they could perfectly have used something else, perhaps the same strings used in the NT kernel (HarddiskZ\PartitionN), it would have been much less confusion for anybody. N could also have been defined clearly as the BIOS drive number, And there are downsides with that approach, most obviously they arent as obvious to the user. Very good point, and very probably the reason behind the text published by MS. However, the other formulations also have downside. For example, "the ordinal number of the drive" may appear faulty if the drive is not properly declared in the BIOS setup. snip Nothing grey about the MS statement that the rdisk() param is the ordinal of the drive on the controller. I did not find a clear statement from them that the rdisk() parameter is the BIOS drive number - 80h. Because it isnt. Funny. The actual code DOES that computation (of course one may worry which other it could ever do.) "It isn't" because MS does not say it is: that's what I called "grey", or the usual "undocumented": it is this way, but since MS did not document it, they are allowed to change this in the future, without backfire about possible incompatibilities. Antoine |
#203
|
|||
|
|||
Boot.ini question
Gerhard Fiedler wrote
Rod Speed wrote Just you with a problem with basic english. Now this together with the following is almost funny... Its obvious what 'it varys' means. Pathetic, really. |
#204
|
|||
|
|||
Boot.ini question
Antoine Leca wrote
Rod Speed wrote I believe you got something wrong, but I cannot find where exactly is the problem. Then you dont have any basis for your belief. I guess you are missing a piece of the puzzle. Or you are wrong. You certainly about whether ntldr is a 'reduced' OS or not. Please take a moment to check your points about the PC boot process (going through INT 19h, MBR, active partition, boot record code, then "booting the OS".) No thanks, already did that in response to ****nert's response. OTOH, if you are trying to make a point based purely on published MS' position, No I'm not. I havent seen any evidence that there is any problem with what MS has published except that the wording is a bit too vague in spots, but thats typical of MS. I've seen no evidence that the rdisk() parameter is other than the ordinal of the drive on the controller in the sense of the master/slave relationship of the drives on a particular controller except with Timmy's completely ****ed bios. please ignore my post. What is true? That few if any current bios can boot a logical drive in an extended dos partition. I'll not put "I disagree" since you do not care. I'll not put "Wrong" (or worse) as you'll, since that is not my conception of discussion. Yet I feel this is incorrect. Then nominate a bios that can do that without modified MBR boot code or some form of loader. Its no news that it can be done with a loader, ntldr manages that fine. If you want to do that, you need to use ntldr or another loader to do that because the bios cannot do that. It is well known it can be done with plain DOS (with customized bootcode in the MBR, as I described), That is a customised MBR boot code, NOT the bios. which is NOT using a sophisticated boot loader. Never said that doing THAT requires a sophisticated loader. Booting a member of the NT/2K/XP family does tho. almost no current bios allows those to be booted by the bios. Because that is not BIOS' job, Why not when the bios can boot any physical drive it can see. Because BIOS sees "physical drives", and it sees them as continuum (LBA or CHS organized) of sectors, without disruption. Thats just the way its currently done. In the past it could only boot from the first physical drive, or the floppy, and later the cdrom drive was added to the list of possibilitys. It does not know about partitions, slices or anything finely grained (and much less extended or logical partitions, or filesystems, obviously). There's no technical reason why the bios cant understand partitions and allow the user to select a partition to boot. And the big advantage of giving the bios that capability is that you can boot any partition on any drive if a drive dies etc. EFI, when considered as BIOS' successor in interest, will. But practice shows the need/interest for it is low. Irrelevant to whether its possible for a bios to do that. rather the one for the code inside the boot records (MBR and the one for the active partition); Thats just the way ntldr does it. It doesnt have to be done that way. That is factually correct (for example, the original code for booting 386*BSD 0.0 did it another way). Yet it is _also_ the way it is done by every MS operating system to date on the PC architecture (well, I have doubt about Xenix System III, though.) And the vast majority of the current OSes on PC. Irrelevant to what can be done. ntldr allowed booting of physical drives which could not be specified in the bios as what the user wanted to boot from too, other than the C: drive, with older bios where you couldnt specify other than the C: to boot from. Hmmm. I believe I understand where you are heading. More or less, you see the Ntldr solution as superior to the MBR+bootrecord way of booting an OS (while still using these piece). I do however also see it as a rather crude boot manager which has a number of significant deficiencys, particularly having to manually edit the boot.ini or use one of the utes that MS provides to modify the boot.ini, none of which are that elegant to use. And one obvious downside with the ntldr approach is that it doesnt handle drive failure that well either. Booting by the bios can be much more robust on physical drive failure. Yes, it makes sense to view it that way. Yet, it is an architectural (higher level) view of the picture. No it isnt. Below the scene, there is still a MBR code and so on, and you really can achieve the same effect using other "tricks", *without* making any assumption about the BIOS support. You dont have to use ntldr as the primary boot manager if you dont like it. There is no technical reason why the bios could not allow the user to specify a logical drive in an extended dos partition to boot from, it just isnt what is possible with most if any bios. ??? I do not know of ANY bios that allow the user to specify which _partition()_ one wants to boot NT from. Thats why I said that there is no TECHNICAL reason why it cant be done. As we were speaking about, BIOS stands at the _rdisk()_ level, No it doesnt. All the bios can do is boot at the level of the physical drive and the active primary partition on that drive. that's one level higher. No it isnt. MBR partition scheme is NOT firmware dependant (only the 55AAh signature is), it is a purely software concept (introduced with DOS 2 / IBM XT), and it is a damned good/clever idea: without it, we could only have ONE operating system on a given box (or perhaps one per bootable drive, assuming BIOS support to select among the available). But is limited in the sense that it cant boot from a logical drive in an extended dos partition without new code in the MBR etc. Big snip; now we were about Boot.ini In fact the multi structure can be used for some SCSI drives, as well as ATA drives. This requires so-called "BIOS support" to be provided by the SCSI hardware (adapter usually). Sure. The multi and scsi protocols arent identical, for a reason. Quite true ;-). Multi() uses BIOS calls, using protected-to-real mode switches to call Int 13h, something that is impossible to do at a later stage (when the kernel has been started). Scsi() OTOH uses (normally) the same driver as will be used in normal operation. This in turn requires Ntldr to fake the kernel, at least the storage IRP stack and the most basic resources management, including memory allocation; plus starting and stoping the driver. The fact there are two indices is a given input, not a decision of the team. That sentence makes no sense. The ARC paths are of the form xxx(X)disk(Y)rdisk(Z)partition(N). With multi(X), no meaning is given to either X or Y, they are always 0. multi(0) has to be kept for coherency reasons, but why using disk(0)? My answer, because ARC (the preexisting MIPS standard) specified the general syntax. Using ARC paths including for i386 also was. Neither does that. I mean, Cutler's team chose to use ARC paths at Ntldr/Boot.ini level, when they could perfectly have used something else, perhaps the same strings used in the NT kernel (HarddiskZ\PartitionN), it would have been much less confusion for anybody. Sure. N could also have been defined clearly as the BIOS drive number, And there are downsides with that approach, most obviously they arent as obvious to the user. Very good point, and very probably the reason behind the text published by MS. However, the other formulations also have downside. For example, "the ordinal number of the drive" may appear faulty if the drive is not properly declared in the BIOS setup. Sure. snip Nothing grey about the MS statement that the rdisk() param is the ordinal of the drive on the controller. I did not find a clear statement from them that the rdisk() parameter is the BIOS drive number - 80h. Because it isnt. Funny. The actual code DOES that computation (of course one may worry which other it could ever do.) "It isn't" because MS does not say it is: that's what I called "grey", or the usual "undocumented": it is this way, but since MS did not document it, they are allowed to change this in the future, without backfire about possible incompatibilities. I doubt they did it for that reason. |
#205
|
|||
|
|||
Boot.ini question
Rod Speed wrote:
Thats just the way its currently done. In the past it could only boot from the first physical drive, or the floppy, and later the cdrom drive was added to the list of possibilitys. It does not know about partitions, slices or anything finely grained (and much less extended or logical partitions, or filesystems, obviously). There's no technical reason why the bios cant understand partitions and allow the user to select a partition to boot. And the big advantage of giving the bios that capability is that you can boot any partition on any drive if a drive dies etc. Architecturally, what you propose would be a problem. For a BIOS to be able to boot from any partition would require the BIOS to understand file systems. Not just any file system, but every file system that one may use, now and in the future, for the feature to work universally. The BIOS should provide services to the OS and start the boot process. Knowing a files system belongs in the loader and OS. |
#206
|
|||
|
|||
Boot.ini question
craigm wrote
Rod Speed wrote Thats just the way its currently done. In the past it could only boot from the first physical drive, or the floppy, and later the cdrom drive was added to the list of possibilitys. It does not know about partitions, slices or anything finely grained (and much less extended or logical partitions, or filesystems, obviously). There's no technical reason why the bios cant understand partitions and allow the user to select a partition to boot. And the big advantage of giving the bios that capability is that you can boot any partition on any drive if a drive dies etc. Architecturally, what you propose would be a problem. No it wouldnt. The bios would just be doing what you agree can be done by modified code in the MBR and a loader. No reason why that cant be done by the bios instead. Note that I am NOT talking about the full complexity of loading a member of the NT/2K/XP family by the bios, I am JUST talking about allowing the user to specify a logical drive within an extended dos partition as what to boot from in the bios instead of in a boot manager. For a BIOS to be able to boot from any partition would require the BIOS to understand file systems. ALL that is required is what is already done in modified MBR code and loaders. Not just any file system, but every file system that one may use, now and in the future, for the feature to work universally. It doesnt to work universally, just do what is currently done by a loader. The BIOS should provide services to the OS and start the boot process. Knowing a files system belongs in the loader and OS. Doesnt have to be when doing something as basic as booting a partition. |
#207
|
|||
|
|||
Boot.ini question
"Rod Speed" wrote in message
Antoine Leca wrote Rod Speed wrote I believe you got something wrong, but I cannot find where exactly is the problem. Then you dont have any basis for your belief. Or 'maybe' you are just all over the place and can't be caught. I guess you are missing a piece of the puzzle. [SNIP] Please take a moment to check your points about the PC boot process (going through INT 19h, MBR, active partition, boot record code, then "booting the OS".) No thanks, already did that in response to ****nert's response. Mindless repetition was never a problem for you so it more than likely wasn't worth repeating. OTOH, if you are trying to make a point based purely on published MS' position, [SNIP] ... I've seen no evidence that the rdisk() parameter is other than the ordinal of the drive on the controller in the sense of the master/slave relationship of the drives on a particular controller except with Timmy's completely ****ed bios. Any bios that allows just the bootdrive to be changed (interchange the device that is ordinarily device 81h, 82h or 83h with device 80h) is '****ed' in that regard which is every current bios. Either NTLDR checks the ordinal that it translated the rdisk() parameter into against the Master/Slave info supplied by the BIOS s.a. Int 13/AH=48h for that ordinal and it works correctly or it doesn't check it and it ****s up accordingly. That is not any BIOS's fault. That's MS's fault. please ignore my post. Fat chance. What is true? That few if any current bios can boot a logical drive in an extended dos partition. I'll not put "I disagree" since you do not care. I'll not put "Wrong" (or worse) as you'll, since that is not my conception of discussion. Yet I feel this is incorrect. [SNIP] If you want to do that, you need to use ntldr or another loader to do that because the bios cannot do that. It is well known it can be done with plain DOS (with customized bootcode in the MBR, as I described), [SNIP] which is NOT using a sophisticated boot loader. [SNIP] almost no current bios allows those to be booted by the bios. Because that is not BIOS' job, Why not when the bios can boot any physical drive it can see. Because BIOS sees "physical drives", and it sees them as continuum (LBA or CHS organized) of sectors, without disruption. Thats just the way its currently done. In the past it could only boot from the first physical drive, or the floppy, and later the cdrom drive was added to the list of possibilitys. It does not know about partitions, slices or anything finely grained (and much less extended or logical partitions, or filesystems, obviously). [SNIP] EFI, when considered as BIOS' successor in interest, will. But practice shows the need/interest for it is low. [SNIP] rather the one for the code inside the boot records (MBR and the one for the active partition); Thats just the way ntldr does it. It doesnt have to be done that way. That is factually correct (for example, the original code for booting 386*BSD 0.0 did it another way). Yet it is _also_ the way it is done by every MS operating system to date on the PC architecture (well, I have doubt about Xenix System III, though.) And the vast majority of the current OSes on PC. [SNIP] ntldr allowed booting of physical drives which could not be specified in the bios as what the user wanted to boot from too, other than the C: drive, with older bios where you couldnt specify other than the C: to boot from. Hmmm. I believe I understand where you are heading. More or less, you see the Ntldr solution as superior to the MBR+bootrecord way of booting an OS (while still using these piece). [SNIP] Yes, it makes sense to view it that way. Yet, it is an architectural (higher level) view of the picture. [SNIP] Below the scene, there is still a MBR code and so on, and you really can achieve the same effect using other "tricks", *without* making any assumption about the BIOS support. You dont have to use ntldr as the primary boot manager if you dont like it. As if there is any other way to get NT in the air. There is no technical reason why the bios could not allow the user to specify a logical drive in an extended dos partition to boot from, it just isnt what is possible with most if any bios. ??? I do not know of ANY bios that allow the user to specify which _partition()_ one wants to boot NT from. [SNIP] As we were speaking about, BIOS stands at the _rdisk()_ level, No it doesnt. All the bios can do is boot at the level of the physical drive and the active primary partition on that drive. Nonsense. Still as clueless as ever. that's one level higher. [SNIP] MBR partition scheme is NOT firmware dependant (only the 55AAh signature is), it is a purely software concept (introduced with DOS 2 / IBM XT), and it is a damned good/clever idea: without it, we could only have ONE operating system on a given box Nonsense. It's fine to have several OSes on a single partition. (or perhaps one per bootable drive, assuming BIOS support to select among the available). And that too. [SNIP] Big snip; now we were about Boot.ini In fact the multi structure can be used for some SCSI drives, as well as ATA drives. This requires so-called "BIOS support" to be provided by the SCSI hardware (adapter usually). [SNIP] The multi and scsi protocols arent identical, for a reason. Quite true ;-). Multi() uses BIOS calls, using protected-to-real mode switches to call Int 13h, something that is impossible to do at a later stage (when the kernel has been started). Scsi() OTOH uses (normally) the same driver as will be used in normal operation. This in turn requires Ntldr to fake the kernel, at least the storage IRP stack and the most basic resources management, including memory allocation; plus starting and stoping the driver. The fact there are two indices is a given input, not a decision of the team. That sentence makes no sense. The ARC paths are of the form xxx(X)disk(Y)rdisk(Z)partition(N). With multi(X), no meaning is given to either X or Y, they are always 0. multi(0) has to be kept for coherency reasons, but why using disk(0)? My answer, because ARC (the preexisting MIPS standard) specified the general syntax. Using ARC paths including for i386 also was. [SNIP] I mean, Cutler's team chose to use ARC paths at Ntldr/Boot.ini level, when they could perfectly have used something else, perhaps the same strings used in the NT kernel (HarddiskZ\PartitionN), it would have been much less confusion for anybody. [SNIP] N could also have been defined clearly as the BIOS drive number, And there are downsides with that approach, most obviously they arent as obvious to the user. Very good point, and very probably the reason behind the text published by MS. However, the other formulations also have downside. For example, "the ordinal number of the drive" may appear faulty if the drive is not properly declared in the BIOS setup. [SNIP] snip Nothing grey about the MS statement that the rdisk() param is the ordinal of the drive on the controller. I did not find a clear statement from them that the rdisk() parameter is the BIOS drive number - 80h. [SNIP] Funny. The actual code DOES that computation (of course one may worry which other it could ever do.) "It isn't" because MS does not say it is: that's what I called "grey", or the usual "undocumented": it is this way, but since MS did not document it, they are allowed to change this in the future, without backfire about possible incompatibilities. [SNIP] |
#208
|
|||
|
|||
Boot.ini question
Folkert Rienstra wrote
Rod Speed wrote Antoine Leca wrote Rod Speed wrote I believe you got something wrong, but I cannot find where exactly is the problem. Then you dont have any basis for your belief. Or 'maybe' you are just all over the place and can't be caught. Never ever could bull**** its way out of a wet paper bag. No wonder you end up having your mouth frothing rages. I guess you are missing a piece of the puzzle. Please take a moment to check your points about the PC boot process (going through INT 19h, MBR, active partition, boot record code, then "booting the OS".) No thanks, already did that in response to ****nert's response. Mindless repetition was never a problem for you so it more than likely wasn't worth repeating. Never ever could bull**** its way out of a wet paper bag. No wonder you end up having your mouth frothing rages. OTOH, if you are trying to make a point based purely on published MS' position, I've seen no evidence that the rdisk() parameter is other than the ordinal of the drive on the controller in the sense of the master/slave relationship of the drives on a particular controller except with Timmy's completely ****ed bios. Any bios that allows just the bootdrive to be changed (interchange the device that is ordinarily device 81h, 82h or 83h with device 80h) is '****ed' in that regard which is every current bios. Not a ****ing clue, as always. Not a shred of evidence that ANY bios uses the ordinal of the drive in the hard drive boot order list as the rdisk() param with the exception of Timmy's completely ****ed bios, if he isnt actually lying about it. Either NTLDR checks the ordinal that it translated the rdisk() parameter into against the Master/Slave info supplied by the BIOS s.a. Int 13/AH=48h for that ordinal and it works correctly or it doesn't check it and it ****s up accordingly. That is not any BIOS's fault. That's MS's fault. See above. please ignore my post. Fat chance. I mostly ignore you pathetic excuses for trolls. What is true? That few if any current bios can boot a logical drive in an extended dos partition. I'll not put "I disagree" since you do not care. I'll not put "Wrong" (or worse) as you'll, since that is not my conception of discussion. Yet I feel this is incorrect. [SNIP] If you want to do that, you need to use ntldr or another loader to do that because the bios cannot do that. It is well known it can be done with plain DOS (with customized bootcode in the MBR, as I described), [SNIP] which is NOT using a sophisticated boot loader. [SNIP] almost no current bios allows those to be booted by the bios. Because that is not BIOS' job, Why not when the bios can boot any physical drive it can see. Because BIOS sees "physical drives", and it sees them as continuum (LBA or CHS organized) of sectors, without disruption. Thats just the way its currently done. In the past it could only boot from the first physical drive, or the floppy, and later the cdrom drive was added to the list of possibilitys. It does not know about partitions, slices or anything finely grained (and much less extended or logical partitions, or filesystems, obviously). [SNIP] EFI, when considered as BIOS' successor in interest, will. But practice shows the need/interest for it is low. [SNIP] rather the one for the code inside the boot records (MBR and the one for the active partition); Thats just the way ntldr does it. It doesnt have to be done that way. That is factually correct (for example, the original code for booting 386*BSD 0.0 did it another way). Yet it is _also_ the way it is done by every MS operating system to date on the PC architecture (well, I have doubt about Xenix System III, though.) And the vast majority of the current OSes on PC. [SNIP] ntldr allowed booting of physical drives which could not be specified in the bios as what the user wanted to boot from too, other than the C: drive, with older bios where you couldnt specify other than the C: to boot from. Hmmm. I believe I understand where you are heading. More or less, you see the Ntldr solution as superior to the MBR+bootrecord way of booting an OS (while still using these piece). [SNIP] Yes, it makes sense to view it that way. Yet, it is an architectural (higher level) view of the picture. [SNIP] Below the scene, there is still a MBR code and so on, and you really can achieve the same effect using other "tricks", *without* making any assumption about the BIOS support. You dont have to use ntldr as the primary boot manager if you dont like it. As if there is any other way to get NT in the air. That isnt necessarily the PRIMARY boot manager, ****wit. Even someone as stupid as you should be able to work out that its perfectly possible to use a different PRIMARY boot manager and still boot a member of the NT/2K/XP family, if for example you dont like some detail of how ntldr does the boot managing. There is no technical reason why the bios could not allow the user to specify a logical drive in an extended dos partition to boot from, it just isnt what is possible with most if any bios. ??? I do not know of ANY bios that allow the user to specify which _partition()_ one wants to boot NT from. [SNIP] As we were speaking about, BIOS stands at the _rdisk()_ level, No it doesnt. All the bios can do is boot at the level of the physical drive and the active primary partition on that drive. Nonsense. Still as clueless as ever. Never ever could bull**** its way out of a wet paper bag. No wonder you end up having your mouth frothing rages. that's one level higher. [SNIP] MBR partition scheme is NOT firmware dependant (only the 55AAh signature is), it is a purely software concept (introduced with DOS 2 / IBM XT), and it is a damned good/clever idea: without it, we could only have ONE operating system on a given box Nonsense. It's fine to have several OSes on a single partition. (or perhaps one per bootable drive, assuming BIOS support to select among the available). And that too. [SNIP] Big snip; now we were about Boot.ini In fact the multi structure can be used for some SCSI drives, as well as ATA drives. This requires so-called "BIOS support" to be provided by the SCSI hardware (adapter usually). [SNIP] The multi and scsi protocols arent identical, for a reason. Quite true ;-). Multi() uses BIOS calls, using protected-to-real mode switches to call Int 13h, something that is impossible to do at a later stage (when the kernel has been started). Scsi() OTOH uses (normally) the same driver as will be used in normal operation. This in turn requires Ntldr to fake the kernel, at least the storage IRP stack and the most basic resources management, including memory allocation; plus starting and stoping the driver. The fact there are two indices is a given input, not a decision of the team. That sentence makes no sense. The ARC paths are of the form xxx(X)disk(Y)rdisk(Z)partition(N). With multi(X), no meaning is given to either X or Y, they are always 0. multi(0) has to be kept for coherency reasons, but why using disk(0)? My answer, because ARC (the preexisting MIPS standard) specified the general syntax. Using ARC paths including for i386 also was. [SNIP] I mean, Cutler's team chose to use ARC paths at Ntldr/Boot.ini level, when they could perfectly have used something else, perhaps the same strings used in the NT kernel (HarddiskZ\PartitionN), it would have been much less confusion for anybody. [SNIP] N could also have been defined clearly as the BIOS drive number, And there are downsides with that approach, most obviously they arent as obvious to the user. Very good point, and very probably the reason behind the text published by MS. However, the other formulations also have downside. For example, "the ordinal number of the drive" may appear faulty if the drive is not properly declared in the BIOS setup. [SNIP] snip Nothing grey about the MS statement that the rdisk() param is the ordinal of the drive on the controller. I did not find a clear statement from them that the rdisk() parameter is the BIOS drive number - 80h. [SNIP] Funny. The actual code DOES that computation (of course one may worry which other it could ever do.) "It isn't" because MS does not say it is: that's what I called "grey", or the usual "undocumented": it is this way, but since MS did not document it, they are allowed to change this in the future, without backfire about possible incompatibilities. [SNIP] |
#209
|
|||
|
|||
Boot.ini question
Rod Speed wrote:
Gerhard Fiedler wrote Rod Speed wrote Just you with a problem with basic english. Now this together with the following is almost funny... Its obvious what 'it varys' means. Pathetic, really. I didn't mean to say that, but if you say so |
Thread Tools | |
Display Modes | |
|
|