billtodd

Thanks for the thought, but I've tried several over the years and found that not being able to use Explorer itself was a minor annoyance (aside from a few quirks exhibited by the potential replacements). This seems like such a basic flaw that there MUST be a simple work-around which I just haven't yet found - at worst, some Registry modification that would prevent it from doing what it so clearly doesn't need to. I don't remember checking to see whether XP exhibited the same flaw; if not, that would be an option, though if I'm going to leave Win2K - in whole or at least in part - it might make more sense to make a bigger jump to something with longer-term support. But if no one here knows of a solution there may well not be one (haven't tried the Russinovich blog yet, if it still exists, but his interest in answering Win2K questions may be limited by now).

As a stubborn decade-plus Win2K user I'm starting to consider upgrading to Win 8 (or possibly Win 7: I'm not a fan of the 'improved' UI in Win 8) in order better to future-proof my Windows activities for the NEXT decade or so. One of the long-standing annoyances I have with Win2K is contributing to this decision, in part because it's also annoying that I've never been able to fix it. When expanding a directory in the left-hand Explorer pane in Win2K it processes subdirectories at the rate of around 20 per second, which means that it can take well over a minute just to expand the left-hand pane one level below a target directory when the number of next-level subdirectories reaches, say, 1,500. I'm guessing that Explorer is VISITING each subdirectory in the process (one MFT access plus one access to the actual data stream of the subdirectory) and possibly doing even more processing, even though none of this is necessary simply to expand the list in the left-hand Explorer pane (and indeed if rather than expanding the tree in the left-hand pane I simply list the content of the parent directory in the right-hand pane it pops up very quickly).. A quick check with Win 7 using the same hardware and directory structure demonstrates that it does not share this behavior (the list in the left-hand pane expands in under a second), so either Microsoft made some significant changes in the Explorer code or there's some simple option (which I've never discovered, though I've tried) that can be changed to eliminate Win2K's Explorer lethargy in this regard. Apologies if this has been covered here already (as I would expect it to have been): I did perform a forum search with variations on 'expand directory' without success but obviously could have still missed it. I also struck out with more general Googling (most of the hits involved slowness in creating lists in the right-hand pane). If anyone knows the answer to this, I'd appreciate it.

Sorry I didn't notice this earlier. I'm still running Avira AntiVir (free version) and getting updates for Win2K (can't say how long that will last, but my impression is that they're not going to stop until they need to for some reason). Version 10.0.0.648 was I think the last one I installed but after subsequent update activity it now says it's 10.2.0.704 (despite the fact that it was shortly after 648, in July of last year, that Avira warned that it could no longer be installed on Win2K - so you could try installing SLIGHTLY later versions if you'd like to try AntiVir but can't find 648). In its Help 'about' screen most program files are dated 11/July/2011 but both the virus signatures and search engine are dated this month and the product date is 28/Sep/2011, well after support for Win2K nominally ceased; in its Program Files folder quite a few .dlls have dates within the past few months. It will occasionally ask to install an 83 MB product update and actually download it but then the install itself does nothing (presumably because the update itself does not support Win2K); still, clearly SOME updating beyond just signatures is still occurring (thank you, Avira). As long as the virus signatures are still being updated I feel pretty safe, though might feel less so if I weren't behind a hardware firewall. Some people report problems installing Avast 7 on Win2K, but others say that you just need to reboot an extra time to get it running. I may try it, but I think pretty highly of AntiVir so would like to stay on it as long as is reasonably possible.

Please don't apologize: I'm grateful for any insights I can get. That would have been good to know back when I arranged for my daughter's laptop to multi-boot with Win2K 3 years ago. Unfortunately, that laptop recently died so I can't try it out on that hardware. But the motherboard that's frustrating me now has an AMD 770 / SB710 chipset, not an nVidia one, so I thought that the only nVidia support I needed was the graphics drivers - though am certainly willing to try out the above nVidia chipset drivers if you think they might help in some way. The latest nVidia graphics driver I know of that works with Win2K is 197.45 (April, 2010 - see http://www.nvidia.com/object/winxp_197.45_whql.html). Its README file (unlike the documentation for 18.11 above save for its display driver, which is why I would have liked to be able to try it out - I have some older nVidia nForce 430 motherboards I could try it on, but it wouldn't exercise the later hardware support) indicates that it supports Win2K, and when I installed it on another Win2K machine it installed without complaint and appeared to support my GeForce 210 card (though I didn't test its functions at all exhaustively). I tried to download it just in case the 18.11 driver supports only the 730a chipset (I tend to be paranoid that if I need something like this I'll find that it is no longer accessible on the Web). But after accepting the nVidia license the download just bumped me back to the nVidia home page (tried multiple times - apparently that link just isn't working, since I can download later drivers using the same menus). I eventually found another site (http://www.driverslib.com/BIOS/Nvidia/nForce-630a/6106.html) that doesn't require use of some proprietary download manager as sites like CNet and Brothersoft do (I find them annoying): unlike 18.11 above its README file DOES say it supports Win2K, but, again, I don't know that it would help with my current AMD chipset problem. VERY good to know - thanks! Yes, I've had pretty good luck getting nVidia chipsets to work with Win2K on several boards, and even some getting them work work with Win98SE (though that's been getting harder the last few years). From earlier comments here I had hoped to have similar experiences with the AMD chipsets, but this particular one seems strangely uncooperative.

My board (770 + SB710) has no integrated video, so no integrated video support on its install DVD. Also, the cards I'm using are nVidia (just in case yours were ATI). Just looking for possible differences as possible clues (or grasping at straws). Tried it. No difference. Tried running AMD's driver detector/downloader, but (naturally) it doesn't want to run on Win2K. Haven't been able to find any AMD drivers for this chipset that claim to run on Win2K (which seems odd given that Win2K was supported for about 3 years after this chipset came out - and for that matter while the board's install DVD top-level autorun.exe won't run on Win2K the setup.exe in the chipset directory seems to install just fine and its internal docs say it should, so perhaps AMD deleted all its support for Win2K when it reached nominal EOL even though Microsoft only stopped issuing updates and kept the existing support available). Blargh.

No, and it was certainly a reasonable idea - but it turns out that nothing useful appears when you show hidden devices either (nor does it on XP before the driver has been installed and magically caused the Display Adapter to appear in DM). So for this particular board XP and Win2K act the same (not seeing any Display Adapter) UNTIL you try to install the appropriate driver, at which point XP installs the driver (whether it be for the GeForce 210 or the 6200LE) and all becomes well while on Win2K the driver either refuses to install (for the 210, saying that no suitable device is present) or installs but doesn't change the situation (for the 6200LE, perhaps because only newer nVidia drivers refuse to install if they don't see hardware that they recognize). Whereas Win7 sees the Display Adapter immediately (perhaps because Win7 already includes the appropriate driver for it and installs it as part of the Win7 installation). If no one else here has used Win2K on an AMD 770/SB710 chipset perhaps it's just some peculiarity of that hardware. Or if everyone who has is also using an unofficially-enhanced Win2K installation perhaps that cures the problem in some unexpected manner (as I noted, I'm just running the HFSLIP 1.7.9 slipstream with no unofficial changes save for time zones since I haven't had time to become familiar with post-EOL unofficial updates that may be significant for me). I don't really NEED to run Win2K on this machine and if I did I could either run it at 800x600 resolution under Vgasave or run it in an emulator: it's just annoying not to understand why I can't get it working right when it seems I should be able to.

Thanks for the additional ideas. Speccy (1.06, apparently the last version to support Win2K) can't see the 6200LE at all (nor the on-board audio hardware, for which I didn't bother installing the driver this time around). Perhaps it can only see devices that have a driver installed - its only entry under 'graphics' is the generic Vgasave support. UnknownDeviceIdentifier found both the 6200LE and the on-board audio hardware, with a red background for both (perhaps its way of saying that no driver is present, but at least it can see the card - only the fact that Win7 could also see it during its installation kept me from worrying that the PCI-e slot was somehow defective). Device Manager still doesn't list any Display Adapter (thought I'd better check to make sure nothing had changed there, especially after UDI found the card). BlackWingCat's version of nVidia's 197.45 driver (with the 6200LE installed) issued the same message that nVidia's did with the GeForce 210 installed: no hardware found that matched the driver, so it just refused to install the driver. I'm curious in what way BWC's driver differs from nVidia's, given that the latter does say it supports Win2K and certainly appeared to when I installed it in another Win2K system. Tried what was apparently BWC's version of 266.58. It installed suspiciously quickly and was identified in Add/Remove Programs as NVIDIA PhysX, but made no other difference (no appearance of any Display Adapter in Device Manager nor of any video facilities beyond the 800x600 provided by Vgasave). A much smaller BWC file has the file name nvw2k26658d.zip but identifies itself internally as 256.00. I couldn't try that as specified because it requires installation via the Device Manager update driver mechanism (which, of course, only exists for a device present in Device Manager), but I did right-click to let me try the 'install' option for its .inf file - to no avail. I've been fumbling around (so far without success) attempting to modify the board's install DVD's content sufficiently to get the top-level autorun.exe to run on Win2K as it did on XP, but keep thinking that I must be missing something which either is obvious or at least is well-known to people who have been using these AMD chipsets with Win2K for the past few years. There are a few suspicious directories outside the main chipset install directory that contain 'vga' subdirectories, but so far they seem related to ATI-specific video support (i.e., to other boards that have it or are using ATI cards) and while I've tried running all their setup.exe files (and installing the occasional .inf) wherever they remotely seemed possibly relevant that hasn't helped. If I didn't have the strong suspicion that Win2K WILL run on this board and use the PCI-e graphics cards as it should (since XP does even though it initially exhibits the same blindness to the video cards that Win2K does) I'd be far more willing just to give up the idea. Grrr.

Thanks for the speedy response - but I'm not sure which BlackWingCat drivers you're referring to. As I noted, the chipset drivers on the board's installation CD appeared to install just fine on Win2K (including a top-of-the-screen title indicating that they were installing for Win2K, not something later), and the driver file dates are 2007, which is I think later than anything that the Win2K installation (basic HFSLIP 1.7.9) would have provided during the Win2K install. Unless the board's installation CD's top-level autorun.exe facility (which does run on XP but not on Win2K) installs something extra that it doesn't mention in its menu (which includes only entries for chipset, LAN, and sound) it certainly looks as if chipset support for Win2K is successfully installed. The GeForce 210 197.45 nVidia driver installed successfully on another board running Win2K (and I'm not sure how much farther back I could go and still get support for that card), as did the GeForce 6200LE driver from that card's install CD (and it installed successfully from the same CD directory on the new board for XP, though I suppose the setup.exe activity may have used different material from that directory). Unlike the 197.45 driver, the 6200LE driver doesn't complain that no suitable card is present and appears to install successfully on Win2K, but (unlike on XP) does not then make the Display Adapter appear (with appropriate support) in Device Manager. There seems to be something different about this chipset (unless there's just something wrong with the board) that doesn't bother Win7 and that XP manages to work around (at least in the case of the 6200LE) better than Win2K does. The base installations of Win2K and XP (unlike Win7) don't even SEE the display adapter (instead using Vgasave to provide basic display functions). After the base installation Device Manager doesn't see any Display Adapter either (so I couldn't follow your suggestion to install in that manner on Win2K). Later requests to detect new hardware don't find it either. I'm game to install any BlackWingCat drivers that you think might help. I didn't bother with the AHCI driver because a) it didn't seem applicable to this problem and B) the board's chipset drivers seemed to install OK. I'm not sufficiently familiar with BWC's extensive work to know what other drivers might be worth a shot, so would appreciate any pointers you can provide. Again, thanks.

Me again, with another question regarding the above. I just purchased a very inexpensive Socket AM3 board (mostly to have a spare) - the first MB I've bought in a long time that wasn't nVidia-based but rather on AMD 770 / AMD SB710 - an ECS IC780M-A2 (V1.0A). The Win2K installation seemed to go fine, but when I attempted to install the nVidia 197.45 graphics driver for the GIGABYTE GV-N210SL-1GI GeForce 210 it claimed that no suitable video card was present (I had just successfully installed this driver for that card on a Win2K installation on another MB, so this was unexpected). At that point I thought I'd better install the chipset drivers (which I'd casually tried to from the MB install CD, but which had failed). Turned out that while the overall CD installation failed each individual driver (chipset, LAN, and sound - apparently all that were present, given that on a subsequent XP installation it only listed those three options in the overall install menu) happily installed on Win2K and in fact seemed to indicate that they were intended to (so there seemed no need to explore, say, BlackWingCat's drivers). But still the 197.45 nVidia driver claimed that no suitable card was present. I then discovered that the adapter support (from Display properties) was Vgasave (which I'd never encountered before), with no option to update the driver to something else. In fact, Device Manager didn't list ANY display adapter as being present. Hmmmm. Just in case it was the video card itself (though it had just been working in the other machine) I swapped it out for an old GeForce6200LE and redid the Win2K installation from scratch. Same result, even though the 6200LE's support CD appeared to install successfully rather than complained that it couldn't see the card as the 197.45 driver had. I was beginning to think that the problem must be with the MB, but figured I should try an XP installation to check. While the basic install still left me with Vgasave in Display Properties and no adapter at all in Device Manager, when I installed the 6200LE's support CD, lo and behold, the Display Adapter appeared and all seemed well: apparently, despite the fact that the card's support CD claimed to support both Win2K and XP, something in the nature of the support (or possibly something which the MB's install CD quietly installed from the top-level installation, which wouldn't run on Win2K) was sufficiently different to resolve the problem on XP. Just to complete the process I installed Win7, and in that case the basic install recognized the 6200LE right off with no need to install a driver independently. I looked around here for discussions about installing Win2K on boards with AMD chipsets (e.g., ) but found nothing that seemed to shed any light on this (which seemed a bit strange, given the number of different MBs people here have tried Win2K on). Am I overlooking something obvious, or does this at least ring a faint bell with someone? Thanks for any insights you may have. Edit: One more thing I did try was choosing 'Enable VGA mode' in the F8 boot menu, a suggestion I found somewhere while trying to investigate this. Still no joy, though.

Since a quick search didn't reveal any answer to this, could you confirm that the statement above applies to the new (a-series FM1 and AM3+) motherboards as well as the earlier AMx ones? The Web sites for at least some FM1 boards don't seem to include drivers for anything prior to XP (nor does the AMD site), and for an integrated GPU one might expect drivers beyond what's available in the Win2K distribution to be required. Thanks.

Thanks for such a clear and complete explanation. The main reason I questioned whether 2286198 actually superseded 967715 was because the Microsoft 'replaces' information for the former did not appear to recognize that it superseded the latter (nor did the descriptions of the problems addressed appear similar). I would have taken a closer look at what was going on had I not assumed that the question could be answered off the top of someone's head, so apologies (and further appreciation) if you had to do more than that. It surprised me that 2286198 was itself superseded without any mention in its own slot - perhaps because it (and similarly 2296011 and two other unofficial updates that apparently didn't supersede earlier official updates) was superseded only by an IE-specific update rather than by a system update. Just tracking what replaces what must be non-trivial, and since it shouldn't do any harm to apply earlier updates unnecessarily I guess the only real reason to try to avoid that may be the size limitations of a CD (though perhaps not even that, given how the CD is likely created). Edit: I've wondered whether the HFSLIP command file keyed off alphabetical order to make sure that newer files in SOURCESS weren't overwritten by older ones, but I guess your new naming conventions make it clear that it doesn't.

I posed what may be a stupid question at WildBill's petool topic but on reflection wondered whether I should have posed it here. In bristols' Win2KSP4 update list 2286198 is said to supersede 967715, but a cursory examination suggests that the latter deals with autorun/autoplay functionality while the former does not seem to have anything to do with that - nor apparently claims to supersede any of the previous patches in that area. Could this be an error, or did WildBill simply include additional stuff that would make it correct, or am I missing something really obvious? Thanks, - bill Edit: Question was answered in WildBill's thread (Yes, the former does supersede the latter, even though Microsoft's descriptions don't appear to recognize this).

Thanks for the speedy response. I understand what 2286198 does, it's just not clear to me that this also addresses what 967715 fixes (i.e., that the assertion that the former supersedes the latter is correct: that assertion appears in bristols' Win2K SP4 update list, so - as I said - forgive me if this is not the right place to ask about it). - bill

A cursory look at 2286198 as superseding 967715 leaves me wondering whether it really does (the latter dealing with autorun/autoplay functionality and the former not obviously having anything to do with that - nor apparently claiming to supersede any of the previous patches in that area). Rather than spend more time trying to analyze this, I'm willing to risk implying what may be a stupid question here (because you presumably can answer it off the top of your head). Please forgive me if I should have posed it somewhere else Thanks, - bill

The data clusters of a FAT32 volume can be arbitrarily aligned on a disk using available (often free) tools. The explanation below describes using them on old-style MBR partition formats (where the first partition on the disk normally starts at sector offset 63 and logical cylinders are normally defined as comprising 255 heads covering tracks of 63 sectors apiece) for those who may want to multi-boot among both older and newer systems (the newer systems and third-party software can usually be tweaked to honor the old format, but older software often cannot be used without risk on disks using the newer format), but much of it is also applicable to the new-style (Vista/Win7) partition format. One such tool is the free version of EASEUS Partition Master, which can tell you (in properties->FAT info) what the offset of the first data cluster is within a FAT32 partition that you create (the offset will vary based on the size of the partition and the size of its clusters, due to variations in the size of the FATs). Using that information, you can tweak the start-position of the partition (e.g., by first creating a dummy partition ending just before the desired start sector for a primary partition or 63 sectors before the desired start sector for a logical partition) such that the start position, plus the first data cluster offset, winds up on a suitable disk boundary. First, however, ensure that the logical disk geometry is seen as 255 heads with 63 sectors per track (if it isn't, it will usually become so - at least using Paragon Partition Manager - if all partitions on the disk are first deleted; the 255-head value comes from the BIOS int 13h 8-bit field and a Microsoft bug which had difficulty dealing with the full 256 heads): the total number of sectors in a logical cylinder needs to be an odd number if you're going to be able to adjust partition start locations to arbitrary points while still maintaining 'legal' (cylinder-aligned) partition locations for older software that may otherwise become destructively confused (the old IDE standard value of 16 heads with 63 sectors per track obviously doesn't meet this criterion, nor does the default 240-head geometry used on some old Thinkpads). Alternatively, you can use another tool such as the free version of Paragon Partition Manager to adjust the 'number of sectors per boot' (in create partition or format partition 'more options' for a FAT32 partition) to a value which will move the start of the first data cluster to an offset which, when added to the partition start location, will produce the desired alignment. For some reason I had difficulty doing this on a Win2K system with PPM versions later than 8.5, even though they nominally offered that option, but presumably they work with XP and later systems. NTFS and recent extx file systems seem to guarantee that the data clusters (if at least 4 KB in size) will be aligned at some multiple of 4 KB from the partition's start, so there's no need to play 'number of boot sector' games (which PPM doesn't support anyway for these file systems) with them if that alignment is tolerable. But the ability to place the partition start location at an appropriate alignment on the disk as described above can still be useful (both when dealing with RAID alignment and when dealing with 'advanced format' disks with 4 KB sectors when using XP and earlier systems). One reassuring thing about using this approach is that (with the possible exception of tweaking the 'number of boot sectors' in a FAT32 partition) the resulting disk layout is bog-standard, minimizing that possibility that any software (including random third-party software) will get confused by it.