CLASYS

Thanks, eidenk.It looks close enough to work [cosmetic WinME reference aside ]. Where did this updater come from? It's a slightly nicer way to do a batch job equivalent for most things that you can do in a batch. However, when applying 98SE updates, there can be sticky spots to deal with. Here's a little snag: I assume you cannot do a file delete with it, but a batch can. In another thread I documented there are strange properties of a small few updates where unless you can delete a file placed by a particular hotfix, no newer hotfix [or even the SP 2.1a!] can fix the problem. Additionally, it also causes QFECHECK to act strangely supporting the incorrect version. Since I prefer to get as much QFECHECK info as possible [when are we going to write a QFECHECK manifest file for QFECHECK?], I install this obsolete update to obtain the QFECHECK stuff. Unless I can place a file delete command immediately afterwards, replacement updates [with newer non-problematic versions] later in the batch file cannot properly install [nor can the SP 2.1a later!] for the file [vip.386 4.10.0 2224 or later; the problematic update installs 2223.] So, is there a way to make this updater perform some file deletion routine [perhaps a batch job?! ] On looking at the updates supplied, I notice ample usage of updates such as to IE 6.0 SP1 using the familiar /q:a /r:n construction. Please note that this does not completely work, at least in some of the cases of updating IE 6.0 SP1. There are some combinations of updates that just don't install that way. If you perform the update manually, you get an error message, usually something about "This update requires Internet Explorer 6 Service Pack 1!" and it aborts. Using the switches just suppresses the error messages; it doesn't get the job done. This is why I devised the kludgy rebooting updater. By allowing a reboot, the problem goes away in certain specific instances where the updates were mandated to be installed in a specific order, with an intervening reboot. However, I do have an open question: Is it possible to make the updates work by an alternate method, such as passing the switches /n:v? Recently mgdx posted the Q329919 update, which I never had experience with before. Manually attempting to add it was rejected for a similar reason as above, but using the /n:v switch made it install just fine. [Of course this isn't a reboot problem; apparently the combination of other IE updates already installed ticks off the installer of the hotfix for some unknown reason. To that extent, it seems to be the same problem.] In any case, I was able to successfully update an existing system to include Q329919 [use IE help/about shows the update just fine after all the others already applied] so all appears fine via this newer method, etc. For a new install, I intend to figure out what updates to IE/OE are "tolerated" by the Q329919 update as preinstallation-acceptable "prerequisites" meaning what seems benign to the install process to avoid the need for the /n:v switch. Assuming this can be accomplished, then admittedly this would be one step closer to not needing the kldugy reboot between updates. [Remember, the kludgy thing always reboots between all updates, but clearly some need the reboot, and it's more work to figure out which ones really don't and which ones really do need the reboot, thus it's a generic kludge, etc.] In any case, the main point to make is that installing IE updates willy-nilly merely depending on the quiet mode of /q:a /r:n does NOT always work, whereas certain combinations regardless of option switches WILL work as long as there is an intervening reboot. Thanks to all of the recently posted updates and kudoes to all who have gathered them up. By my latest count, there are now 47 fixes to IE 6.0 SP1 beyond initial install OFFICIALLY and 2 more UNOFFICIALLY that fix stuff MS chose not to give us non-XP versions for. [Yes, I know that not all of them are unique, but all 47 will give IE help/about information, and clearly it's not just a matter of two streams of cumulative updates, one for IE, and the other one for OE; rather there are a bunch of one-off updates as well, and apparently not all of them are posted in any single place I am aware of.] I need to get my act together to make the kludgy thing a bit less kludgy, and then will release it here. [it only does 38 or the updates because I haven't had time to add on the newly posted ones and some done in relatively recent months; I'm just now running at about 2/3 speed with regard to keeping up with all of the bursts of wonderful activity here; please bear with me as I contribute questions and answers to tbe best I can offer, etc.] Can anyone give me information on how to batch [or use this nice updater!] for the two unofficial updates Q905495 and Q911567 in terms of option switches they might need to run in "quiet" mode or whatever? To be included in the list-of-49 hopefully! cjl

thanks for the info.So Browseui.dll comes in Q867282 that I already installed over the original IE 6.0 SP1 and Browselc.dll stems from the original install? And Browseui.dll from the IE 5.5 SP2 version of the Q867282 is the replacement as is the original IE 5.5 SP2 install being the source of Browslc.dll replacement? Thus, any discussion of newer files from other sources [iE 6.0 family-derived, etc.] is incorrect? I understand the technique, just wanted confirmation of the exact files to use, since various references have been made, each appearing to be "authoritative" only to be found short-sighted and obsolete, etc. cjl

I was away from the forum for awhile and missed this entire thread. Anyone have a copy I can download? cjl (large files don't scare me!)

It is part of IE 6.0 SP1. Petr Thanks PetrI almost missed it in HHUPD.CAB because it's inside of the mui.cab inside of that, and only the 0409 [ENU] version is that date [the rest are much older in the release!] Anyone know why the main IE cabs [the ones with an S in the name, IE_S1.cab, etc.] are wholely imbedded within as another complete cab file [same name only the S is removed]? cjl

In light of this, two things:[All of this is on 98SE] 1) Assuming IE 6.0 SP1 is installed, complete with all of the other known patches except MS06-013 (912812), what is the simplest way to get the benefits of 912812 without the urlmon problem? [Note that urlmon.dll will already be from 905915 in this scenario, if that helps!] Will doing so make WU believe I have installed 912812 so it won't bother me again about this? [Theorize: If 912812 is ever fixed by MS, will WU know to tell us in the future to download the fixed version? And will it install over the fixed-up system which isn't the "pure" 912812 situation?] 2) With all of the updates, what --today-- is the best way to handle the 98SE explorer freeze problems, i.e., to change BROWSELC.DLL and BROWSEUI.DLL? [Where do the "best" replacements come from?] cjl

Just to clarify: SP 2.1a wants to install: hhctrlui.dll 5.2.3635.0 20-May-2002 11:09:38 AM [presumably derived from Q323255 and/or Q811630.] Before installing SP 2.1a on this system, OTHER updates primarily outside of the SP were installed [iE 6.0, XML and MDAC updates, etc. to name a few]. As a result of these OTHER updates [but I have no idea which particular one of them at this point], the SP 2.1 allowed me [correctly!] to prevent modifying the file already present: hhctrlui.dll 5.2.3664.0 26-Jul-2002 11:02:46 AM Considering the "age" of both of these files, I would suspect that this newer version of hhctrlui.dll is a stable file to be included within the SP in a future release. Anyone have any comments here, i.e., which specific update provided the file, and whether the inclusion into a future SP makes sense, etc. [Note: While I don't know where the file exactly comes from, I am certain it is official MS release for something known to be compatible with 98SE.] cjl

Can anyone compile a complete list of which hardware/software combinations are capable of supporting larger than 137 GB disks? As I understand it, all the following is true: 1) Any one partition on the disk cannot be bigger than 137 GB, largely due to restrictions within Scandisk and Defrag. Any other problems per se? [Would there be alternative programs that don't have the problem, such as DISKKEEPER and/or some Symantec/Norton utility? I know that certain Symantec packages subsititute I believe Norton Disk Doctor for SCANDISK throughout Windows. And what of the DOS-based SCANDISK that runs on 98/98SE [not relevant on ME!]. 2) It doesn't matter where on the disk these partitions are, just the size of any one of them; split the disk up any way you feel best. 3) DOS and safe/forced compatibility mode don't need anything fixed; they just work. A question: What about defraggers for DOS and large disks? And what of DOS chkdsk and scandisk [pick any relevant versions from MS-DOS, PC-DOS, FREE-DOS, DR-DOS, etc.]. 4) 32-bit mode needs a 48-bit-aware driver: a) Mr Lowe sells a patched ESDI_506.PDR version for most systems. [i am a registered user.] b ) Intel application accelerator works for certain specific Intel chipsets [can anyone give the exact models?] c) Perhaps something from VIA does this, or does it merely interfere with anything else? [Mr Loew intimates that perhaps it not only doesn't work, it prevents his item from functioning. He also disputes the 98SE hotfix to correct FDISK for larger disks actually completely works beyond some specific size that could be relevant here.] d) I would appreciate something for my AMD chipset-based system [that is skirting the issue by using a 120 GB disk currently]. There are drivers from AMD, but I don't know if any of them deal with 48-bit. e) Just about anything USB 2.0 or firewire external hard disk in a box just works in Windows, as long as there is an appropriate driver. However, for DOS, the driver situation is muddled; some drivers work fine for some hardware configurations, but it could be quite specific. Some drivers hate certain card/disk combinations, some hate certain cards period. Some drivers only support 127 GB and down, others work totally fine. In my own experience, the recommend DOS drivers are those associated with the fully live-updated version of Ghost2003, allegedly coming from IOMega, to Symantec. The firewire driver works amazingly well, on such disparate hardware as Sony VAIO laptops, to common garden variety VIA chipset firewire 400, to SIIG's 64-bit transfer PCI FireWire-800 card that in my AMD system causes noticeable throughput improvement in the 64-bit PCI slots, even from DOS! [using FW800 hardware throughout.] But cheap ALI chipset USB cards only work if the disk is less than 127 GB. The driver totally hates the VIA chipset built into Tyan 2495ANRS USB 2.0 regardless of disk size. And some drivers hate intervening USB hubs! All USB cards based on NEC chipsets seem to fare the best, including DOS large disks, etc. f) Add-in cards such as the Promise TX2-Ultra 100 and 133 work fine supplying their latest drivers to 98SE. [Note to owners of the 100 version: Use the 133 card's driver; the Promise website is misleading on this point.] I use the Promise driver to access larger disks just fine in XP as well as 98SE. [Not a boot drive for 98SE though. XP in theory could do it it is claimed.] [Note: XP will not identify the 133 card at all, but it will misidentify the 100 card; beware of not using the driver!] BIOS support for DOS works fine [upgrade the ROM to the latest version on their website.] Anyone tried SIIG, Addonics or High-Point equivalents? To my knowledge, the only known 98SE-friendly SATA II [300] card comes from Addonics, but there are some SATA I cards that are. Presumably certain machines have SATA support in the BIOS that might work with any of the above. In any case, these are on a case-by-case basis as to whether they support 98SE and hard disks of any size, much less greater than 137 GB. A side note: Partition Magic 8.05 will refuse to make a FAT32 partition bigger than 196 GB. Can anyone explain this number? [FDISK from a 98SE startup disk will make a full 250 GB into one partition.l] Partitions larger than that number seem to give WinXP some problems as well [perhaps that's the explanation!?]. I apologize for any errors in the above. Can someone correct/elaborate/add on other hardware known to either work or not work, etc. cjl

Is this perhaps a vcomm.vxd problem?cjl

Where does MPC 6.4.9.0 stand with regard to the mega-codec pack? [And 98se in particular?] cjl

Not the point, since yes, of course you keep the newer version. The problem here is that some update NOT in the SP is already installed, and it's at a higher rev on the particular file, in this case hhctrlui.dll. The SP is attempting to do the work of 323255 or, better still 811630, both common updates that also would cause the same result. I am asking if anyone knows what this even newer update not found in the SP is that supports the even newer file rev. This is solely for the purpose of the future of the SP, not anything else. Other than a known sore-point update [known to cause problems where not warranted, and to be applied only on certain laptops], the SP tends to be the latest rev of just about any system file it affects. [Actually, there was a mouse-support file that had a similar problem, but in this case the revision was grossly newer, and actually part of a package, not an O/S update, for which the other files had to accompany this "too-new" rev file to avoid problems. Fortunately, the issue was solved by obtaining the proper rev file as intended in the update it was derived from, etc., so this isn't even a current issue within the SP, etc.] If someone knows what other update [perhaps an XML or MDAC update? or perhaps IE 6.0 SP1 + updates] perhaps it would be justified to be added into the next release. This is similar to the issue about the 269388 update. If that is installed first, you get a similar warning because the SP is actually attempting a lower rev than that update. However, 269388 is already scheduled to be in a future update already. To my knowledge, the hhcrlui.dll file doesn't have the same status, thus the need to discuss whatever the actual source of this file is, etc. It's just not always true that a newer file can be used just because it's newer; in this case, since apparently it was installed by some other update, it is likely true in this instance. The file in question seems to be part of some help center update; the revision is curious because 323255 and 811630 have other files at the same relative revision, almost as if this file was "intended" to be updated to this still-higher level. cjl

As a long-term denizen of the no-phone-line-modem-limited Internet, I officially welcome you! Happy downloading! cjl (Optimum Boost - Upload 2.1 MBps, Download 28.4 MBps, FIOS not yet available)

Installing the SESP2.1a on a machine already containing many updates. During the install was prompted to replace hhctrlui.dll (recommending to keep current file) because it is version 5.2.3664.0 [per se, this makes sense because the SP uses 5.2.3635.0]. My question is: what update has this file in it that is past the SP? Should this version be included in a future release? Any way to figure out what update installed this file? Nothing appears to be wrong, just I thought SP is supposed to be at latest rev on everything [is that wrong?] like this, other than newer-still recently released updates [which I can't find any contributing this newer file!]. If this helps, the file is in \windows\system\mui\409. cjl

And a whole lot less trouble. This is off-topic for this forum, but I have a relatively undinged XP system that really doesn't want to be reinstalled from scratch, assuming that would even help. The only thing known wrong with it is that any Adobe version 6 or 7 all have been installed then deinstalled then reinstalled to no avail.The problem is that it won't support the ability to do a normal print without fudging some seemingly unnecessary advanced settings in the printer [which is an HP laser-Jet IIP with the built-in support]. No other programs exhibit this behavior, including Foxit which just works fine as is. No problems with Adobe 6 on 98se on the same hardware. [98se is used as a maintenance system on this particular machine.] cjl

Since you can get into safe mode, use MSCONFIG to turn off everything that starts. See if that breaks the cycle; sleuth until you find the looping culprit [likely sfc-related]. Hope that helps. cjl

See if you can get into safe mode [hold control as it's coming up until you get a menu to appear and select safe mode] and hopefully it will stop looping. If so, then use MSCONFIG to turn stuff off. Assuming all that, you should be able to turn off the culprit, likely regarding SFC as you surmised.Good luck, cjl

Just sleuthed out some sticky interactions involving dcom98 and indirectly related updates. As many know, currently the Unofficial Service Pack doesn't support QFECHECK information for the underlying updates. Thus, some [including me] are interested in the installation of the readily available updates independently [hopefully in unattended batch files] to establish the QFECHECK information. [QFECHECK is available in virtually every update package; you only need it once. It gives you an opportunity to see problems where installed updates flag installed files that become either missing or too-low versions. It mostly accomplishes what it sets out to do [but not completely!].] In the course of creating [admittedly somewhat redundant to the SP] these batch update files, I have found a small few sore cases. Here's one I found to watch out for: There are two updates to 98SE that are the source of the file RPCRT4.DLL, Q258191 provides 4.71.3331.0 and Q269874 provides 4.71.3336.0 [and apparently is the source of the file as found in SESP2.1a]. I generally put the updates together in a batch file containing a bunch of lines like: START /WAIT 269874usa8.exe /q:a /r:n and expect to boot once after it finishes, etc. It didn't seem to work out correctly, because the file RPCRT4.DLL was being set back to version 4.71.3328.0 seemingly out of nowhere. [More below on exactly why what was stated was yet another problem.] I finally traced it down to update 315575, which nominally does NOT update RPCRT4.DLL, yet it CAN! Unless DCOM98 1.3 is already installed, the 315575 update runs an internal copy of DCOM that will also attempt to update RPCRT4.DLL, but it's a deferred update until during the next reboot. Since I used all three updates in the same batch, the back-dating of RPCRT4.DLL from 315575 [from the DCOM98 within] won out after the reboot. The fix is to first run DCOM98 explicitly before any batched updates. [DCOM98 requires a reboot; I doubt if anyone can provide a way to prevent this reboot, or at least make it not mandatory; I don't know how to suppress the reboot requirement, yet 315575 itself supports the proper switches to do it overall just fine, etc.] So, the final batch does run the same three updates, in numerical order, if that should matter. Since DCOM98 was accomplished on a prior reboot, all installs as expected [after a single final reboot]. Now back to the QFECHECK problem: This is now the second occurrence of an anomaly where somehow QFECHECK is thwarted and will not complain when there is a legitimate problem you SHOULD be seeing. The above [un-repaired version] example installs 258191 and 269874 [and also 315575 that caused the problem without a prior DCOM98 install] winding up with RPCRT4.DLL at the incorrect revision of 4.71.3328.0. Within the QFECHECK output, totally correctly the 269874 reports the 3328 as invalid [since it requires 3336]. However, 258191 seemingly has no problem with 3328, yet clearly it requires 3331 or better. If you delete RPCRT4.DLL, the QFECHECK report becomes correct: Each of the two updates complains the file is now MISSING and each indicates its respective required minimum revision. Anyone able to shed any light on how an update can fool QFECHECK this way? The other known situation is when you install Q238329, it installs VIP.386 version 4.10.0.2223. But installing this update prevents the file update to still higher revisions associated with Q238453 [2224], Q242962 [2225], and Q2259728 [2226 and apparently the source of the file for the SESP2.1a package]. Even the SESP2.1a package itself cannot fix this! [The only way to fix it is to just delete vip.386; any newer update will then put in the update-appropriate version, including the SP. Fortunately, this file is generally not in use so you can easily delete it from Windows. I delete it in the batch update file after I install 238329 to get the QFECHECK information, and all is fine, etc.] Not fixing the above problem reveals the same ill behavior of QFECHECK. All of the mentioned updates work the same exact [totally incorrect] way. If VIP.386 is actually present at the 2223 level, all the newer updates aren't complaining about this and seem to like the 2223 level just fine. And deleting Vip.386 makes all of the updates work properly, each reporting MISSING and requiring their respective minimum required levels; any of the newer updates [or applying the SP] fixes the entire problem. But this is just "burying" the QFECHECK problem. The point is that QFECHECK is supposed to be trustworthy to reveal updates that are corrupted, missing, or accidentally down-graded. To the extent this might involve either of these two files, QFECHECK cannot totally be trusted. [Note: There is a side issue to the weakness of QFECHECK: There is no indication within QFECHECK whether the indicated revision is merely the minimum requirement or is perhaps somewhat higher. Unless you have QFECHECK information for the HIGHEST installed revision being the minimum requirement for some update, it is possible for a file to be down-graded and yet find no errors in QFECHECK; the one requiring the actually present file will flag it as an error when the file gets down-graded, but prior updates won't because they don't require that high a level, etc. This issue does come up because there are apparently some update files in the SP not even associated with a specific update package for which QFECHECK info even exists. Unless and until the SP provides QFECHECK information to cover the provided revision, these cases can never be flagged when the accidental down-grade occurs. This same situation will happen with packages like 982ME and the like. By providing a QFECHECK manifest file, all of these problems can be averted. However, this assumes the problem associated with the two files cited doesn't happen!] These two problems likely have something to do with some .inf file issue in their respective installers. Awhile ago I sent Gape the VIP.386 problem update because that early update is obscure; I can give it to anyone who wants to see for themselves; the RPCRT4.DLL problem appears in a more readily available update; I can provide it as well, etc. cjl

Actually. I found it inside of an HP laptop massive update, so that seems to be the same thing; thanksBut no KB article to take some relevant verbiage from [i like to describe them, etc.] cjl

Dunno if this is already covered territory: Any information about KB269388? [i have 269388USA8.EXE.] It appears that the SP 2.1a gets us to Q259728 [vip.386 4.10.2226] while 269388 gets to vip.386 4.10.2227. I can't find any KB articles for this one. cjl

Actually, I stumbled upon it much later than that, well into the 6.x-7.x era, and I wasn't sure if was official or perhaps a joke? [What, if anything did it do beyond the 4.79 we all loved/hated?]cjl

So, assuming you have an XP system installed on a compliant box-maker's machine [sLP] you never were prompted to activate, and you never will. As such, make all the copies you want, since it will work on your HP machine [and not on non-HP hardware from that era; I mention this because HP is sorta Compaq also, so unlike most other box-makers, HP/Compaq essentially breaks down into "provinces" etc.]. The trick is to get it all copied. Here's a freeware way to go: Partition your USB-based disk the same way as the booted internal HD. Again, since this is a box-maker's machine, it's guaranteed to be a C:-based system [which is something I never use; there are no good reasons for using C:, other than bad habits MS has been trying to get us to break for almost 20 years!], so you are in essence trying to clone drive C: and not much else. Without the worry of activation because it's SLP, it is NOT necessary to even worry about cloning the volume ID, since the whole process is moot. However, if you had the second hard disk temporarily hooked into the box directly, GHOSTPE or 2003 should have been able to clone it correctly. So, the easy way, since again, no activation worries, is to just hook your partitioned USB hard drive up, make sure it really is the same, including making sure the same active partition is set, etc. and to merely clone the contents of the C: drive to the primary partition in the USB box. This can be accomplished with the freeware program XXCOPY using the command XXCOPY /CLONE or XXCOPY /BACKUP. The only remaining problem is that the partition boot record isn't set. [Again, GHOST should have worked; it would have done this too!] The only way to accomplish this is to run the recovery console, which can be accessed from a bootable XP CD-ROM of any vintage. [The problem is that while there needs to be a Master Boot Record or MBR on the partition-table-containing master boot block, which is the code that boots up your machine based on looking at the table contained within the code, there also needs to be a partition boot record in your partition, and this is NOT a file. This boot record is the one that is searching for the NTLDR file and finds it elsewhere on the partition, loads it into memory and starts it up on its merry way getting the rest of your system up from identifiable files, etc. Back in the DOS/Win9x days, this was done with the SYS command from DOS, but in XP has to be set in the boot partition itself, so you need that recovery console if you cannot boot, etc.] Please note that any aborted installation that gets up to the point of asking you to continue setting up an XP install has already given you a formatted C: drive and that boot record. If you place your hard disk from the USB into the main box and subject it to that subset of an install, then all that is done. Then, put the disk back in the USB box and replace the original hard disk back in the main box, and let XXCOPY move all of the files and you should be set. cjl

There needs to be a major clarifiction about the so-called SP3 package. Many people really don't understand what's really going on here: 1) Microsoft has very low credibility with regard to actually maintaining Windows - ANY VERSION! 2) The so-called SP3 package is major damning proof of this with regard to XP. 3) What Microsoft currently offers through Windows Update is widely believed as an authoritative copy of what you need to patch XP so it is "perfect", no more and no less. This is patently wrong! I am one of the contributors to the Unofficial Win98SE Service Pack. The reason it even exists is that Microsoft hasn't had a service pack for ANY member of the Win9x family except for a brief flurry of relatively minor activity early on in the era of Windows 95 where it went from 95 [now known as 95 0] to 95A. By PURCHASING 95B or eventually 95C we got slight improvements, and yes, there were some hotfixes, but nothing ever rolled any of it up, and worse, a lot of updates were never released in any meaningful way. Hardy individuals obtained them in various ways, no thanks to Microsoft. While there is interest in Windows 98 [aka First Edition] or Me, most of us in this arena want 98SE because we consider 98SE superior to the versions before and after. [And some are "grafting" the best ME has to offer onto 98SE]. Again, no service pack ever happened, so we are writing our own. As has become the custom since the days of Windows 95, Microsoft often actually fixes many things and then "hides" them from the general public. We have all heard the language about "regression testing" and related deflection of responsibility, but the point is simply this: a ) Microsoft has actually assigned people to fix known problems, probably from people willing to shell out support money to report a bug. There often is a fix. b ) You probably won't be able to get it, or at least get it easily. Go read thousands of Knowledge Base articles that basically say over and over again, that a specific problem fix exists, but not for you! c ) Someone in Microsoft is making decisions as to which ones are "important" enough to rise to the occasion of being included into some more "official" list that often results [sometimes incredibly late!] in inclusion into Windows Update. As more and more problems appear, fully expect the priority of any of these updates to drop. They are simply running on gross overload. Back when 95 and 98 and SE were being heavily worked on, virtually all [not literally all!] updates were thoroughly tested enough to be considered safe enough to apply, even if you didn't "need" them. They were either benign or beneficial. At some point in time, quite a few of them were even appearing in Windows Update. However, due to the general sloppiness of Windows Update, some fell through the cracks only to never be seen again, and not superseded by a replacement update either. This is not an official "withdrawal" because a problem was found, just a "lost" update problem. So, today, with the emphasis on XP and company, what is happening is merely that Windows Update, which actually has a shoddy record in general, is getting worse. Here's a few tidbits: 1) Some updates used to be in Windows Update. They aren't there now, aren't part of SP2, not replaced, just gone! 2) Some updates were relatively recently added to Windows Update. However, the actual updates themselves have been available [quite difficult to get your hands on, but not impossible!] for as long as nearly a year before Windows Update finally added them very belatedly. [As I stumble upon them, I maintain a list I call "Why isn't this in Windows Update?" because they seem to be general purpose, sometimes even the subject of a security problem or clearly are a clear fix to a problem that ought not to be withheld because it could be risky, etc. Some of these have "graduated" into actually appearing in Windows Update, while some were "demoted" back into my list because they no longer are in Windows Update.] 3) Some updates are in Windows Update, presumably because they WERE tested sufficiently to be trusted. Yet, they had to be replaced because they are actually buggy despite the claims. [Go read Knowledge Base articles with titles like xxxxx doesn't work after applying hotfix zzzzzz.] So, we have a dichotomy here: Articles are withheld because they haven't been tested enough as a general policy, selectively applied. Other articles are claimed tested enough only to find that this was wrong and need to be fixed because they cause more harm than good. This can only lead to a distrust of Microsoft "recommendation" as might be ascribed to membership at any particular time in Windows Update. And conversely, an update not ever offered by Windows Update may be perfectly valid, but wasn't ever entered into the "popularity contest" that is an unfortunate aspect of Windows Update as practiced currently. So, what of the so-called SP3 collection? It consists of literally hundreds of hotfixes for problems ranging from clearly narrow-focused problems that affect only a few users, but probably are innocuous to apply if you don't need them [or perhaps not!] to common problems most people would agree might affect them. In the latter category I have actually experienced some of the problems and found the hotfixes did fix the problem as advertised. Many of these updates break down into several categories: 1) Fixed only to be cared about by XP clients of domain servers. Some seem quite serious and were probably reported by money-paying corporate clients to fix real problems. They likely work but admittedly only are needed by this segment of users. Loose machines and peer networks need not care. 2) More general networking which applies to a larger audience. Same considerations, just that more users may care. 3) A small category of newly discovered bugs dating back to the original release now fixed. 4) A distressing category having to do with a whole lot of things broken in XP as of SP2 [see below] that only pertain to laptops. I find these generally to work and fix a lot of problems with regard to suspend-related problems and the like. 4a) Related subcategories such as fixes that clearly fix problems with Firewire support [and seem to work fine; many are merely registry settings as workarounds so you need not work around, etc.] 5) This is the most distressing category and is partially related to 4), fixes for problems CREATED by Service Pack 2. Back in August 04, many people were complaining that SP2 broke their machines. Microsoft did damage control and claimed everything from misinstalls to "your third-party application is broken and not compliant; SP2 just enforces rules that weren't enforced before". Yet, a lot of people were still grumbling that things were better before SP2. It appears that as early as September 04, there has been a steady progression of hotfixes that clearly show Microsoft's position as a flat-out lie. This seems to be a major segment of the so-called SP3 collection. In all, the SP3 collection shows that literally hundreds of things are broken, well, as long as you define that the definition of XP is XP as augmented by Windows Update. Many have warned that you should not apply all of these updates. This is totally correct. Not all of the updates are final and some really haven't been tested. Moreover, if you do the research by actually reading the Knowledge Base articles, you find that these hotfixes include obsolete versions. I am assuming that a recently revised Knowledge Base article's information is to be believed. If it indicates a revision of a replacement file as x.xx or better, it's likely correct. However, some of these hotfixes have older digital signatures and are apparently not the latest version of the hotfix. Moreover, this does tend to indicate some work is being done, since at the bare minimum, there are at least two releases beyond XP SP2 of the relevant files. Generally, hotfixes that raise the revision level of most files can be trusted to implement fixes embodied by former changes to the same files as described in other fixes. In that sense, it is possible for a series of events to create a latest-date collection of files that supersedes all previous versions of all of the files in the collection. Thus, it is possible that some of these hotfixes are totally obsolete, albeit benign, because the affected files were further updates by other updates. There are a small number of hotfixes in the SP3 package that are obsolete by this notion, but it's not a significent percentage of the collection. By and large these hotfixes just show that Microsoft has essentially made half-hearted efforts to fix literally hundreds of things, many broken by SP2, yet this fact is largely denied. And what about the ACTUAL SP3? Arrogantly, several months ago Microsoft announced that there WILL be an SP3, but only AFTER they release Vista, now put off until at least Jan 07, [i wouldn't hold my breath for that date being real either!]. If the track record of Microsoft is consistent, many, but not all of these fixes should -- then -- be embodied in SP3. SP1 and SP2 listed things claimed to be fixed when they were released. Both of them broke things, many more in SP2 than in SP1, and both failed to fix things claimed to be included in their long list of things claimed to be fixed, and both failed to include things that should have been included, some of which even remained in Windows Update after SP2 was applied! I consider Windows Update to be a cruel joke; the main thing is to understand just how irrelevant it actually is in the overall scheme of things. Microsoft has a vested interest in keeping as many people in the dark as possible about just how much of Windows is ACTUALLY broken and not yet fixed. So, Windows Update is considered the bellweather of just how rosy they want to believe the situation is. The SP3 hotfix collection proves just how lousy things are. cjl

SLP copies don't get activated because they are OEM/SLP. Are you saying you installed XP Home yourself on a machine that did NOT have XP Home before?If the copy is an OEM-non-SLP type, there is no guarantee that the reactivation will work [regular OEM, as opposed to SLP do need activation, just like retail full/upgrade types do]. OEM copies have no way to tell MS manually/easily because you aren't supposed to be moving the licensed copy to another machine, etc. [i suppose you could argue with them, such as your disk and motherboard and NIC all got replaced at once, but it's still "the same machine" etc. In any case, MS wants us to be "policeman" and refuse to even attempt to move a licensed copy to a "different" machine. The problem is the spin in what constitutes a "new" machine. It would appear that if you WANT to be on a new machine, just get a "new" hard disk, CPU upgrade, and/or motherboard. But if you want to be on a REPAIRED old system, then you have to argue that it was mandatory due to damage, and the more stuff that still is the same the better; this includes hard disk volume ID, NIC address, which are factors you may have some control of. Of course if your primary NIC is part of the motherboard you replaced, you are probably SOL on all three, leaving only the hard disk voume ID on the system partition, which is NOT necessarily drive C:; that';s where BOOT.INI must be; the system partition is where the \winnt or \windows partition is, etc. and of course for some they are one and the same, etc.] In any of the other activation-worthy scenarios, you have a perfect right to tell them you reinstalled the software; any actual hardware similarities would vindicate you. Obviously, if you reformatted your hard drive [as opposed to merely emptying it and/or truly cloning it] the related points of similarity that trigger a reactivation would be different. In essence, activation goes something like this: No need to reactivate if enough "fingerprints" are identical; the ones that change are adapted into what is expected next time. I think the time period for this "growing process" is something like 90 days or so; this alllows you to slowly reconfigure your machine. As long as you have some lower threshold of similarities, the activation process needs to be performed explicitly, but it will succeed. This is where you may be making a phone call to India; be prepared to tell them you are reinstalling on the same machine. That a few points of similarity still exist means they will find you credible. If you have few to none, there could be a problem, but if that's the case, AND it's a retail copy, then your position is that the machine it was originally activated on doesn't actually exist [anymore, in the original form that is], and you "forgot" that you had your box major-upgraded and didn't realize you needed to tell them that, sorry! So, unless this is an OEM copy, i.e., it is a legal retail full or upgrade, don't sweat a reactivation. And again, HP machines are subject to SLP, unless of course you never got a copy of XP with that box and this is an upgrade/replacement of a former system. cjl ps: If you are truly cloning the system, that means you are moving the [i think .DBL stuff] current activation file. On every boot it checks to see if reactivation is needed because the system is now different "enough" to go through the process again [but will succeed if still close enough, just no longer close enough to not need reactivation]. If you really cloned it and there aren't any other changes, it should pass with either disk. [i don't know if the hard disk ID itself is a fingerprint, just the Volume ID; you can't change the former, but the latter you can clone!]

Here's an answer that you probably never expected: Since you mention this is an HP machine, that means it uses an SLP key. In essence, if one understands all of what that implies, it is possible to completely reinstall an infinite amount of times without anyone or anything the wiser. This is one of those things where the enforcement is weaker than the license would allow. No actual piracy is even possible, unless one has a slightly older HP machine, since it would only work on the original and such a contrived machine [that you probably don't even want XP on due to being too slow!] All that said, there is a more fundamental issue here: It is totally true that XP is NOT a self-sufficient system! If you are foolish enough to think otherwise, ponder the following actual case history that has cropped up more than once in our "modern" era of too-smart viruses: A system got malwared and virtually every anti-spyware/malware program anyone ever heard of was run, and some nasties were detected and even eliminated. Eventually, all of them proclaimed the system to be totally free of problems. Only one problem: It was a lie! A really, really nasty virus had attached itself to Svchost.exe in such a nasty way that it stealthily was there and nothing could find it! The way it was found was by installing another system on another partition. The infected partition appears as a data-only drive to that maintenance system. Running Trend Micro Housecall on the maintenance system quickly identified the problem. Removing the infected file and replacing it with a stock one totally fixed the problem, etc. The only way to even have a maintenance system comes down to one of only a few cases: 1) Create an illegal maintenance partition [and deal with the consequences/limitations]. 2) Buy the software twice for use on the same hardware one at a time. Even though the second one is only used when the first one is not running, and only then for limited purposes, since the maintenance system cannot access the installed programs on the other/main system. 1) sounds unethical, but is 2) ethical, essentially doubling MS's profits? If SLP considerations aren't relevant, AND you know what you are doing, it IS possible to create a solution that doesn't involve 2) and creatively brings up the issue about just what 1) means: Install XP, but not the way most people do so [and ultimately it's just a bad habit, since it buys you nothing but "familiarity" to do it the usual way; I generally avoid that!]. The answer is multiple partitions. Create a tiny C: drive. 39 MB will do fine. Ultimately it can be trimmed down to the minimum 7.8 MB with Partition Magic after the fact if you are a fanatic. [The install requires 30-odd MB on C: but only about 1 MB after installation; the minimum one-cylinder partition is 7.8 MB on a modern HD, etc.] Install your intended XP on a higher-still drive. I use G: because I define F: as a maintenance partition. The others along the way are defined for other purposes outside of the overall method, but you might want to create these other special-purpose partitions along the way, etc. In any case, it is necessary to create a small dummy partition eventually somewhere before the F: drive, so you have to leave a space for it, but at this point, do NOT create it, just the empty space [again, need only be 7.8 MB]. At this point, the G: drive gets the normal XP installation, and the F: drive is visible to the system as F:. Boot.ini is created to count partitions from the beginning and correctly identifies which partition it is, etc. Now, using a variety of methods, clone the contents of G: onto F: and you have a copy of the system which will NOT boot [not yet!]. [Do this after all activation considerations!] Your main system is the G: system and the F: system is your maintenance partition. How to make it boot? Now make that dummy partition someplace after C: and before F:. Edit BOOT.INI to make the system bootable again, so that the overall partition head count is accounted for, since BOOT.INI merely counts partitions, not unhidden partitions, ANY partitions count. Or, leave BOOT.INI alone. In which case, F: is NOT F:, it is G:! If you want the overall reckoning of drive letters to be perfect, make sure that the dummy is hidden when your main system is in use, and non-hidden when the maintainence function temporarily transforms F: into logically G: which is needed to make that work. [in XP only, all works fine even though the former F: drive is a cloned G: drive; there just isn't an F: drive in the maintenance mode if the volume remains hidden. But, if you like consistency, unhide the dummy during maintenence operations and it becomes F:, assuming it's physically located just before the main F:/G: partition, etc.] Or better yet, make an entry for both systems in BOOT.INI and choose which to use every time. [Again, notwithstanding the fact that unless you change the status of the dummy partition, there will a discrepancy on one lesser volume depending on whether it's hidden or not.] Note that this method does NOT work on two C: drives unless you can convince it that the "other" one is visible while one is booted, especially when the maintenance copy is in effect. The point is not to get the maintenance system booted, but to get it booted and also to "see" the main system partition as a data [non-boot] drive. [My method has the added bonus that the main sees the maint as a data drive as well.] A side advantage of doing it this way is that C: has static contents; if you suspect malware, just replace the partition; the files should fit on a diskette. Certainly as a small .GHO image, etc. In any case, the overall idea is to circumvent MS's heavy-handed approach where to prevent piracy at all costs, you have to pay twice to use it once at a time, unless you resort to a method they might cry foul to in various degrees depending on just how you circumvented this particular aspect of "piracy". If MS wised up, they would allow an alternate method where an alternate installation on another partition checked and found that having a "twin" system was not a problem on the same exact machine. cjl

Didn't want to stir up the hornets! spacesurfer is correct. The problem with any and all other methods is that this is one of those "special" icons that plague us in every version of Windows. "Regular" icons have a somewhat fixed set of "properties" on their "property-sheet" and you really can't get any unusual actions added, unless some sneaky utility pokes its nose into just about anything and everything [like Norton AntiVirus for example]. But these "special" icons are another universe, and each is a special variant of a special case. doodr describes how to make an alternate "special" icon that is close, and in fact has a mixed bag of too many options [some of which are useful, just not authentic!] more like the desktop icon, but yet not exactly that either, and still not all of what the original wants. [And Windows allows both on the desktop, one showing as a shortcut and the other an icon. Customize Desktop is the source of the normal one, the other is the dragged one. Curiously, Windows has no way to redrag it back to the start menu...] In any case, it doesn't get you back to the three options that are essentially identical to the OE start menu icon. Ultimately, had it been necessary, the only "brute-force" way to do this would be some form of registry .reg patch if it could be isolated to a before/after kind of thing. I have used the package 98lite on Win9X. A peculiarity it causes is that you lose the entire desktop icon for IE somewhat analogous to this small problem. TweakUI helps you get an icon at all back, but it doesn't fully work. Most importantly, the OPEN option is missing! [And not particularly a 98lite problem, it is possible through some sort of IE upgrade process, dunno exactly when to install what, etc., but you can get an extraneous CUT option on the right-click menu that has no possible pairing with a PASTE that never happens!] I fixed it by creating a .reg patch that put back the property-sheet "handlers" in the registry that are normally there by doing a normal versus damaged entire registry dump/compare and removing the overhead of stuff that just changes because you booted up [which is amazingly large!]. Thanks for helping me avoid having to do something like that all over again! cjl

Hope this is not an old hat issue: Using the default Luna interface, the special Icon for IE [with the Internet Properties for example, this is NOT merely a shortcut icon!] "remove from this list" was invoked, so now it's gone. Is there any way to get it back? Please don't mention making new shortcuts [regular ones] or "reinstalling" IE from the CD, or customizing the DESKTOP icons, since that's not the problem. When the Luna interface is turned off, and/or you use desktop icon for IE, that icon is a special one and can do the Internet options stuff on its property-sheet, but how to move that one or equivalent into the main start menu of the Luna interface [meaning NOT on the "All Programs" portion]? Thanks for any pointers on this, cjl