Archived from groups: microsoft.public.windowsnt.setup (
More info?)
Hi Stephan,
I meant to reply to this post of yours the other day, and got caught up in other
things and forgot :-(
> ---> STOP 0x0000003E <---
>
> If you google around you'll find that there are really some people who cannot
> install NT4 on some P4-systems, on the other hand there are lot who can. Two
> things are discussed, AFAIR: Hyperthreading and the Prescott core. It is clear
> that NT4 cannot handle hyperthreading but is not clear why it cannot handle the
> Prescott core (if this is really the issue). It seems that it does not accept
> the
> CPU ID!? There was a similar(?) problem with NT 3.1 and 3.5 and >=
> PII-Processors and only the setup.inf and initial.inf had to be modified.
> Or maybe it is the HAL....?
>
> Anyway, this topic seems really interesting to a lot of people, especially those
> who (still) love NT4, ;-).
> - and there are only few discussions about.
There has been ongoing discussion for quite a while on this topic - though I
don't think it has really EVER drawn to any usable and verifiable conclusions.
My understanding is that the P4 processor is fine PROVIDED Hyperthreading is
disabled. The Prescott core is a complete unknown at this stage, I haven't heard
any comments for or against it. The other factor is Motherboard Chipsets. I have
heard conflicting reports with Intel Chipsets from 865 and later, some stating
NT4 will run on motherboards based on this technology, while other say it will
not - all very confusing. Unfortunately I don't have the funds to go buy a
whole heap of this latest hardware to conduct real-life experiments to prove or
disprove all these theories :-(
> Concerning the "7.8 GB" - discussion:
>
> Yes, no question "Windows NT 4.0 supports maximum of 7.8-GB system partition".
> Nevertheless, there seems to be some truth in the statement of your opponent.
>
> This very same article states:
> "If the Boot.ini file uses the multi()
> syntax for locating the boot partition, NTLDR uses the INT13
> interface to load the HAL, the kernel, and boot-start device
> drivers. In this case, these files must reside within the 7.8 GB
> addressable range of the INT13 interface. If the Boot.ini file
> uses scsi() syntax to find the boot partition, then a file named
> Ntbootdd.sys should exist on the system partition. This file is
> simply a renamed copy of the disk controller driver. In this
> case, NTLDR uses the Ntbootdd.sys driver to access the disk
> when loading the HAL, kernel, and boot-start device drivers.
> The addressable area of the disk is determined by this driver."
>
> In other words: in the scsi()-case only the boot.ini and Ntbootdd.sys needs to
> be reachable by the INT13 if Ntbootdd.sys (here: atapi.sys) does not use INT13
> itself. If you were going to install NT4 on a HDD (let's say 2 partitions 2 GB
> (boot) and > 8 GB (system) using the updated atapi.sys NT4 would AFAIK install
> using the scsi() syntax itself.
> I believe to have heard that this would really overcome the "7.8 GB" !? And if
> not - why not?
>
> Stephan
>
An interesting suggestion - I can't say I've ever heard of anyone trying using
the SCSI() syntax with IDE hardware and using atapi.sys as ntbootdd.sys - it
would be interesting to try it and see if it will work - I have my doubts though.
What this passage was trying to say (I think) is that the 7.8GB barrier is only
an issue on IDE hardware - SCSI hardware is unaffected because the boot
partition is accessed using the SCSI card driver (ntbootdd.sys) which doesn't
run into the CHS addressing issues that the IDE boot sequence does.
Calvin.