billtodd

Your English is fine (and better than any second language that I speak, though that might have been less true several decades ago). I'm not sure if this would help, but http://www.terabyteunlimited.com/downloads-free-software.htm has 'drop to dos' which allows you to right-click on a folder in Explorer and get a command window into it. - bill

I'm generating a new system for my wife, who has some software that runs only on Win9x. Since it will multi-boot with Win7, I'm using an nForce3 board (the most recent hardware we have that still runs Win98 well). In the past I had a GeForce MX 4000 AGP card on this board and had a minor issue when running Win98SE with the CRT refusing to power down when the power management time-out told it to: it would display the message "Frequency out of range 00.0 Khz / 186.8 KHz" (the second number may vary a bit) after trying to power down, cycle through this a few times at a few seconds each, then return to normal awake status. This problem did not occur when running Win2K on the same hardware, and I eventually made it go away on Win98SE by changing the card's refresh rate from 'optimal' to any specific value supported by the monitor ('Adapter default' may have worked as well). nVidia doesn't list any Win7 drivers for the MX 4000 (though any Win7 nVidia driver might work) and in any event that's a fairly old card to be running Win7 on, so I tried a (marginally newer) FX 5200 we had lying around (for which nVidia does list a Win7 driver). Unfortunately, not only does it have the same problem running Win98SE but I haven't been able to find any combination of refresh rate, screen resolution, and color depth that will make the problem disappear (Google provided some hits that suggested this screen message could be caused by over-taxing the card's bandwidth capability, but the situations being discussed involved active use of the monitor rather than going to sleep - when I wouldn't expect bandwidth to be an issue - and the Google hits also did not refer to 00.0 KHz as the first number). I'm using the unofficial 82.69 nVidia driver since my wife's monitor is wide-screen (I think I was using an earlier driver version with the MX 4000): I'm just getting the system up and running on the CRT that's having the problem, but it would be nice to resolve it anyway (even if it doesn't occur on the LCD display, which I haven't tried it with yet). There's 1 GB of RAM in the box and the AGP aperture is set to 128 MB, but I do have MaxFileCache limited to 393216 so would not have thought this could be caused by a lack of available system memory. Incidentally, before installing any nVidia driver, when the default Windows driver was handling the card, this strange behavior did not occur. Anyone familiar with this issue, or have any ideas what might be causing it? Thanks, - bill

Well, 'tain't HFSLIP's fault that 969878 and 975025 wouldn't install. After taking MPSetup.exe out of the slipstream and still having the problem, I went back to my SP1 disk and reinstalled everything by hand - and those two patches still wouldn't install (Google couldn't find any information about this, but both have only been out for less than a week and not that many people are still using Win2K - assuming it's peculiar to Win2K). I even tried installing the 891122 DRM patch just to see if that would make them work - but no... If HFSLIP can save me 70-odd manual installs I won't complain about having to install a dozen or so WMP patches by hand (plus one DX9 patch). Slipstreaming the DX9c installation also eliminates 4 event log Windows File Protection failures (involving ks*.ax) that have always bothered me even though they never seemed to cause any problems. - bill

Ah - yet more fun and games. I just finished installing the slipstreamed system withholding all the WMP-related updates (except WMP9's MPSetup.exe itself). When installing the WMP-related updates individually afterward, 969878 failed saying it required that WMP9 be installed and 975025 failed saying it required that WMP (no specific version) be installed. The other 10 or so WMP-related patches installed fine (including the original codecs that I downloaded from Microsoft rather than use the DRM-'enhanced' version in 891122). Perhaps I shouldn't have included MPSetup.exe in the slipstream after all. I remember a claim that if you wanted the WMP9 encoder to work well you should first install the WMP7.1 encoder before upgrading to WMP9, so deferring the upgrade might have that advantage as well. Just to see what would happen I executed MPSetup.exe manually (the result seemed to retain all the setting changes that I had made earlier) and then attempted to re-apply the two failed updates, but the result was the same: whatever was lacking didn't get cleared up by the reinstall. Unfortunately, there's no obvious way to uninstall the codec package to see whether that may have affected anything (**** - I *know* I should have taken an early image of the system just in case). WMP certainly is a marvel... - bill (Oh, my - about the most innocuous '4-letter word' in my vocabulary seems to have been censored. I wouldn't want anyone to think it was something worse.)

Our Win2K systems date back to 2001, when SP1 was what the distribution disks came with. A quick check with WinMerge suggests that what's happening to the \SOURCE directory is that SP4 is being slipstreamed into it, before all the other updates get slipstreamed into \SOURCESS. As long as that won't confuse HFSLIP when it gets run again with W2KSP4_EN.EXE still in \HF even though \SOURCE already has the SP4 updates it's understandable why \SOURCE doesn't have to be refreshed each time - one less step in the process (two less if HFSLIP also cleans out \SOURCESS before reusing it). Whatever errors may or may not be occurring don't seem to have compromised the result, which installs and runs just fine. Thanks again for helping me understand things a bit better. - bill

svcpack.log is generated by HFSLIP in its main directory (\HFSLIP in my case) when HFSLIP is run. Its first line is Service Pack started with following command line: -u -n -o -q -s:"E:\OSKITWin2KReinstallKit\HFSLIP\SOURCE\" In this case the E: drive is the one containing the HFSLIP directory structure set up by hfslip-1.7.8.cmd which it then uses to generate a slipstreamed installation. Beats me: it's HFSLIP that's apparently looking for it during its processing. Didn't find the string '\mp\dosnet' with a quick search of the .cmd file, but the apparent error notation in svcpack.log seems to suggest that it wanted this and didn't find it. All I have in \HFTOOLS are the three files that I placed there (bbie.exe, cygwin1.dll, and mkisofs.exe) plus the BOOT.BIN file that the installation places there - which I think is everything that the instructions at http://www.hfslip.org/ told me to place there. Your instructions at http://www.hfslip.org/ under the 'Extras' heading say that all those are the default values (in which case I shouldn't need to have that answer file to cause them to be used, should I?). Incidentally (there always seems to be one more question to ask) I just noticed that generating the installation seems to have added three .cabs to \HFCABS (_IE6_HFSLIP.CAB, _IE6b_HFSLIP.CAB, and _OE6_HFSLIP.CAB) - but not updated them (at least according to their modification dates) since the first slipstreamed installation that I generated. I understood that the \SOURCE directory had to be cleared and repopulated for each run - is this also true of \HFCABS (and any others)? - bill

Just a couple more oddities observed while running the current release (1.7.8): The second entry in svcpack.log is x86GetSourceArchitecture: Invalid handle for file: E:\OSKITWin2KReinstallKit\HFSLIP\SP\i386\mp\dosnet.inf Does that sound OK? At one point during the procedure (I didn't find this in either log file) a message to the effect that a valid iso9660 .iso image could not be produced apparently because some support file controlling use of Joliet (I think) extensions was not found appears on the screen. The .iso can still produce a bootable and usable installation disk (WinMerge validates that its data content matches the SOURCESS source) but ISOburner produced a disk on which ISObuster couldn't checksum a couple of the last sectors (could just have been a defective disk) and while InfraRecorder produced a disk that ISObuster could checksum the checksum didn't match that of the input .iso file, which leaves me wondering whether some additional .iso-creation file is missing (beyond bbie.exe, cygwin1.dll, and mkisofs.exe, which are there). FWIW, - bill

Well, 'removing' WMP6 in Add/Remove Programs after a non-WMP9 installation doesn't do squat in terms of removing anything: it just hides it - and not all that well, since Windows Update still lists its related patches as missing (thanks for introducing me to InstallRite, by the way). And after installing WMP9 and all its relevant updates those WMP6-related updates are still listed as missing, so there's apparently nothing to be gained by not installing WMP9 with HFSLIP. Whether all the related updates - including those for WMP6 - should also be included in the slipstream is more debatable: Windows Update doesn't recognize that they've been installed and if you want to keep WU quiet they must be installed later manually, but since doing this doesn't generate compressed uninstall folders in \WINNT there's a bit less cleanup afterward. I'm leaning toward doing everything but the actual WMP9 installation afterward, if for no other reason than that it's about as easy and doesn't leave any disturbing questions about what is actually happening. Incidentally, 891122 doesn't show up as a missing update (critical or otherwise) when WM9Codecs9x.exe and the other WMP-related updates are installed. And removing HFSLIP from Add/Remove Programs after the installation didn't cause any obvious problems. - bill

Are you by any chance confusing 891122 with 926122 (which you indeed did mention a few posts up)? As for the details of what's happening with WMP hotfixes, I had no idea that incorporating them involved so much manual detective work (let alone whatever it may take to transform the results of that detective work into a working HFSLIP install). Given how easy it is just to install them after the HFSLIP installation is complete, and the likelihood that every new WMP hotfix will create a new puzzle to solve, and the fact that most new WMP hotfixes simply replace previous ones (hence would not add to the post-install update effort), just leaving them out of the HFSLIP list strikes me as by far the most reasonable approach. In that regard I hope that it's now clear (if it wasn't before) that I haven't been trying to rush you to incorporate any such changes (nor the DX9 change if that's similar in nature): I've only been trying to give as much information about what happened as I could glean to give anyone who might be affected a heads-up and help if/when you decide whether to tackle this issue (plus asked a few random questions that you might know the answer to off the top of your head - again, I wasn't requesting that they be researched). - bill

I suspect that if you consult a grammarian you will find that my sentences, while perhaps too long for some tastes, do not qualify as run-on. I don't use WMP but my wife and daughter do, so I keep it up to date for them. It might be best just to leave its updates completely out of the list (save possibly for MPSetup.exe) rather than just let the chips fall where they may: while I won't presume to speak for anyone else as I said that works fine for me (I'll let you know how removing the old WMP before installing WMP9 works out). Windows2000-DirectX9-KB971633-x86-ENU.exe was indeed what I had in \HF. You may have missed my last edit (P.P.S.) above regarding 891122 and applicable codecs. I've tried removing HFSLIP with Add/Remove Programs and will see how that goes. - bill

Yup - I'm slipstreaming WMP9 (MPSetup.exe is included in \HF for the run). In addition to the 4 WMP-related updates that I had slipstreamed but which WU thought were missing (954155, 968816, 973540, and 952069) and the WMP 6.4-related updates that I had not included at all, 3 other WMP-related updates that I did include seem to have been recognized by WU as being there (975025, 969878, and 911564 - plus of course MPSetup.exe itself) - perhaps the result of the inconsistent naming practices that you mentioned. WU also thought that the DX9 update (971633) which I had included in \HF along with directx_9c_redist.exe was missing. The root certificates update as well, but another post here seems to suggest that a new version of that may have appeared since I captured the one from the September list (since I already had it in \HF this possibility didn't cross my mind when I was updating the \HF contents for October or even when I re-applied the same update manually after WU listed it as missing - duh). As I mentioned those 4 slipstreamed but unrecognized WMP updates plus the one for DX9 did not generate compressed uninstall folders in \WINNT when I applied them individually after WU thought they were missing - just in case that helps diagnose what's happening. As for 926122, I'm pretty sure that WU has identified this (apparently server-only) update as missing on only the ThinkPad 570E plus one of the many desktop systems that I've installed Win2K on. Wonder what triggers that. Just out of curiosity, if I remove *all* WMP9-related material (including MPSetup.exe) and all the WMP 6.4 updates from \HF, then after having installed the slipstreamed system use Add/Remove Windows Components to remove WMP (if indeed that option is available with WMP 6.4/WMP 7.1), then install MPSetup.exe and all the WMP9-related updates, should that exorcise all traces of WMP 6.4/WMP 7.1 from my system? (The list preamble states that "Windows 2000 comes with WMP 7", so it's not clear why 6.4 is there at all.) I'm not sufficiently into paring fat from the system to explore the nLite possibilities, but for some reason find this particular redundancy vaguely annoying. From my point of view given that there are so few WMP updates that need to be applied just leaving them out of the list and letting us apply them after installation (as is required with other products such as .NET) would be reasonable if figuring out what to do with each one individually is a recurring problem. In any event, thanks for your continuing efforts. - bill P.S. Yet another random question: After installing the system there's an HFSLIP entry in Add/Remove Programs. Is this just an artifact of the installation which can be removed? P.P.S. 891122 appears to be a DRM 'enhancement' that some might consider to be junk (I didn't include it in \HF), even if it happens to contain useful codecs as well. Microsoft's WMP codec installation packages can be downloaded from http://www.microsoft.com/windows/windowsme...ecdownload.aspx

Interestingly, when I manually applied the updates that I thought might be significant only the WMP 6.4 updates created compressed uninstall folders in \WINNT, which might suggest that the WMP 9 and DX9 updates actually were correctly applied by HFSLIP but simply not recognized by Windows Update as having been applied until I reapplied them individually. But the root certificates update failed to be recognized by WU even after I had applied it manually (behavior which I've encountered before): only asking WU to apply it made it recognizable the next time WU ran, though I suppose it's possible that the version which I downloaded using the link in the September list on 10/7 might have been superseded in the interim. For what it may be worth. Thanks again: this sure beats applying the whole post-Update-Rollup-1 (or even just the post-usp5.1) bunch manually to multiple systems, especially given that I like to know exactly what's on them rather than just give WU its head and let it apply everything. - bill

Thanks - I feel kind of silly for not having noticed this after noticing the WMP 6.4 pattern. But there's still the DX9 update that also didn't get found (and doesn't seem to contain multiple files), and that dates back to August. In any event, it's not hard to install the few offending updates manually now that I know which ones they are (perhaps the HFSLIP instructions and contents could change to reflect this). Having been pestered by Windows Update about WMP 6.4 updates in the past I do understand that installing WMP 9 does not normally remove WMP 6.4, but since HFSLIP in fact does replace files in \i386 and the driver .cab file (and since the HFSLIP instructions emphasize that you should not include WMP 6.4 patches if you've slipstreamed WMP 9) I had tentatively assumed that HFSLIP removed WMP 6.4 when it installed WMP 9 (though in fact HFSLIP refers to WMP 7 rather than 6.4). Since the behavior of WMP in this area differs from that of replacement-style upgrades to IE, OE, and DX, perhaps the instructions could clarify that. - bill

Is it possible that some of the newest updates didn't include whatever it takes for Windows Update to recognize that they've been applied? 954155, 968816, 973540, 971633, and 952069 are listed as missing despite the fact that I included them in my \HF input to HFSLIP. The (optional) root certificates update (also included) came up missing as well. Is this expected behavior (I think I've seen that happen after I manually installed that update)? Several WMP 6.4 updates are listed as missing despite the fact that I slipstreamed in WMP9. I realize that I can probably just ignore them (unless somehow WMP 6.4 is still lurking in my system somewhere and creating a latent vulnerability if I leave it defenseless), but is this expected behavior from HFSLIP (I tried to search this topic for '6.4' but for some reason just kept getting sent to the main forum page)? I tend just to ignore updates to things like Remote Desktop Connection, Message Queue, and Active Directory that I never plan to use (or even install), which sometimes leads to strangeness (e.g., 937894 listed as missing but not the more recent 951071 which replaced it or the even more recent 971032 which replaced that). Should this be any cause for concern? Pure curiosity question: 926122 is listed as missing - a server update which I really wouldn't expect my ancient ThinkPad 570E would require. I remember seeing that pop up missing on one other desktop system once, and never on any others: anyone have any idea why? Thanks for any insights, - bill

Thanks for such a prompt monthly update - now that everything is officially blessed I'll give it another shot to see if WU agrees that it's all there. (KB973346 appears in the deleted-files section but doesn't seem to have been removed from the main list.) - bill

One more note that may just reflect some misunderstanding on my part: I can't find LegitCheckControl.* anywhere on my Win2K system and it runs Windows Update just fine, so that may not be required (nor is the Malicious Software Removal Tool; the Agent and - I think - the BITS updates are required, though). I'd also feel more comfortable knowing why patches to Remote Desktop Connection like KB958470 don't appear in the list (is it just because no one in their right mind would enable it?). Thanks (again), - bill

While doing a cursory (and not yet complete) cross-check against the Win2K update list that I've built up over the years I noticed that the MS09-037 ATL update in August seemed to affect 4 different components (OE, MP, ATL, and DHTML), only one patch for which (the OE one - KB973354) seems to be included in the Win2K hotfix list (i.e., KBs 973869, 973507, and 973540 don't appear in the list). Since this is my first encounter with HFSLIP and since the patches are so recent and so easy to apply manually I don't plan to include those missing three (just in case one or more should go somewhere other than in \HF), but thought I should mention it just in case the omission was inadvertent (rather than due to my misunderstanding what should have been included). It also seems to me that KB969805 may only apply to server editions of Win2K, but I could just be confused there as well. This isn't meant to be critical: I really appreciate this tool and wish I had taken the plunge years ago. - bill

Forgive me if I missed these in earlier posts, but since I'm still running Win2K (occasionally XP) even though we've got Win7 on order finding good security products is becoming harder: Last Win2K versions: Online Armor Free 3.1.0.26, which is somewhat more current than Comodo Firewall Pro 2.4.18.184 (though both are still quite respectable) However, Avira's AntiVir still supports Win2K, as do a large number of other useful applications. For that matter, if you sit behind a hardware router/firewall and are careful where you surf even Win98 is still surprisingly usable (last I knew Avast's anti-virus still supported it). - bill

My impression is that Microsoft's command language doesn't offer the level of wild-carding rename facilities that would be required. See http://rename.lupasfreeware.org/lupasrename.php for some freeware that should do the job easily. - bill

Last week I asked for help in changing the username reflected by the screen-saver return screen in XP Home (the login and return-from-standby screens do reflect changes made with XP Home's User Accounts manager in Control Panel but for some reason that change does not propagate to the screen-saver return screen, which appears to use a more fundamental account name). While several people came up with potential ways to do this, they all had drawbacks involving risk and/or complexity. The one straight-forward suggestion involved use of the Local Users and Groups Management Console snap-in, which is not available on XP Home (and Microsoft goes to some lengths to ensure that it won't be - e.g., even trying to run lusrmgr.msc from my Win2K SP1 installation disk returned the error that it cannot be run on XP Home - perhaps if I'd had a Win2K installation disk with no service pack that would have preceded Microsoft's policy decision in this area). I was not able to find any other information here about how to run lusrmgr.msc on XP Home, but finally did find it elsewhere and it appears to work just fine - so since the question has been asked here multiple times in the past with no real response that I could find I thought I'd pass it on (quoted from http://www.techbytes.ca/techbyte106.html ): How to access Local Users and Groups in XP Home In Windows XP Professional the Local Users and Groups can be displayed and edited through the Computer Management (compmgmt.msc) console. This feature has been removed from Windows XP Home, however there is a workaround. Note: This article is intended for experienced system administrators. If you are not familiar with using Local Users and Groups, we highly recommend that you use the built-in Windows XP Home user management tools. To create your own Local Users and Groups utility in XP Home, perform the following steps: 1. Click Start -> Run.... Type mmc.exe and press Enter. 2. Click File -> Add/Remove Snap-in... and click the Add button. 3. Scroll down until you find Local Users and Groups and click the Add button. 4. In the dialog box that opens, choose Another computer and enter 127.0.0.1 (the local loopback address) and click Finish. Note: Even though there is an option on this screen for Local computer, if you choose this you will be presented with the following message: "This computer is running Windows XP Home Edition. This snapin may not be used with that version of Windows. To manage user accounts for this computer, use the User Accounts tool in the Control Panel." By selecting Another Computer you can work around this warning. 5. Click the Close button then OK button to return to the newly created MMC console. 6. Click File -> Save to save the new console. By default it will be saved to the Administrative Tools folder. 7. Close the MMC window. Edit: Found another obscure (but apparently supported) way that might have addressed my specific goal (quoted from http://www.howtofixcomputers.com/forums/xp...oups-84888.html ): QUESTION: ========== Is it possible to create a new group in Windows XP Home Edition. I do not see an option from Computer Management view RESOLUTION: ============= 1. Restart your computer. Then boot into safe mode by pressing F8 2. Log in as the Administrator 3. Click Start -> Run 4. Type "control userpasswords2" (without quotes) 5. Click Advanced tab 6. Click Advanced button under Advanced User management 7. Click Groups folder. Then Right-click Groups folder and select "New Group..." The above facility does not appear to be completely comfortable in XP Home, since the way it tells you to change the Administrator password (CNTL/ALT/DEL) does not work (I was somewhat surprised to find that this safe-mode Administrator account had no password, and think I'll continue to try to find out how to give it one), but it seems to offer the ability to change the account name as well as the 'full name'. A third option was suggested in http://answers.yahoo.com/question/index?qi...22224529AA7F7FB (haven't tried that either, but the download still exists). And there are shareware apps that may address such issues as well. - bill

malmal - Yes, I'd already changed the RegisteredOwner value. James - It was indeed imprudent for me to have thought of trying to get away with changing profileimagepath as the last act of the user using it before logging off. However, it might be safe to switch back to the old account and change the new account's profileimagepath from there, then perform the directory renames from the Win2K installation which shares the system, log into the new account, and change the old account's profileimagepath to the renamed old directory before deleting the old account just in case that deletion might affect the target profileimagepath directory (which would otherwise now be the new account's directory). Ponch - There's no separate 'Administrator' Documents and Settings profile directory (nor for that matter any separate Administrator profile listed under the My Computer properties sub-menu), so I suspect that account uses the Marvin directory. Whether this would create problems making the change in Safe Mode as you suggested I don't know. Again, thanks to all who responded. At this point the better part of valor may be to leave well enough alone unless I can find a security plugin to use in the more-or-less supported manner to change (the rest of) the existing account name - since I'd like to limit the amount of required rigmarole should I ever have to rebuild the system from the original image. - bill

Alas, this is not XP Pro but XP Home, where Microsoft in its infinite wisdom has decided that users should not have access to security information or even to user/group management - so there is no Local Users and Groups section in the Management Console. Control Panel has a User Accounts section which allows one to rename an account, which is what I used. I agree that switching to a new user (even with the same profile contents) does not seem to be the way to accomplish what I'd like to, which is my main reservation about trying iamtheky's otherwise interesting approach - since that presumably would leave the old SID as the owner of all the existing contents of the profile (not necessarily much of a problem as long as those contents allow full access by any administrator, but still a bit awkward given the lack of readily-available security functions in XP Home that could change the ownership if necessary). I suppose I could create the new account, use it to copy the contents of the old profile directory (presumably leaving the new SID as the owner of the new copy's contents), modify the profileimagepath entry in the new SID's entry in the profile list as described, then delete (or just in case perhaps merely rename) the old profile directory and rename the new copy to Marvin (this last perhaps from the safety of a co-resident Win2K installation) - but while this might be an interesting experiment I'm not sure it's worth the risk (though taking a backup image beforehand could eliminate that) just to change the name used by the screen saver. At this point the annoyance of not being able to fix this problem without potentially risky Registry manipulation is starting to exceed my annoyance with being called Marvin once in a while. I seem to remember seeing some reference recently to being able to add the XP Pro security plugin to the XP Home Management Console, which your post suggests might do the job: does anyone happen to know where I might be able to pick that plugin up to try it (as I said, I don't have an XP installation disk of any kind, but do have my Win2K disk if the one there would work)? Thanks once again, - bill

Thanks. From Microsoft's descriptions it's not clear that the Files and Settings Transfer Wizard would work in this case, and the manual method that's described in KB811151 certainly wouldn't since it doesn't handle any of the hard-wired third-party references to the old Marvin directory (nor, for that matter, necessarily any of the applications that make them). The 'fiddling' that I already did may not be a problem (and indeed hasn't affected any subsequent use of the system), since I only changed 'User Name' kinds of entries rather than anything likely to affect linkages rather than display properties. I had hoped that someone here might happen to know where the screen saver code gets its user name, or perhaps more generally how to change the profile name (which might be where it's coming from) without affecting any of the profile's linkages (e.g., to the existing Marvin directory). But it's really not that big a deal just to tolerate the current situation if no one knows how to fix it. - bill

Thanks, but it's a bit more specific than the login (perhaps the length of the post made that easy to miss). The name reflected in the login screen is the new account name, as is the name reflected in the screen presented on return from standby: *only* the screen presented on return from the screen saver uses the old name, so it's getting its information from somewhere different (which seems a bit odd to me). Is my (decidedly superficial) understanding incorrect that creating a new profile would create problems with all the existing hard-wired third-party Registry references to the old 'Marvin' Documents and Settings directory? - bill

While generally content with trailing-edge technology (I migrated to Win2K from Win98SE a couple of years ago but have yet to convince my wife to do so), we recently inherited an XP Home system from her parents and I figured I might as well try to resurrect it (its disk was dying and its other hardware was antiquated) to handle the occasional instance where some stubborn software demands XP or Vista rather than Win2K and can't easily be fooled about that. To my surprise, after using xxcopy to migrate what was still readable on the disk and preserve 8.3 names the transplanted system seemed to run OK (after a bunch of missing driver files were reextracted from the driver cabinet; I'm still missing sysdm.hlp, since no installation disk came with the inheritance) and Microsoft didn't complain about activating XP on the new hardware (WGA even accepted it without demur). SP3 and drivers for the new hardware installed without a hitch, and here I am. I'm fond of my father-in-law but didn't particularly want to have the machine address me as 'Marvin' for the rest of our lives with it, so I renamed his user account to something I'm more used to. I'm not offended at all to have his name still appearing in the Documents and Settings profile directory, though - which is just as well, since a bunch of third-party program Registry entries are hard-wired to that directory. But there's one remaining problem: while the machine addresses me by the new name during logon and after returning from standby, when reawakening from screen-saver mode it still calls me 'Marvin'. I've gone through the entire Registry changing every system-related user-name instance of Marvin to the new name, and even looked through the 'Marvin' Documents and Settings directory to see whether there might be something squirreled away there that's getting used, but to no avail (and some of those Registry changes seem to get changed back after every reboot). The user profile entry (reached through My Computer properties) is named Marvin, and there's no option to change that which I've been able to find. I understand why just changing the Documents and Settings directory name would not be a good idea, but as I said above that's not what bothers me: I mostly just want the screen-saver exit screen to stop calling me 'Marvin', and that really shouldn't be tied to the directory name (nor should the profile name - in fact, while trying to research this problem I think I encountered information that suggested that the directory name could be anything one wanted it to be if one had the foresight to change it during installation). As I said in the title, this is a silly issue - but if anyone happens to know how to resolve it without creating a new profile, migrating the old one to it, and in the process breaking all those third-party Registry links I'd be grateful for the information. Thanks, - bill