info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: How long will windows 2000 Pro. updates be available?
10 views
Skip to first unread message
Java Jive
Sep 9, 2012, 12:30:34 AM9/9/12
to
> Johny B Good wrote on Jun 26th:
>
> > Java Jive wrote on Jun 25th:
> >
> > IME, Windows 2000 hangs if you don't do this. What versions of NTLDR
> > and NTDETECT.COM are you actually using? Can you give us the version
> > numbers and the date/time/size of each?
>
> Unfortunately, there's no version info for these files, just creation
> and modified date/time stamps. These I can give you.
> Name Size (bytes) Modified
> NTLDR 250,048 14/04/2008 01:01
> NTDETECT.COM 47,564 13/04/2008 23:13
> NTLDR.2k 214,432 19/06/2003 12:05
> NTDETECT.COM.2k 34,724 19/06/2003 12:05
Only just got around to trying this ...
Firstly, FTR, your Win2k files are out-of-date, mine are dated:
Name Size (bytes) Modified
NTLDR 214,432 07/09/2004 03:20:35
NTDETECT.COM 34,724 07/09/2004 03:20:35
I tried booted Win2k with the WinXP loader files and WinXP with the
Win2k loader files. In both cases, the boot hangs with a message:
"<w> could not start because the following file is missing or corrupt:
\<d>\SYSTEM32\CONFIG\SYSTEM"
where:
<w> "Windows 2000" with NTLDR.2k, "Windows" with NTLDR.xp
<d> WINNT for 2k, Windows for XP
In other words, in both cases, the wrong loader can't load the right
version of the System Registry hive.
Also, it's only the version of NTLDR that seems to matter, there are
no obvious ill-effects from using the WinXP NTDETECT.COM when loading
Win2k, as long as you use the Win2k NTLDR.
--
=========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html
>
> > Java Jive wrote on Jun 25th:
> >
> > IME, Windows 2000 hangs if you don't do this. What versions of NTLDR
> > and NTDETECT.COM are you actually using? Can you give us the version
> > numbers and the date/time/size of each?
>
> Unfortunately, there's no version info for these files, just creation
> and modified date/time stamps. These I can give you.
> Name Size (bytes) Modified
> NTLDR 250,048 14/04/2008 01:01
> NTDETECT.COM 47,564 13/04/2008 23:13
> NTLDR.2k 214,432 19/06/2003 12:05
> NTDETECT.COM.2k 34,724 19/06/2003 12:05
Only just got around to trying this ...
Firstly, FTR, your Win2k files are out-of-date, mine are dated:
Name Size (bytes) Modified
NTLDR 214,432 07/09/2004 03:20:35
NTDETECT.COM 34,724 07/09/2004 03:20:35
I tried booted Win2k with the WinXP loader files and WinXP with the
Win2k loader files. In both cases, the boot hangs with a message:
"<w> could not start because the following file is missing or corrupt:
\<d>\SYSTEM32\CONFIG\SYSTEM"
where:
<w> "Windows 2000" with NTLDR.2k, "Windows" with NTLDR.xp
<d> WINNT for 2k, Windows for XP
In other words, in both cases, the wrong loader can't load the right
version of the System Registry hive.
Also, it's only the version of NTLDR that seems to matter, there are
no obvious ill-effects from using the WinXP NTDETECT.COM when loading
Win2k, as long as you use the Win2k NTLDR.
--
=========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html
Johny B Good
Sep 22, 2012, 12:29:08 PM9/22/12
to
On Sun, 09 Sep 2012 05:30:34 +0100, Java Jive <ja...@evij.com.invalid>
wrote:
>> Johny B Good wrote on Jun 26th:
>>
>> > Java Jive wrote on Jun 25th:
>> >
>> > IME, Windows 2000 hangs if you don't do this. What versions of NTLDR
>> > and NTDETECT.COM are you actually using? Can you give us the version
>> > numbers and the date/time/size of each?
>>
>> Unfortunately, there's no version info for these files, just creation
>> and modified date/time stamps. These I can give you.
>
>> Name Size (bytes) Modified
>> NTLDR 250,048 14/04/2008 01:01
>> NTDETECT.COM 47,564 13/04/2008 23:13
>> NTLDR.2k 214,432 19/06/2003 12:05
>> NTDETECT.COM.2k 34,724 19/06/2003 12:05
>
>Only just got around to trying this ...
>
>Firstly, FTR, your Win2k files are out-of-date, mine are dated:
>
>Name Size (bytes) Modified
>NTLDR 214,432 07/09/2004 03:20:35
>NTDETECT.COM 34,724 07/09/2004 03:20:35
They may have different modified dates but they still have the same
sizes.
>
>I tried booted Win2k with the WinXP loader files and WinXP with the
>Win2k loader files. In both cases, the boot hangs with a message:
>
>"<w> could not start because the following file is missing or corrupt:
>\<d>\SYSTEM32\CONFIG\SYSTEM"
>
>where:
> <w> "Windows 2000" with NTLDR.2k, "Windows" with NTLDR.xp
> <d> WINNT for 2k, Windows for XP
That's interesting. Are you trying to use the renamed files (eg
NTLDR.xp) or was that simply just to signify which versions you were
trying?
>
>In other words, in both cases, the wrong loader can't load the right
>version of the System Registry hive.
>
>Also, it's only the version of NTLDR that seems to matter, there are
>no obvious ill-effects from using the WinXP NTDETECT.COM when loading
>Win2k, as long as you use the Win2k NTLDR.
That was _not_ my experience. However, since I had renamed the win2k
versions as a means to create a name mismatch to prevent them being
used during the boot process and allow them to remain in the root of
the boot volume, it did occur to me that perhaps the boot process was
sufficiently intelligent enough to search out and use the 'proper
versions' in the event the properly named files were identified as
being unsuitable (silly I know, but, leave no stone unturned - take
nothing for granted and all that).
To eliminate this possibility, I created a "2k" folder and moved the
2k versions into that. The machine still boots fine. Now it occurs to
me that another way to try the two versions is to also create an XP
folder so that the unrenamed XP file versions can simply be moved to
hide them out of sight and the win2k versions renamed back to their
original names and then moved back to the root.
I haven't tried this but it does neatly avoid having to rename the
files when swapping versions around (just make sure to check that
you're moving each pair of files into the currently _empty_ folder
before using the contents of the other folder).
--
Regards, J B Good
wrote:
>> Johny B Good wrote on Jun 26th:
>>
>> > Java Jive wrote on Jun 25th:
>> >
>> > IME, Windows 2000 hangs if you don't do this. What versions of NTLDR
>> > and NTDETECT.COM are you actually using? Can you give us the version
>> > numbers and the date/time/size of each?
>>
>> Unfortunately, there's no version info for these files, just creation
>> and modified date/time stamps. These I can give you.
>
>> Name Size (bytes) Modified
>> NTLDR 250,048 14/04/2008 01:01
>> NTDETECT.COM 47,564 13/04/2008 23:13
>> NTLDR.2k 214,432 19/06/2003 12:05
>> NTDETECT.COM.2k 34,724 19/06/2003 12:05
>
>Only just got around to trying this ...
>
>Firstly, FTR, your Win2k files are out-of-date, mine are dated:
>
>Name Size (bytes) Modified
>NTLDR 214,432 07/09/2004 03:20:35
>NTDETECT.COM 34,724 07/09/2004 03:20:35
sizes.
>
>I tried booted Win2k with the WinXP loader files and WinXP with the
>Win2k loader files. In both cases, the boot hangs with a message:
>
>"<w> could not start because the following file is missing or corrupt:
>\<d>\SYSTEM32\CONFIG\SYSTEM"
>
>where:
> <w> "Windows 2000" with NTLDR.2k, "Windows" with NTLDR.xp
> <d> WINNT for 2k, Windows for XP
NTLDR.xp) or was that simply just to signify which versions you were
trying?
>
>In other words, in both cases, the wrong loader can't load the right
>version of the System Registry hive.
>
>Also, it's only the version of NTLDR that seems to matter, there are
>no obvious ill-effects from using the WinXP NTDETECT.COM when loading
>Win2k, as long as you use the Win2k NTLDR.
versions as a means to create a name mismatch to prevent them being
used during the boot process and allow them to remain in the root of
the boot volume, it did occur to me that perhaps the boot process was
sufficiently intelligent enough to search out and use the 'proper
versions' in the event the properly named files were identified as
being unsuitable (silly I know, but, leave no stone unturned - take
nothing for granted and all that).
To eliminate this possibility, I created a "2k" folder and moved the
2k versions into that. The machine still boots fine. Now it occurs to
me that another way to try the two versions is to also create an XP
folder so that the unrenamed XP file versions can simply be moved to
hide them out of sight and the win2k versions renamed back to their
original names and then moved back to the root.
I haven't tried this but it does neatly avoid having to rename the
files when swapping versions around (just make sure to check that
you're moving each pair of files into the currently _empty_ folder
before using the contents of the other folder).
--
Regards, J B Good
Java Jive
Sep 22, 2012, 1:35:22 PM9/22/12
to
On Sat, 22 Sep 2012 17:29:08 +0100, Johny B Good
<johnny...@invalid.ntlworld.com> wrote:
> On Sun, 09 Sep 2012 05:30:34 +0100, Java Jive <ja...@evij.com.invalid>
> wrote:
>
> >> Johny B Good wrote on Jun 26th:
> >>
> >> > Java Jive wrote on Jun 25th:
> >> >
> >> > IME, Windows 2000 hangs if you don't do this. What versions of NTLDR
> >> > and NTDETECT.COM are you actually using? Can you give us the version
> >> > numbers and the date/time/size of each?
> >>
> >> Unfortunately, there's no version info for these files, just creation
> >> and modified date/time stamps. These I can give you.
> >
> >> Name Size (bytes) Modified
> >> NTLDR 250,048 14/04/2008 01:01
> >> NTDETECT.COM 47,564 13/04/2008 23:13
> >> NTLDR.2k 214,432 19/06/2003 12:05
> >> NTDETECT.COM.2k 34,724 19/06/2003 12:05
> >
> >Only just got around to trying this ...
> >
> >Firstly, FTR, your Win2k files are out-of-date, mine are dated:
> >
> >Name Size (bytes) Modified
> >NTLDR 214,432 07/09/2004 03:20:35
> >NTDETECT.COM 34,724 07/09/2004 03:20:35
>
> They may have different modified dates but they still have the same
> sizes.
But could still be different internally. You'd have to perform a ...
<johnny...@invalid.ntlworld.com> wrote:
> On Sun, 09 Sep 2012 05:30:34 +0100, Java Jive <ja...@evij.com.invalid>
> wrote:
>
> >> Johny B Good wrote on Jun 26th:
> >>
> >> > Java Jive wrote on Jun 25th:
> >> >
> >> > IME, Windows 2000 hangs if you don't do this. What versions of NTLDR
> >> > and NTDETECT.COM are you actually using? Can you give us the version
> >> > numbers and the date/time/size of each?
> >>
> >> Unfortunately, there's no version info for these files, just creation
> >> and modified date/time stamps. These I can give you.
> >
> >> Name Size (bytes) Modified
> >> NTLDR 250,048 14/04/2008 01:01
> >> NTDETECT.COM 47,564 13/04/2008 23:13
> >> NTLDR.2k 214,432 19/06/2003 12:05
> >> NTDETECT.COM.2k 34,724 19/06/2003 12:05
> >
> >Only just got around to trying this ...
> >
> >Firstly, FTR, your Win2k files are out-of-date, mine are dated:
> >
> >Name Size (bytes) Modified
> >NTLDR 214,432 07/09/2004 03:20:35
> >NTDETECT.COM 34,724 07/09/2004 03:20:35
>
> They may have different modified dates but they still have the same
> sizes.
FC /b <file1> <file2>
... to be certain that they are actually the same. Our differing
experiences actually suggest that they are indeed different
internally. See below ...
> >I tried booted Win2k with the WinXP loader files and WinXP with the
> >Win2k loader files. In both cases, the boot hangs with a message:
> >
> >"<w> could not start because the following file is missing or corrupt:
> >\<d>\SYSTEM32\CONFIG\SYSTEM"
> >
> >where:
> > <w> "Windows 2000" with NTLDR.2k, "Windows" with NTLDR.xp
> > <d> WINNT for 2k, Windows for XP
>
> That's interesting. Are you trying to use the renamed files (eg
> NTLDR.xp) or was that simply just to signify which versions you were
> trying?
You can only boot using the standard names, because "NTLDR" is
hard-coded into the Partition Boot Record (PBR) loader, and
"NTDETECT.COM" into NTLDR. You can check the first using DiskProbe,
and the second by examining NTLDR in hex.
I merely renamed the ones not in use as .2k or .XP as appropriate, and
in the above referred to them thus.
> >In other words, in both cases, the wrong loader can't load the right
> >version of the System Registry hive.
> >
> >Also, it's only the version of NTLDR that seems to matter, there are
> >no obvious ill-effects from using the WinXP NTDETECT.COM when loading
> >Win2k, as long as you use the Win2k NTLDR.
>
> That was _not_ my experience.
particularly NTLDR?
> However, since I had renamed the win2k
> versions as a means to create a name mismatch to prevent them being
> used during the boot process and allow them to remain in the root of
> the boot volume, it did occur to me that perhaps the boot process was
> sufficiently intelligent enough to search out and use the 'proper
> versions' in the event the properly named files were identified as
> being unsuitable (silly I know, but, leave no stone unturned - take
> nothing for granted and all that).
quite a while, almost certainly since I installed the XP recovery
console, which I do on my standard 2k build because it can deal
natively with large hard disks, whereas the 2k RC can not.
There were changes to the registry from 2k to XP, IIRC so that XP
caches more of it than 2k, and I suspect that this explains why you
have to use the correct NTLDR for the particular version of Windows,
otherwise loading the System hive, which predictably and therefore
presumably must be the part of the registry that is read first, fails.
Johny B Good
Sep 22, 2012, 3:34:27 PM9/22/12
to
On Sat, 22 Sep 2012 18:35:22 +0100, Java Jive <ja...@evij.com.invalid>
I've generated MD5 checksums, see below:
21d9176d8dba084b0b6f2a0159aeeb83 NTDETECT.COM.2k
2ecc0cd4197c012f9d0fcff7f78e1d34 ntldr.2k
You can compare them with the MD5 checksums for your versions which
will settle the argument over whether or not they're different.
I can certainly see the benefit of using the winXP version of the
recovery console but I've never seen any urgent need for one.
>
>There were changes to the registry from 2k to XP, IIRC so that XP
>caches more of it than 2k, and I suspect that this explains why you
>have to use the correct NTLDR for the particular version of Windows,
>otherwise loading the System hive, which predictably and therefore
>presumably must be the part of the registry that is read first, fails.
I'm pretty certain the win2k registry[1] is entirely cached in ram
(instant access to disk drives when opening 'My Computer' anytime
after booting to the desktop). WinXP, otoh, behaves as though it only
loads the absolute minimum to get to the desktop (unconscionably long
delay when making the initial access to My Computer _any_ time after
booting to the desktop[2], plus the several seconds spent by MBAM's
quick scan 'enumerating' the registry compared to the less than a
second to do so in win2k).
[1] currently reported as being 32MB in size.
[2] subsequent accesses being about as fast as win2k's initial access
speed.
21d9176d8dba084b0b6f2a0159aeeb83 NTDETECT.COM.2k
2ecc0cd4197c012f9d0fcff7f78e1d34 ntldr.2k
You can compare them with the MD5 checksums for your versions which
will settle the argument over whether or not they're different.
recovery console but I've never seen any urgent need for one.
>
>There were changes to the registry from 2k to XP, IIRC so that XP
>caches more of it than 2k, and I suspect that this explains why you
>have to use the correct NTLDR for the particular version of Windows,
>otherwise loading the System hive, which predictably and therefore
>presumably must be the part of the registry that is read first, fails.
(instant access to disk drives when opening 'My Computer' anytime
after booting to the desktop). WinXP, otoh, behaves as though it only
loads the absolute minimum to get to the desktop (unconscionably long
delay when making the initial access to My Computer _any_ time after
booting to the desktop[2], plus the several seconds spent by MBAM's
quick scan 'enumerating' the registry compared to the less than a
second to do so in win2k).
[1] currently reported as being 32MB in size.
[2] subsequent accesses being about as fast as win2k's initial access
speed.
Java Jive
Sep 22, 2012, 5:04:40 PM9/22/12
to
On Sat, 22 Sep 2012 20:34:27 +0100, Johny B Good
<johnny...@invalid.ntlworld.com> wrote:
>
> I've generated MD5 checksums, see below:
>
> 21d9176d8dba084b0b6f2a0159aeeb83 NTDETECT.COM.2k
Same:
<johnny...@invalid.ntlworld.com> wrote:
>
> I've generated MD5 checksums, see below:
>
> 21d9176d8dba084b0b6f2a0159aeeb83 NTDETECT.COM.2k
21d9176d8dba084b0b6f2a0159aeeb83
XP version that I'm actually using with 2k:
b2de3452de03674c6cec68b8c8ce7c78
> 2ecc0cd4197c012f9d0fcff7f78e1d34 ntldr.2k
Same, this version fails to boot XP:
2ecc0cd4197c012f9d0fcff7f78e1d34
XP version that fails to boot 2k:
c1b29b4e6eea9510610db2ec4d6db160
> You can compare them with the MD5 checksums for your versions which
> will settle the argument over whether or not they're different.
results were unequivocal, and, as reinforced below, follow an
understandable logic, so I have to ask: could you have made a mistake?
> >> However, since I had renamed the win2k
> >> versions as a means to create a name mismatch to prevent them being
> >> used during the boot process and allow them to remain in the root of
> >> the boot volume, it did occur to me that perhaps the boot process was
> >> sufficiently intelligent enough to search out and use the 'proper
> >> versions' in the event the properly named files were identified as
> >> being unsuitable (silly I know, but, leave no stone unturned - take
> >> nothing for granted and all that).
> >
> >No, it turns out that I've been using the XP NTDETECT.COM on 2k for
> >quite a while, almost certainly since I installed the XP recovery
> >console, which I do on my standard 2k build because it can deal
> >natively with large hard disks, whereas the 2k RC can not.
>
> I can certainly see the benefit of using the winXP version of the
> recovery console but I've never seen any urgent need for one.
> >There were changes to the registry from 2k to XP, IIRC so that XP
> >caches more of it than 2k, and I suspect that this explains why you
> >have to use the correct NTLDR for the particular version of Windows,
> >otherwise loading the System hive, which predictably and therefore
> >presumably must be the part of the registry that is read first, fails.
>
> I'm pretty certain the win2k registry[1] is entirely cached in ram
> (instant access to disk drives when opening 'My Computer' anytime
> after booting to the desktop). WinXP, otoh, behaves as though it only
> loads the absolute minimum to get to the desktop (unconscionably long
> delay when making the initial access to My Computer _any_ time after
> booting to the desktop[2], plus the several seconds spent by MBAM's
> quick scan 'enumerating' the registry compared to the less than a
> second to do so in win2k).
>
> [1] currently reported as being 32MB in size.
>
> [2] subsequent accesses being about as fast as win2k's initial access
> speed.
point remains that there is a difference in registry handling.
I've just searched NTLDR (2k), and the string ...
\SYSTEM32\CONFIG\SYSTEM
... appears in it at offset 1FD3E. This supports my idea voiced
earlier that it is NTLDR that first loads the System registry hive,
and therefore has to have the OS-specific coding to get it right. This
would completely explain the behaviour and the error messages that I
observed when using the wrong NTLDR for the OS.
Johny B Good
Sep 22, 2012, 11:19:57 PM9/22/12
to
On Sat, 22 Sep 2012 22:04:40 +0100, Java Jive <ja...@evij.com.invalid>
wrote:
>On Sat, 22 Sep 2012 20:34:27 +0100, Johny B Good
><johnny...@invalid.ntlworld.com> wrote:
>>
>> I've generated MD5 checksums, see below:
>>
>> 21d9176d8dba084b0b6f2a0159aeeb83 NTDETECT.COM.2k
>
>Same:
>21d9176d8dba084b0b6f2a0159aeeb83
>
>XP version that I'm actually using with 2k:
>b2de3452de03674c6cec68b8c8ce7c78
>
>> 2ecc0cd4197c012f9d0fcff7f78e1d34 ntldr.2k
>
>Same, this version fails to boot XP:
>2ecc0cd4197c012f9d0fcff7f78e1d34
>
>XP version that fails to boot 2k:
>c1b29b4e6eea9510610db2ec4d6db160
Just for completeness, here are the checksums for the winXP versions
I'm actually using to boot my win2k setup from:
b2de3452de03674c6cec68b8c8ce7c78 NTDETECT.COM
c1b29b4e6eea9510610db2ec4d6db160 NTLDR
The mystery deepens. It's a bit of a conundrum as to why our
experiences are so different. In my case only the use of winXP
versions to boot a win2k setup, I haven't tried the opposite case of
win2k versions on a winXP box.
When I read about the use of winXP versions to speed up a win2k boot
process, I was rather sceptical. To my surprise, I didn't land up with
a borked win2k install and it did seem to shave off about 4
seconds[1], not a lot considering the 90 seconds original boot time
involved.
I had rather hoped it would eliminate the mysterious extra 30 to 40
seconds spent looking at the starting windows 2000 logo screen but any
improvement, no matter how disappointingly short of my hope, isn't
something to be sneezed at.
I'm quite convinced this protracted part of the boot process is down
to the scsi like nature of the built in sata ports[2] which win2k
doesn't handle too cleverly. The ten year old desktop (with a 1GHz
Athlon and 400GB IDE drive) and the almost 6 years old Acer notebook
(Celeron M420 1.6GHz cpu and no sata at all) both manage to boot up in
60 seconds give or take a second or two.
The benefit of a 30GB ssd and a dual core 3GHz clocked Phenom only
becomes apparent once it has booted to the desktop where not even the
startup sequence of initialising the Avast free antivirus, the most
draggy of all the 'add-ons' (as witnessed with winXP and higher
windows versions), can slow down access to whatever app I care to fire
up. None of this "I'd give it 5 minutes if I were you." type nonsense
normally suffered by those other windows versions.
I've considered using sata to ide converters to allow me to connect
the ssd drive via the ide port so I can totally disable the built in
sata ports completely in order to test this hypothesis (plus
installing a promise ide card to do the same with the two HDDs).
I'm sure this would shave a good 30 seconds off the boot time even
though it'll reduce the post boot performance. If nothing else, it'll
confirm whether my hypothesis is the correct one for the protracted
boot time.
The md5 checksums confirm that I'm actually using the same winXP
versions of those two files as yours.
>
>> >> However, since I had renamed the win2k
>> >> versions as a means to create a name mismatch to prevent them being
>> >> used during the boot process and allow them to remain in the root of
>> >> the boot volume, it did occur to me that perhaps the boot process was
>> >> sufficiently intelligent enough to search out and use the 'proper
>> >> versions' in the event the properly named files were identified as
>> >> being unsuitable (silly I know, but, leave no stone unturned - take
>> >> nothing for granted and all that).
>> >
>> >No, it turns out that I've been using the XP NTDETECT.COM on 2k for
>> >quite a while, almost certainly since I installed the XP recovery
>> >console, which I do on my standard 2k build because it can deal
>> >natively with large hard disks, whereas the 2k RC can not.
>>
>> I can certainly see the benefit of using the winXP version of the
>> recovery console but I've never seen any urgent need for one.
>
>Sometime it save that hassle of trying to find the installation CD.
In my case, the only showstopping event that, on the face of it,
would make a recovery console come into its own, unfortunately, cannot
help in the slightest.
The error in question being the Licence violation error caused by the
power down induced corruption of the SSD for which the only quick fix
is the restore from a recent partition image backup method.
Thankfully, since I replaced the PSU innards, the once every week or
three rate at which this event was occuring has now dropped to a once
every two or three months rate.
Even before acquiring the ssd, I might find myself having to boot
into the recovery console from the win2k disk maybe as often as once
or twice a year but in any case, I was creating 'regular' (fsvo
'regular') image backups of the boot partition which often proved
their worth when it turned out that the measures available from the
recovery console weren't up to repairing the damage.
Well the fact that I am able to successfully boot win2k using the
winXP versions does place some doubt on your hypothesis.
[1] This 4 seconds improvement was what others in the various forums
were reporting when trying this particular kludge.
[2] Echoes of my experience with a P2/450 box fitted with an ISA
Adaptec SCSI card being used purely to support a quad speed CD writer
and an Artec Flatbed scanner. In this case, I was able to configure
the adapter to reduce the 3 or 4 minute boot time to a more reasonable
45 or so seconds. In this case, I have no such configuration option to
prevent win2k going off on a wild goose chase searching out all
possible boot devices that it might believe to exist on the very SCSI
looking SATA interface.
wrote:
>On Sat, 22 Sep 2012 20:34:27 +0100, Johny B Good
><johnny...@invalid.ntlworld.com> wrote:
>>
>> I've generated MD5 checksums, see below:
>>
>> 21d9176d8dba084b0b6f2a0159aeeb83 NTDETECT.COM.2k
>
>Same:
>21d9176d8dba084b0b6f2a0159aeeb83
>
>XP version that I'm actually using with 2k:
>b2de3452de03674c6cec68b8c8ce7c78
>
>> 2ecc0cd4197c012f9d0fcff7f78e1d34 ntldr.2k
>
>Same, this version fails to boot XP:
>2ecc0cd4197c012f9d0fcff7f78e1d34
>
>XP version that fails to boot 2k:
>c1b29b4e6eea9510610db2ec4d6db160
I'm actually using to boot my win2k setup from:
b2de3452de03674c6cec68b8c8ce7c78 NTDETECT.COM
c1b29b4e6eea9510610db2ec4d6db160 NTLDR
The mystery deepens. It's a bit of a conundrum as to why our
experiences are so different. In my case only the use of winXP
versions to boot a win2k setup, I haven't tried the opposite case of
win2k versions on a winXP box.
When I read about the use of winXP versions to speed up a win2k boot
process, I was rather sceptical. To my surprise, I didn't land up with
a borked win2k install and it did seem to shave off about 4
seconds[1], not a lot considering the 90 seconds original boot time
involved.
I had rather hoped it would eliminate the mysterious extra 30 to 40
seconds spent looking at the starting windows 2000 logo screen but any
improvement, no matter how disappointingly short of my hope, isn't
something to be sneezed at.
I'm quite convinced this protracted part of the boot process is down
to the scsi like nature of the built in sata ports[2] which win2k
doesn't handle too cleverly. The ten year old desktop (with a 1GHz
Athlon and 400GB IDE drive) and the almost 6 years old Acer notebook
(Celeron M420 1.6GHz cpu and no sata at all) both manage to boot up in
60 seconds give or take a second or two.
The benefit of a 30GB ssd and a dual core 3GHz clocked Phenom only
becomes apparent once it has booted to the desktop where not even the
startup sequence of initialising the Avast free antivirus, the most
draggy of all the 'add-ons' (as witnessed with winXP and higher
windows versions), can slow down access to whatever app I care to fire
up. None of this "I'd give it 5 minutes if I were you." type nonsense
normally suffered by those other windows versions.
I've considered using sata to ide converters to allow me to connect
the ssd drive via the ide port so I can totally disable the built in
sata ports completely in order to test this hypothesis (plus
installing a promise ide card to do the same with the two HDDs).
I'm sure this would shave a good 30 seconds off the boot time even
though it'll reduce the post boot performance. If nothing else, it'll
confirm whether my hypothesis is the correct one for the protracted
boot time.
versions of those two files as yours.
>
>> >> However, since I had renamed the win2k
>> >> versions as a means to create a name mismatch to prevent them being
>> >> used during the boot process and allow them to remain in the root of
>> >> the boot volume, it did occur to me that perhaps the boot process was
>> >> sufficiently intelligent enough to search out and use the 'proper
>> >> versions' in the event the properly named files were identified as
>> >> being unsuitable (silly I know, but, leave no stone unturned - take
>> >> nothing for granted and all that).
>> >
>> >No, it turns out that I've been using the XP NTDETECT.COM on 2k for
>> >quite a while, almost certainly since I installed the XP recovery
>> >console, which I do on my standard 2k build because it can deal
>> >natively with large hard disks, whereas the 2k RC can not.
>>
>> I can certainly see the benefit of using the winXP version of the
>> recovery console but I've never seen any urgent need for one.
>
>Sometime it save that hassle of trying to find the installation CD.
would make a recovery console come into its own, unfortunately, cannot
help in the slightest.
The error in question being the Licence violation error caused by the
power down induced corruption of the SSD for which the only quick fix
is the restore from a recent partition image backup method.
Thankfully, since I replaced the PSU innards, the once every week or
three rate at which this event was occuring has now dropped to a once
every two or three months rate.
Even before acquiring the ssd, I might find myself having to boot
into the recovery console from the win2k disk maybe as often as once
or twice a year but in any case, I was creating 'regular' (fsvo
'regular') image backups of the boot partition which often proved
their worth when it turned out that the measures available from the
recovery console weren't up to repairing the damage.
winXP versions does place some doubt on your hypothesis.
[1] This 4 seconds improvement was what others in the various forums
were reporting when trying this particular kludge.
[2] Echoes of my experience with a P2/450 box fitted with an ISA
Adaptec SCSI card being used purely to support a quad speed CD writer
and an Artec Flatbed scanner. In this case, I was able to configure
the adapter to reduce the 3 or 4 minute boot time to a more reasonable
45 or so seconds. In this case, I have no such configuration option to
prevent win2k going off on a wild goose chase searching out all
possible boot devices that it might believe to exist on the very SCSI
looking SATA interface.
0 new messages