On Sat, 22 Sep 2012 22:04:40 +0100, Java Jive <ja...@evij.com.invalid>
>On Sat, 22 Sep 2012 20:34:27 +0100, Johny B Good
>> I've generated MD5 checksums, see below:
>> 21d9176d8dba084b0b6f2a0159aeeb83 NTDETECT.COM.2k
>XP version that I'm actually using with 2k:
>> 2ecc0cd4197c012f9d0fcff7f78e1d34 ntldr.2k
>Same, this version fails to boot XP:
>XP version that fails to boot 2k:
Just for completeness, here are the checksums for the winXP versions
I'm actually using to boot my win2k setup from:
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, not a lot considering the 90 seconds original boot time
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 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
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.
 This 4 seconds improvement was what others in the various forums
were reporting when trying this particular kludge.
 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.