How long will windows 2000 Pro. updates be available?

[Kenn Caesius]

I am already thinking about a future where I may or may not have install
Windows 2000 Pro. on a completely unformatted computer. Has there been
in discussion by MS or other professionals about one day removing access
the update page for Windows 2000 or similar event?

---End of message---

[Loony]

I'd say it is extremely unlikely that Win2K will be revived again. It
was my favorite OS. My guess is that it would take a lot of efforts to
protect the computer that has it running now and connected to the 'net.

[Bruce Morgen]

I finally gave up and upgraded
to XP for that reason -- even
Firefox no longer works under
Win2k, and there's no way this
old hardware could handle Win7.
IOW, no choice.... :-(

[Andrew Rossmann]

In article <ssens7tvgh60a75dk...@4ax.com>, edi...@juno.com
says...

> I finally gave up and upgraded
> to XP for that reason -- even
> Firefox no longer works under
> Win2k, and there's no way this
> old hardware could handle Win7.
> IOW, no choice.... :-(

Firefox works fine with Win2K. I have 12.0 on my old work computer. Even
the latest Flash does work, but you have to do a patch to get the
installer to work.

--
If there is a no_junk in my address, please REMOVE it before replying!
All junk mail senders will be prosecuted to the fullest extent of the
law!!
http://home.comcast.net/~andyross

[Bruce Morgen]

Andrew Rossmann <andysnewsreply@no_junk.comcast.net> wrote:

>In article <ssens7tvgh60a75dk...@4ax.com>, edi...@juno.com
>says...
>> I finally gave up and upgraded
>> to XP for that reason -- even
>> Firefox no longer works under
>> Win2k, and there's no way this
>> old hardware could handle Win7.
>> IOW, no choice.... :-(
>
>Firefox works fine with Win2K. I have 12.0 on my old work computer. Even
>the latest Flash does work, but you have to do a patch to get the
>installer to work.

Fine -- after a day's tweaking
I've got XP looking like Win2k
and it seems to actually
perform a bit better in most
respects (this box has five
SCSI hard drives, two SCSI
controller, a Winmodem for
FAXing, two sound cards, and a
USB card so I could get USB
2.x speed and front panel
connectors -- it took *forever*
to boot up under Win2k).
Firefox refused to upgrade me
to v12.0 and advised me to
either upgrade the OS or find
myself another browser. I
chose the former because my
neighbor's old XP Pro box fried
its MB last year and he'd
given me his XP product key in
exchange for putting some RAM
in his new Win7 notebook.

Since my hardware is fairly
capable for its advanced age
(2xPIII @1gHz and 1gB RAM),
that made the most sense for
me -- ymmv, of course, but for
me it was time to move on to a
still-supported product. In
addition to Flash, Acrobat
Reader had fallen behind and
recent versions of VLC were a
no-go until I got XP going --
apparently, some functions of
VLC now requre one of XPs DLLs.

IOW, so far so good and zero
regrets.

[Bruce Morgen]

Addendum: Actually, now that I
think about it, Firefox warned
me the v13.xx wouldn't work
with Win2K, which was the
straw that broke my particular
camel's back regarding finally
making the jump to XP.

[Johny B Good]

I think Kenn was simply querying how much longer win2kSP4 updates
would remain available on line to allow fresh re-installs to be able
to update to the latest that were available at the end-of-life-support
cut off point (June 2010?), rather than newer updates being made
available since that date.

In any case, ignoring crappy products like FF, win2k is easier to
secure than its broken brain dead son, winXP, since you're still
forced to use third party security products on _all_ versions of
windows and win2k offers far less resistance to the AV engines when
scanning (most notably, the fact that win2k loads all of its registry
into ram rather than just caching the accessed bits as and when
they're actually accessed in the case of winXP).

Yes, rather sadly, win2k is slowly but surely being disowned by third
party software houses (driver support as well as apps) eventually
forcing even the most ardent of us 'Refuseniks' to let go of our
favourite MS OS as the primary host OS.

That doesn't necessarily mean we'll all be choosing win7 as the
alternative. Obviously, a lot will go over to this latest 'festering
PoS' offering from MS but I suspect quite a few will be turning to a
linux distro deemed suitable for the job with winXP running in a VM to
allow those very few 'must have' essential windows only apps to run.

The nice thing about running such festering PoS MS OSes in VMs is
that they can be treated as 'just another disposable app' removing the
need to bother with antivrus ware (although it's still a good idea to
install SpyBoy S&D and MBAM's free on-demand scanner - zero
performance impact protection).
--
Regards, J B Good

[Skywise]

Johny B Good <johnny...@invalid.ntlworld.com> wrote in
news:tn14t71vsj718ehv9...@4ax.com:

> Yes, rather sadly, win2k is slowly but surely being disowned by third
> party software houses (driver support as well as apps) eventually
> forcing even the most ardent of us 'Refuseniks' to let go of our
> favourite MS OS as the primary host OS.
>
> That doesn't necessarily mean we'll all be choosing win7 as the
> alternative. Obviously, a lot will go over to this latest 'festering
> PoS' offering from MS but I suspect quite a few will be turning to a
> linux distro deemed suitable for the job with winXP running in a VM to
> allow those very few 'must have' essential windows only apps to run.

I have a Win2kProSP4 and a WinXPproSP3 desktop, and recently
acquired a low end laptop which came with Win7.

I enjoy my two desktop machines. They're both locked down
pretty good apparently as in all my years of PCing on windows
I've never been infected successfully. I won't say what I
do security wise as that's just silly to do, but I will say
I don't do a heck of a lot. Just a few simple common sense
things. Plenty of websites to explain those.

I don't do anything 'serious' on my laptop so I can't really
say about Win7, yet. It's doing what I need it to do and hasn't
really given me any fits. In fact, there's a few interface
features that I really like, but that's just icing and not cake.

I want to switch to linux (have toyed a bit with Kubuntu, I
like it), but unfortunately will likely have to have a windows
machine for some time as I have some hardware/software that
simply aren't supported on linux. No biggy, that machine's
purpose isn't for online stuff anyway.

My ideal for my next computers that I build, I will build
two identical machines hardware wise. One will get windows,
and the other with gets linux. That way I'll have a known
working machine that I know how to use while I learn the
ropes of linux.

In the end, I'll keep my Win2k machine alive as long as
possible. It's always been solid and reliable. In fact, I
have a 'maintenance/repair/diagnostic' spare hard drive
that is Win2k based.

Just some thoughts....

Brian

[Kenn Caesius]

Hello Johny B Good, that was exactly what I was asking.

I would also like to add a post script to my initial question - if I
were to do a clean install of Windows 2000 Professional, how many MB
will I have to download to have my computer update?

---End of message---

[Java Jive]

About 280 files totalling 1.2GB, excluding things like Visual Studio
and IIS updates which would add another 1GB or so, but including
things like DirectX, IE6, and WMP.

--
=========================================================
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]

On Sat, 9 Jun 2012 14:05:19 -0700, "Kenn Caesius"
<xilotea...@yahoo.com> wrote:

The last time I did a scratch install was 11 months ago. This was
done from an SP4 slipstreamed win2k install CD. The reason for
re-installing from scratch was on account I couldn't find an effective
way to align the existing installation partition on the cheapskate
30GB Kingston SSD (too small a value of capacitor to allow the ram
cache to be flushed to the nand flash ram on every power down).

I'm afraid I can't recall how many and how much megabytes worth of
updates were involved but Java Jive's estimate seems about right.

If you haven't already done so, I suggest you create an SP4
sliptstreamed install CD before embarking on such an enterprise.

One major gotcha when installing onto a modern HDD with a capcity in
excess of 128 GiB capacity (in practice, drives larger than "120GB")
is that the installer will only allow you to create a 127.5GiB (137GB)
drive C partition and won't correctly recognise space beyond this
boundary.

This isn't really much of an issue in practice since only an idiot
would want to create a single huge partition for the OS, Apps and data
to rattle around in.

An initial 127.5GB drive C primary partition is obscenely excessive
even when you plan to "Keep it Simple" and use the C drive for both OS
and apps. Since the question of having to create extra logical
drive(s) within an extended partition space cannot be avoided if you
wish to fully utilise a 160GB or larger drive, you may as well do the
sensible thing and pick a drive C size optimised for the idea of
having seperate disk volumes for the OS, the application software and
the user data.

By way of example, I split that 30GB SSD into a 10GB C drive and used
the remaining 17.9GB as a D drive (I'd have created such partitons
anyway when using the 1TB drive on its own with the remaining 900 odd
GB used for a drive E for data, notably, reloacating the "My
Documents" folder to this space). In this case, I had already
pre-partitioned the SSD with aligned partitions (the whole point of
the exercise).

If you're installing onto a hard disk that doesn't use 4k advanced
format sectors, you can use the install CD's own partitioning option
to create the initial drive C partition, ignoring whatever remaining
space is visible at this stage (you can deal with this _after_
completing the initial install).

Once you've finished the initial install, you can then apply the
Large LBA fix which will allow diskmanager to properly see the rest of
the disk space and allow you to partition and format without risk of
'wrap around' LBA addressing errors corrupting the OS files.

If you're re-installing from scratch onto a such a disk with existing
partitions that extend beyond win2kSP4's initial LBA
'shortsightedness', it's most important to remember to apply the Large
LBA fix before attempting any write accesses beyond the 128GB
boundary.

If you find the 10/20/whatever's leftover partitoning a bit too
extreme and prefer something like a 30 to 60GB/whatever's leftover
partitioning scheme to give you an OS plus apps drive C with a
seperate larger D partition for data, then by all means do so (you're
initially stuck with a 128GB limit anyway for drive C) rather than
simply use a partitioning tool to expand drive C (after applying the
large LBA fix) into the whole of the disk space.

I use (and recomend) partition image backups of at least the OS drive
partition. The last one I created is only 827MB in size. This doesn't
take up much space and can be restored in a matter of just two or
three minutes from booting from the Paragon rescue CD. It's a far more
reliable way to roll back to a working system than winXP's flawed
system restore method.

One more vital post install configuration change that's well worth
doing is to establish a fixed size pagefile, preferably on the first
small partition space of a second disk drive (otherwise leave it in
the drive C partition). I typically set it to 3 times the ram size or
else just short of the 4GB limit (4095MB).

You can create pagefiles on each and every disk volume if you so wish
but, unless you can identify a need to have more than 4GB's worth of
swap space, you're probably better off with a single pagefile on the
fastest part of a second disk drive.

I could go on but I'll leave it at that. I'd explain why seperate
partitions and fixed size pagefile(s) are "A Good Thing"(tm) but it
aught to be blindingly obvious to anyone with more than a passing
interest in optimising a Windows OS install.

[Java Jive]

I started this post a few days ago, but had to leave it unfinished due
to other more pressing matters, and have only just rediscovered it in
my Drafts folder.

On Wed, 13 Jun 2012 14:36:05 +0100, Johny B Good
<johnny...@invalid.ntlworld.com> wrote:
>
> I'm afraid I can't recall how many and how much megabytes worth of
> updates were involved but Java Jive's estimate seems about right.

Actually, it's a bit more than an estimate. I've downloaded all, I
think, the W2k, IE6, WMP, IIS, and VS update exes onto my server, to
ensure that I can continue to use the OS, should I so wish. In fact,
I'm using W2k to write this, specifically my own standard build that
works on all my PCs, built as described in the linked page below.

> One major gotcha when installing onto a modern HDD with a capcity in
> excess of 128 GiB capacity (in practice, drives larger than "120GB")
> is that the installer will only allow you to create a 127.5GiB (137GB)
> drive C partition and won't correctly recognise space beyond this
> boundary.

Yes, because ...

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters]
"EnableBigLba"=dword:00000001

... is by default absent or set to zero, I can't remember which.

> This isn't really much of an issue in practice since only an idiot
> would want to create a single huge partition for the OS, Apps and data
> to rattle around in.
>
> An initial 127.5GB drive C primary partition is obscenely excessive
> even when you plan to "Keep it Simple" and use the C drive for both OS
> and apps. Since the question of having to create extra logical
> drive(s) within an extended partition space cannot be avoided if you
> wish to fully utilise a 160GB or larger drive, you may as well do the
> sensible thing and pick a drive C size optimised for the idea of
> having seperate disk volumes for the OS, the application software and
> the user data.

IMV, there is a great deal to be gained in having seperate
partitions/drives for the system, including software applications,
and the data, but absolutely nothing to be gained by splitting it
three ways. As the vast majority of Windows PC software stores a
great deal of configuration data in the registry, and at that nearly
all of it in the same HKLM hive as nearly all Windows configuration
data, and as a single registry hive can only be stored in one place at
a time, there is little or no benefit and makes absolutely no sense at
all to complicate matters unnecessarily by installing the software on
a seperate partition from the system.

My advice, based on years of doing builds for a large business with
thousands of users, is to split the build two ways, one for the system
including software, and one for the data, as described here:
http://www.macfh.co.uk/JavaJive/Windows/WindowsImageBuilding.html

> If you're installing onto a hard disk that doesn't use 4k advanced
> format sectors, you can use the install CD's own partitioning option
> to create the initial drive C partition, ignoring whatever remaining
> space is visible at this stage (you can deal with this _after_
> completing the initial install).
>
> Once you've finished the initial install, you can then apply the
> Large LBA fix which will allow diskmanager to properly see the rest of
> the disk space and allow you to partition and format without risk of
> 'wrap around' LBA addressing errors corrupting the OS files.
>
> If you're re-installing from scratch onto a such a disk with existing
> partitions that extend beyond win2kSP4's initial LBA
> 'shortsightedness', it's most important to remember to apply the Large
> LBA fix before attempting any write accesses beyond the 128GB
> boundary.

Yes, agreed.

> If you find the 10/20/whatever's leftover partitoning a bit too
> extreme and prefer something like a 30 to 60GB/whatever's leftover
> partitioning scheme to give you an OS plus apps drive C with a
> seperate larger D partition for data, then by all means do so (you're
> initially stuck with a 128GB limit anyway for drive C) rather than
> simply use a partitioning tool to expand drive C (after applying the
> large LBA fix) into the whole of the disk space.

Unless the OP has even more software installed than myself, which is
unlikely, about 20GB should be plenty for the system partition, the
rest can be used for data. Currently, about 15GB of my system disk is
used.

> I use (and recomend) partition image backups of at least the OS drive
> partition. The last one I created is only 827MB in size. This doesn't
> take up much space and can be restored in a matter of just two or
> three minutes from booting from the Paragon rescue CD. It's a far more
> reliable way to roll back to a working system than winXP's flawed
> system restore method.

Yes, though, as they include all the software, my backups are much
bigger, about 7-8GB. About half the used space on the system drive is
normal for a compressed image made by, say, Ghost, or one of the free
alternatives. You may be able to reduce the size by booting into the
Recovery Console beforehand, which automatically deletes the pagefile,
and as I don't allow hibernation, there is no hibernation file anyway.

> One more vital post install configuration change that's well worth

> doing is to establish a fixed size pagefile ... leave it in

> the drive C partition). I typically set it to 3 times the ram size or
> else just short of the 4GB limit (4095MB).

Normal practice is simply to put it on the system (C:) drive. The
recommendation is twice the installed RAM, or the maximum, whichever
is smaller. I suspect there will little or no measurable benefit from
putting the pagefile on a seperate drive, unless perhaps you are
running SSD drives, and wish to avoid wearing them out. Unless
there's some good reason, keep it simple and follow the
recommendations.

One more thing. If one has a disk larger than the 128GB limit, it's
worth installing the XP Recovery Console instead of the W2k one, as
that will recognise partitions that go beyond the 128GB limit. WITH
CARE, once the system build is complete and all updates have been
installed, this can be done as follows:

1) Look in the root of C: and backup NTLDR to, say, NTLDR.W2K
2) Insert an XP Pro installation CD and install the RC by going into
a DOS console and typing ...

<CD Drive>\I386\WINNT32.EXE /console

... answering any confirmations appropriately. You can allow it to
search for updated files, though it actually doesn't seem to make much
difference.
3) IMPORTANT - When installation is complete, before rebooting
rename NTLDR to, say, NTLDR.XP, and replace it with a copy of the file
backed up in 1.
4) Optionally, <Rt-Click> My Computer and choose Properties,
Advanced, Startup and Recovery, and change the time that alternative
operating systems are displayed to something more sensible like 5s, or
edit the RO H S file C:\BOOT.INI to effect the same change.
5) Run the Group Policy editor gpedit (may have to get it from the
installation CD toolkit - I can't remember now) OR choose Start,
Settings, Control Panel, Administrative Tools, Security Policy, OR run
mmc and choose the console secpol.

Whichever way you're doing this, open up the branch that ends Security
Settings, Local Policies, Security Options, and set:

Recovery Console: Allow automatic administrative logon = disabled
Recovery Console: Allow floppy copy and access to all drives and all
folders = enabled.

Now if you have a bad, bad, system problem, at least you can reboot
into the XP Recovery console and copy anything desperately important
off the data drive.

[Johny B Good]

On Thu, 21 Jun 2012 14:31:50 +0100, Java Jive <ja...@evij.com.invalid>
wrote:

>I started this post a few days ago, but had to leave it unfinished due
>to other more pressing matters, and have only just rediscovered it in
>my Drafts folder.
>
>On Wed, 13 Jun 2012 14:36:05 +0100, Johny B Good
><johnny...@invalid.ntlworld.com> wrote:
>>
>> I'm afraid I can't recall how many and how much megabytes worth of
>> updates were involved but Java Jive's estimate seems about right.
>
>Actually, it's a bit more than an estimate. I've downloaded all, I
>think, the W2k, IE6, WMP, IIS, and VS update exes onto my server, to
>ensure that I can continue to use the OS, should I so wish. In fact,
>I'm using W2k to write this, specifically my own standard build that
>works on all my PCs, built as described in the linked page below.

That's a MAXIMUM figure then. I've never bothered with the WMP, IIS,
VS _and_ all the dot net tosh so I couldn't have offered any
worthwhile opinion other than bowing to your superior knowledge in
this regard.

>
>> One major gotcha when installing onto a modern HDD with a capcity in
>> excess of 128 GiB capacity (in practice, drives larger than "120GB")
>> is that the installer will only allow you to create a 127.5GiB (137GB)
>> drive C partition and won't correctly recognise space beyond this
>> boundary.
>
>Yes, because ...
>
>[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters]
>"EnableBigLba"=dword:00000001
>
>... is by default absent or set to zero, I can't remember which.

Nor can I offhand. I've done the registry by hand as well as use the
LBAFixtool.

>
>> This isn't really much of an issue in practice since only an idiot
>> would want to create a single huge partition for the OS, Apps and data
>> to rattle around in.
>>
>> An initial 127.5GB drive C primary partition is obscenely excessive
>> even when you plan to "Keep it Simple" and use the C drive for both OS
>> and apps. Since the question of having to create extra logical
>> drive(s) within an extended partition space cannot be avoided if you
>> wish to fully utilise a 160GB or larger drive, you may as well do the
>> sensible thing and pick a drive C size optimised for the idea of
>> having seperate disk volumes for the OS, the application software and
>> the user data.
>
>IMV, there is a great deal to be gained in having seperate
>partitions/drives for the system, including software applications,
>and the data, but absolutely nothing to be gained by splitting it
>three ways. As the vast majority of Windows PC software stores a
>great deal of configuration data in the registry, and at that nearly
>all of it in the same HKLM hive as nearly all Windows configuration
>data, and as a single registry hive can only be stored in one place at
>a time, there is little or no benefit and makes absolutely no sense at
>all to complicate matters unnecessarily by installing the software on
>a seperate partition from the system.

This partitioning into seperate OS, Apps and Data partitions is a
matter of convention and has no effect on where the various registry
hives get stored - they remain on the system drive (conventionally
drive C).

I've seen and tried the system settings changes (registry or system
variables, I can't remember which) required to make installers
automatically choose drive D by default but this still had issues so I
gave up on trying to configure the system to make installers choose
drive D by default and went back to manually choosing drive D (or
whatever disk volume of choice that took my fancy).

In my case (C&D disk volumes) the total consumption by the OS and
apps amounts to 8.4GB but this is sans the pagefile which lives on
another physically seperate disk to prevent undue wear on the SSD's
erase blocks.

>
>> I use (and recomend) partition image backups of at least the OS drive
>> partition. The last one I created is only 827MB in size. This doesn't
>> take up much space and can be restored in a matter of just two or
>> three minutes from booting from the Paragon rescue CD. It's a far more
>> reliable way to roll back to a working system than winXP's flawed
>> system restore method.
>
>Yes, though, as they include all the software, my backups are much
>bigger, about 7-8GB. About half the used space on the system drive is
>normal for a compressed image made by, say, Ghost, or one of the free
>alternatives. You may be able to reduce the size by booting into the
>Recovery Console beforehand, which automatically deletes the pagefile,
>and as I don't allow hibernation, there is no hibernation file anyway.

I'm currently using Paragon Disk Manager 9.5 for this task and, like
the PowerQuest's Drive Image 3 utility I used to use before,
intelligently compresses these system files down to nothing (just size
and place marker info with total data loss - the ultimate in "Lossy
Compression" exemplified with mp3 and mpg compressed formats).

Most such partition imaging tools are capable of effectively removing
these particular files from the picture and do away with the need to
manually remove them beforehand. Like yourself, I also fail to see the
benefit of a hyberfile on a mains powered desktop machine.

>
>> One more vital post install configuration change that's well worth
>> doing is to establish a fixed size pagefile ... leave it in
>> the drive C partition). I typically set it to 3 times the ram size or
>> else just short of the 4GB limit (4095MB).
>
>Normal practice is simply to put it on the system (C:) drive. The
>recommendation is twice the installed RAM, or the maximum, whichever
>is smaller. I suspect there will little or no measurable benefit from
>putting the pagefile on a seperate drive, unless perhaps you are
>running SSD drives, and wish to avoid wearing them out. Unless
>there's some good reason, keep it simple and follow the
>recommendations.

That's more or less what I said. The main point I was making was that
there was no point in placing the pagefile on any other partition
space than drive C in a single disk system. It only makes sense to
move it to another partition when that partition is on another disk
drive where it will reduce 'head contention'.

It's also a good idea to shift the pagefile off an SSD onto a
spinning disk in a system that uses the ssd to speed up boot and
program access times alongside of a spinning hard disk drive to
provide the bulk of the data storage (user data and partition image
backups as well as system log files) in order to maximise the life
expectancy of the SSD.

>
>One more thing. If one has a disk larger than the 128GB limit, it's
>worth installing the XP Recovery Console instead of the W2k one, as
>that will recognise partitions that go beyond the 128GB limit. WITH
>CARE, once the system build is complete and all updates have been
>installed, this can be done as follows:
>
>1) Look in the root of C: and backup NTLDR to, say, NTLDR.W2K
>2) Insert an XP Pro installation CD and install the RC by going into
>a DOS console and typing ...
>
><CD Drive>\I386\WINNT32.EXE /console
>
>... answering any confirmations appropriately. You can allow it to
>search for updated files, though it actually doesn't seem to make much
>difference.
>3) IMPORTANT - When installation is complete, before rebooting
>rename NTLDR to, say, NTLDR.XP, and replace it with a copy of the file
>backed up in 1.

That bit is redundent. I'm actually using the winXP versions of that
file and the NTDETECT.COM as a means to shave about 4 seconds off the
boot time. Unfortunately the "Scuzziness" of SATA drastically
increases the boot time in win2k. In my case, I estimate that it must
be adding a good (bad, really!) 40 or 50 seconds making for a total
boot time from power on of some 90 seconds in spite of the SSD.

I have an ancient 1GHz Athlon based system using a MoBo deliberately
chosen for its single ISA slot to allow me to use an expensive and
very good Creative AWE64Gold sound card which is not afflicted by SATA
ports with a 400GB IDE drive which boots in about 60 seconds flat -
around the same boot speed on an ACER laptop just old enough to be
without SATA yet still recent enough to sport DDR2 ram. I find it a
little bit depressing that the much more recent iteration of my
desktop machine takes 50% longer to boot than that ancient desktop and
that not quite so ancient laptop.

Of course win2k's protracted boot to desktop times compared to
winXP's sleight of hand speedy boot time is rather misleading since,
unlike winXP, win2k will actually be responsive immediately after the
desktop appears rather than require another minute or so to become
reluctantly responsive so it's a case of "Swings and Roundabouts".

Despite this extra 40 odd seconds required to boot, I still prefer
win2k's better responsiveness and lower maintainance requirements to
the rather dubious 'delights' of winXP.

>4) Optionally, <Rt-Click> My Computer and choose Properties,
>Advanced, Startup and Recovery, and change the time that alternative
>operating systems are displayed to something more sensible like 5s, or
>edit the RO H S file C:\BOOT.INI to effect the same change.
>5) Run the Group Policy editor gpedit (may have to get it from the
>installation CD toolkit - I can't remember now) OR choose Start,
>Settings, Control Panel, Administrative Tools, Security Policy, OR run
>mmc and choose the console secpol.
>
>Whichever way you're doing this, open up the branch that ends Security
>Settings, Local Policies, Security Options, and set:
>
>Recovery Console: Allow automatic administrative logon = disabled
>Recovery Console: Allow floppy copy and access to all drives and all
>folders = enabled.
>
>Now if you have a bad, bad, system problem, at least you can reboot
>into the XP Recovery console and copy anything desperately important
>off the data drive.

As far as installing a recovery console, I find it all rather
unnecessary. In fact, the relatively frequent (around once every
couple of months or so) Licence violation errors that are caused by
using an SSD make such a recovery console redundent since fixing FS
errors on the SSD have had absolutely no effect whatsover on this
particular error which can only be fixed by restoring from an image
backup file thus neatly demonstrating that an image restore will trump
winXP's rather fragile system restore feature every single time.

[Java Jive]

On Mon, 25 Jun 2012 00:41:41 +0100, Johny B Good
<johnny...@invalid.ntlworld.com> wrote:

> On Thu, 21 Jun 2012 14:31:50 +0100, Java Jive <ja...@evij.com.invalid>
> wrote:
> >
> >IMV, there is a great deal to be gained in having seperate
> >partitions/drives for the system, including software applications,
> >and the data, but absolutely nothing to be gained by splitting it
> >three ways. As the vast majority of Windows PC software stores a
> >great deal of configuration data in the registry, and at that nearly
> >all of it in the same HKLM hive as nearly all Windows configuration
> >data, and as a single registry hive can only be stored in one place at
> >a time, there is little or no benefit and makes absolutely no sense at
> >all to complicate matters unnecessarily by installing the software on
> >a seperate partition from the system.
>
> This partitioning into seperate OS, Apps and Data partitions is a
> matter of convention and has no effect on where the various registry
> hives get stored - they remain on the system drive (conventionally
> drive C).

Exactly, as you can't seperate the software configuration data in the
Registry from the Windows configuration data, no matter where you put
the software, all its configuration data will still be in the Registry
on the C: drive. Therefore there's no point in installing software
onto a seperate D: drive, you might as well keep things simple and put
it on the C: drive along with its configuration data.

> >One more thing. If one has a disk larger than the 128GB limit, it's
> >worth installing the XP Recovery Console instead of the W2k one, as
> >that will recognise partitions that go beyond the 128GB limit. WITH
> >CARE, once the system build is complete and all updates have been
> >installed, this can be done as follows:
> >
> >1) Look in the root of C: and backup NTLDR to, say, NTLDR.W2K
> >2) Insert an XP Pro installation CD and install the RC by going into
> >a DOS console and typing ...
> >
> ><CD Drive>\I386\WINNT32.EXE /console
> >
> >... answering any confirmations appropriately. You can allow it to
> >search for updated files, though it actually doesn't seem to make much
> >difference.
> >3) IMPORTANT - When installation is complete, before rebooting
> >rename NTLDR to, say, NTLDR.XP, and replace it with a copy of the file
> >backed up in 1.
>
> That bit is redundent. I'm actually using the winXP versions of that
> file and the NTDETECT.COM as a means to shave about 4 seconds off the
> boot time.

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 the "Scuzziness" of SATA drastically
> increases the boot time in win2k. In my case, I estimate that it must
> be adding a good (bad, really!) 40 or 50 seconds making for a total
> boot time from power on of some 90 seconds in spite of the SSD.

Well, that's not my experience. When I changed my lead machine to
SCSI 160Mb/s, the boot time reduced noticeably, when I replaced the
SCSI with SATA 150Mb/s there was no appreciable change.

> Despite this extra 40 odd seconds required to boot, I still prefer
> win2k's better responsiveness and lower maintainance requirements to
> the rather dubious 'delights' of winXP.

Yes, I think there's more bloatware to disable in XP.

> As far as installing a recovery console, I find it all rather
> unnecessary.

My experience is the opposite.

> In fact, the relatively frequent (around once every
> couple of months or so) Licence violation errors that are caused by
> using an SSD make such a recovery console redundent since fixing FS
> errors on the SSD have had absolutely no effect whatsover on this
> particular error which can only be fixed by restoring from an image
> backup file thus neatly demonstrating that an image restore will trump
> winXP's rather fragile system restore feature every single time.

That seems to be an argument against using SSD drives rather than an
argument against installing the recovery console.

[Johny B Good]

On Mon, 25 Jun 2012 12:13:23 +0100, Java Jive <ja...@evij.com.invalid>

Yes, I see your point. It's been so long since this was more than a
minor issue that I hadn't realised it might not be so minor for
everone.

The point I was making was that splitting the OS and apps off into
different partitions (aside from those "Core Apps" that the OS
pre-installs such as wmp, IE and OE and such) means you keep the
compressed OS partition image quite small, a partition backup that is
the minimum required to successfully recover from almost any disaster,
even one caused by a dead disk drive.

You can make backups of the apps partition on a less frequent basis
if you don't mind having to re-install / reconfigure the odd one or
two "New apps" that got added / updated since the last drive D backup.

It's a lot less likely that the sort of disaster you're protecting
against on the boot drive will also apply to the apps drive. It's
really only the OS partition that benefitst from image backups, the
remaining disk volumes can be backed up using more conventional data
backups including the space saving incremental backup regime.

It's worth remembering that any backup scheme is simply to protect
against "The Unthinkable" (and, hopefully, extremely rare) event of
data loss / corruption whether due to disk failure or any other number
of causes.

I've chosen to place the OS and apps onto seperate partitions to
allow me to optimise the benefits of keeping both backed up on their
own seperate backup schedules. Any complications in "Tidying Up" post
restore onto a replacement disk drive will be a relatively minor
'inconvenience' AFAIAC.

If you're in the habit of making frequent changes of installed
software, the "Keep It Simple Stupid" OS and apps on a single disk
volume strategy will probably be a better trade off against the space
and time saving strategy of the seperate OS and apps partitions where
you can afford to make more frequent OS partition backups with
relatively infrequent apps partition backups.

At the end of the day, it's down to personal preferences and, if
you're setting up a system on behalf of a less skilled computer user,
what you think they're most likely to be comfortable with.

>
>> >One more thing. If one has a disk larger than the 128GB limit, it's
>> >worth installing the XP Recovery Console instead of the W2k one, as
>> >that will recognise partitions that go beyond the 128GB limit. WITH
>> >CARE, once the system build is complete and all updates have been
>> >installed, this can be done as follows:
>> >
>> >1) Look in the root of C: and backup NTLDR to, say, NTLDR.W2K
>> >2) Insert an XP Pro installation CD and install the RC by going into
>> >a DOS console and typing ...
>> >
>> ><CD Drive>\I386\WINNT32.EXE /console
>> >
>> >... answering any confirmations appropriately. You can allow it to
>> >search for updated files, though it actually doesn't seem to make much
>> >difference.
>> >3) IMPORTANT - When installation is complete, before rebooting
>> >rename NTLDR to, say, NTLDR.XP, and replace it with a copy of the file
>> >backed up in 1.
>>
>> That bit is redundent. I'm actually using the winXP versions of that
>> file and the NTDETECT.COM as a means to shave about 4 seconds off the
>> boot time.
>
>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) Created Modified

NTDETECT.COM 47,564 19/06/2003 12:05 13/04/2008 23:13
NTLDR 250,048 07/04/2012 12:28 14/04/2008 01:01
NTDETECT.COM.2k 34,724 19/06/2003 12:05 19/06/2003 12:05
NTLDR.2k 214,432 19/06/2003 12:05 19/06/2003 12:05

I did, as you can see, take the precaution of backing up the originals
in case this "Speed up fix" was a load of balony (or even some sort of
nasty joke) but the 'fix' does seem to 'work as advertised'.

The speed up was only a mere 3 to 4 seconds at best and clearly not a
solution to eliminating the 40 or 50 seconds scuzzy delay I was trying
to fix. However, even a mere 3 or 4 seconds is an improvement of sorts
and I've not seen any other consequences over the past two months or
so that I've been trialling this 'fix'.

>
>> Unfortunately the "Scuzziness" of SATA drastically
>> increases the boot time in win2k. In my case, I estimate that it must
>> be adding a good (bad, really!) 40 or 50 seconds making for a total
>> boot time from power on of some 90 seconds in spite of the SSD.
>
>Well, that's not my experience. When I changed my lead machine to
>SCSI 160Mb/s, the boot time reduced noticeably, when I replaced the
>SCSI with SATA 150Mb/s there was no appreciable change.

My first experience with protracted boot times with SCSI devices
harks back to the heady days of a P2/350 on a BX440 MoBo with an
adaptec HBA serving a quad speed CD writer and a flatbed scanner.

The boot process was, afaicr, taking about 3 minutes or so until I
sorted out the SCSI adapter settings which got it down to less than a
minute. Unfortunately, there are no such settings available with the
built in SATA controller to allow me to fine tune it to prevent win2k
seemingly going through a rather pointless 'discovery' exercise during
the time it displays its start up logo screen.

>
>> Despite this extra 40 odd seconds required to boot, I still prefer
>> win2k's better responsiveness and lower maintainance requirements to
>> the rather dubious 'delights' of winXP.
>
>Yes, I think there's more bloatware to disable in XP.
>
>> As far as installing a recovery console, I find it all rather
>> unnecessary.
>
>My experience is the opposite.
>
>> In fact, the relatively frequent (around once every
>> couple of months or so) Licence violation errors that are caused by
>> using an SSD make such a recovery console redundent since fixing FS
>> errors on the SSD have had absolutely no effect whatsover on this
>> particular error which can only be fixed by restoring from an image
>> backup file thus neatly demonstrating that an image restore will trump
>> winXP's rather fragile system restore feature every single time.
>
>That seems to be an argument against using SSD drives rather than an
>argument against installing the recovery console.

Well, it's an argument against _this_ particular SSD (a "30GB"
Kingston SSD Now V series drive). I don't know whether it's an
argument against _all_ SSDs in general (at least not yet).

The point here was that it was a failure mode I couldn't have
predicted (at least not without a damn good reason to research very
deeply into the many issues new to this technology) yet the partition
image backup strategy proved itself equal to the job regardless of
whatever form the disaster took.

Prior to using an SSD, I can't remember any event where my only
remedy was to restore from an image backup. I'm sure there must have
been two or three times over the decade prior to my fitting that SSD
where I was forced to restore from a disk volume image but I can't
recall any one particular event, just a vague notion that I must have
had no choice other than use a backup image.

Of course, I've restored from image backups where I've made the
mistake of installing questionable software as a guaranteed means of
rolling the system back to "Happier Times".

SSDs have serious issues over handling a reset during impending loss
of power regardless of whether it's a power outage or a system
shutdown, issues which simply do not exist for "Spinning Rust"[1]
drives.

A spinning HDD only has to, at most, terminate a sector write in
progress gracefully to avoid spurious 'bad sectors' and co-lateral
data corruption, a matter of microseconds, whereas an SSD has to
perform a cache flush to an erase block or three (maybe more) which
takes tens to hundreds of milliseconds. This requires a level of
reserve power 4 or 5 orders of magnitude longer in duration over and
above the HDD requirement which can be very comfortably exceeded by
the voltage supply hold up time from the main PSU during the time the
PG line becomes negated (triggering a system reset condition) and the
voltage rails eventually dropping below the minimum level for
guaranteed operation of the logic gates used in the HDD's controller.

An SSD aught to be able to independently provide its own reserve of
power to ride out such a shutdown event sufficiently to completely
avoid the risk of data corruption, especially since such data
corruption can effect totally "innocent data content", not just that
of the file caught out in 'mid flight'.

That 30GB Kindston SSD either relies upon the main PSU hold up
reserve time or else has insufficient built in reserve. Either way,
the reult of this lack of reserve has proven to be disasterous on far
too many occasions for my liking over the past couple of years that
I've been 'trialling' the SSD. Admittedly, the situation did improve
somewhat after I upgraded the PSU, leading me to believe this
particular model of SSD was more or less totally reliant on the main
PSU reserve rather than on a self contained one.

[1] an expression I've seen used by a certain poster using a two
decades out of date technology reference.