billtodd
Content Type
Profiles
Forums
Events
Posts posted by billtodd
-
-
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.
0 -
It seems that ClamWin and MalwareBytes Antivirus software are the only viable option now.
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.
0 -
Sorry for the late reply, I didn't see your post. Here's some info and my favorite links:
Please don't apologize: I'm grateful for any insights I can get.
NVIDIA no longer supports Win2000, but their packages are still online, even though you won't find them through searches.The latest version that works in Win2k is 18.11 (download here)
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.
GeForce Release 175 also works.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).
You can also get 14.10 here. You can also browse NVIDIA's ftp.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.
Most XP packages work in Win2k with small changes. See this thread, follow the instructions, it works!VERY good to know - thanks!
You can install each manually, or slipstream and Nlite the whole package for your favorite NVIDIA mobo and burn to CD. Or you can let Win2k search the drivers on CD through Device Manager. NVIDIA is my favorite and they also have better support for Linux.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.
0 -
Actually I had Windows 2000 installed on Foxconn A76ML-K 3.0 (AMD® 760G + SB710). I didn't experience any problems related to graphic cards (I used two - the integrated one + external one).
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).
You may want to try installing UURollup-v9b. I doubt it will help in solving this particular problem but it's the easiest way to install almost all unofficial updates at once. If it doesn't help then at least you'll be sure the problem is not related to system updates.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.
0 -
Have you tried enabling the "View -> Show hidden devices" in Device Manager?
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.
0 -
Hmm, I was thinking about these BlackWingCat's drivers:
http://blog.livedoor.jp/blackwingcat/archives/1114373.html
or
http://blog.livedoor.jp/blackwingcat/archives/1370860.html
What does programs like Speccy or Unknown Device Identifier say about your graphic card (when there's no displa adapter displayed in Device Manager)?
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.
0 -
I think you should at least try install BlackWingCat drivers. Those official installers from Nvidia are really bad... the drivers often don't install on Win2k even though they say the system is supported. On my previous mainboard I had to install everything from Device Manager because the Nvidia installer didn't install anything at all (although it kept saying that "the installation completed successfully").
How about also trying some older versions?
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.
0 -
Win2000 runs on all current AMD mobos, though sometimes installing it may take some work, see here for some pointers.
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.
0 -
Win2000 runs on all current AMD mobos, though sometimes installing it may take some work, see here for some pointers.
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.
0 -
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.
0 -
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).
0 -
Billtodd -
It fixes the MS10-046 security vulnerability relating to LNK files.
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
0 -
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
0 -
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.
0 -
Please forgive my vague memory about this (and my laziness in not refreshing it by running tests), but I may have had a similar problem after having updated the contents of \HF (in order to prune entries that had been superseded by post-1.7.9 patches) and then running the result with the 1.7.9 command file (I'm sure that doing so resulted in problems running the resulting .iso image from CD, where the size of the target 500 GB SATA drive got reported as 131 GB and the existing partitions on the drive were all reported as corrupt).
Clearly, removing those superseded patches (but leaving out the newer ones that had superseded them until the initial installation had completed, because I wasn't sure that the 1.7.9 command file could process them properly) had caused some updates needed DURING the installation to disappear. I seem to remember at one point forging ahead anyway and getting the boot device failure shortly thereafter.
Since then I've just used the 1.7.9 installation as-is and installed the later patches on top of the result without problems.
0 -
Am I still missing something?
The Data area is after the FAT tables, so the size of the FAT Tables can affect the alignment. This is why the Partition size is important.
So for FAT partitions there is NOT any fixed offset to the first cluster, and one would either need to use a standard partition size (for which that offset had been determined previously) or create the partition, check the offset, and then recreate it at a 'cylinder' boundary which would cause that offset to create aligned multiple-of-4KB clusters. (A complementary approach could tweak the partition size to affect the offset, I suppose - though since each 'cylinder' comprises around 2,000 4 KB sectors the required size change could be prohibitive unless the partition could be forced to end at other than a 'cylinder' boundary, which would introduce an undesirable peculiarity.) Throw in the 240-head case which you mention below and the benefits of your special format utility become more evident.
Is the NTFS offset fixed (or at least always created such that it's a multiple of 4KB)? I seem to recall discussions w.r.t. the alignment of database clusters that suggest that it is - and I probably could (and should) just try to dig up the spec to verify this.
Aligning some standard Partitions require a legal but non-standard modification to the Format. If your Computer uses 240 Head mapping, it may be impossible to avoid this issue regardless of Partitioning, if you use standard settings.
Since every 'cylinder' will begin at a 4KB boundary. This would be fine for any (non-FAT) primary partitions on the drive if their file systems aligned the first cluster on a 4 KB boundary w.r.t. the partition start (though you'd need to leave an unused 'cylinder' prior to the first partition), but logical partitions could never be optimally aligned.
Or you could perform all partitioning operations on a different system which used standard (255 x 63) 'cylinders' before populating the partitions on the target system - as long as you were prepared NEVER to use the target system to alter the partition layout (well, some utilities might be smart enough to handle it correctly, but Partition Magic certainly wasn't back when it was still otherwise reasonably usable). Fortunately, I don't foresee using a 4KB-sector drive in my ancient Thinkpad any time soon (do they still use that 240-head pseudo-geometry today?).
Thanks again for having taken the time to help clarify things. I may be overly paranoid about using any atypical partition layouts (internal or external), but between seeing how Vista/Win7 and older Windows systems can screw each other up and my past experience with Partition Magic's refusal even to LOOK at a disk partitioned on a system with differing pseudo-geometry without first 'fixing' it and thereby making it unusable I prefer to be conservative where possible in this area.
0 -
I was attempting to ascertain whether merely positioning partition start locations strategically on 4 KB sector drives that DO support 512-byte-sector emulation would be sufficient to allow several legacy operating systems of interest installed within those partitions without any modification (or special formatting) to suffer no significant performance degradation (e.g., to avoid almost all read/modify/write sequences caused by the larger sector size) - at least as long as those systems used file clusters that were multiples of 4 KB. As long as those systems do maintain consistent offsets to the first file cluster (and then manage free space such that clusters are tightly packed) I couldn't see any reason why this wouldn't work, but it's always nice to have such suppositions confirmed.
Yes. But Partition Size is also a factor.
If the partition start location is set such that the file system clusters (as long as they're multiples of 4 KB in size) will be 4KB-aligned on the disk, then unless there's some other non-file-structured system data that gets frequently written I would think that where the partition ended wouldn't matter (i.e., if it ended at some odd boundary the file system simply would leave the final few sectors that were insufficient to create another cluster unused - just as it has always done).
The trick is knowing how to do it and not breaking something else in the process.
I don't understand HOW anything could be broken as long as one used standard (pre-Vista) partitioning utilities to create the partitions: the entire point of this exercise would be to create bog-standard partitions using standard 'cylinder' boundaries carefully chosen to make virtually all disk access activity by legacy file systems 4KB-aligned (as long as those file systems used clusters that were multiples of 4 KB in size).
Even if one made a mistake in such choice the worst that should happen in the presence of 512-byte sector emulation is that small-write performance would suffer - at least as long as one refrained from using Vista/Win7 Disk Management to muck around with the partition structure without first telling it to use old-style partition alignment (a Registry modification which Microsoft appears to support).
Am I still missing something?
0 -
Thanks for replying.
Is it possible just to choose appropriate partition starting locations to get pre-Vista systems to work well with 4 KB sector drives, as long as they emulate 512-byte sectors (as I'd kind of expect them to do for a long time, at least as an option, if disk manufacturers don't wish to kiss the legacy aftermarket good-bye)?
Actually DOS 7 and Windows 9x can support 4KB Sector Drices WITHOUT 512 Byre Emulation with the proper modifications.
I was attempting to ascertain whether merely positioning partition start locations strategically on 4 KB sector drives that DO support 512-byte-sector emulation would be sufficient to allow several legacy operating systems of interest installed within those partitions without any modification (or special formatting) to suffer no significant performance degradation (e.g., to avoid almost all read/modify/write sequences caused by the larger sector size) - at least as long as those systems used file clusters that were multiples of 4 KB. As long as those systems do maintain consistent offsets to the first file cluster (and then manage free space such that clusters are tightly packed) I couldn't see any reason why this wouldn't work, but it's always nice to have such suppositions confirmed.
0 -
Did you search using the Wayback Machine?
I usually don't because it doesn't work 3/4 of the time I try it. But tried it now and got the name of the software and was able to download it (under WSC it's called "WSC Guard", under McAfee it's called "McAfee Wireless Security"). Such are things when most of the references just say "here's the link" or "google this and you'll find it". Doesn't work too well if it's not current.
If anyone else finds this software, you have to click "Disable Authentication" to be able to use the free mode of the software, which is the WPA networking part.
I also found an open source project called "WPA Supplicant" (which you can Google) which claims the same function.
YMMV on either, I suppose. When I find a wireless net card I like, I'll get to try both
I downloaded WPA Supplicant recently (after failing to find the WSC software) but never used more than its signal-strength check (at that point I finally got the card I was trying to use working normally). Just in case I or anyone else here might need the WSC/McAfee software in the future, describing how you found it via the Wayback Machine would be helpful (I just spent 10 minutes probing old McAfee pages without success).
Thanks,
- bill
Edit: Eventually found it under the WSC Web site in the archive: http://web.archive.org/web/20051228062502/www.wirelesssecuritycorp.com/wsc/public/BigRedButtonAction.do?sequenceNo=2 along with documentation (an earlier version of the page didn't have the download archived). If you found another version it might be useful just in case this one evaporates at some point.
0 -
if you happen to find the actual link on MS, I would appreciate it.
jaclaz
I read only the first page of your link above, but it did contain a link to multibooters.co.uk which contains a link to http://support.microsoft.com/kb/931854 (describes only losing a Vista partition after using XP to add a new one, but I'm pretty sure that there's another somewhere that describes - IIRC - losing all old-style logical partitions after a new one created with Vista/Win7).
0 -
Is it possible just to choose appropriate partition starting locations to get pre-Vista systems to work well with 4 KB sector drives, as long as they emulate 512-byte sectors (as I'd kind of expect them to do for a long time, at least as an option, if disk manufacturers don't wish to kiss the legacy aftermarket good-bye)?
E.g., for the normal case where traditional partitions are based on fictitious 'cylinder' boundaries (512-byte sectors plus the fictitious 255 heads and 63-sector tracks - i.e., 16065-sector 'cylinders' each a bit under 8 MiB; old Thinkpads and perhaps other systems used 240 fictitious heads, so would need to be handled differently), you'd just define a 62+ MB initial partition to create a suitable end-point, then create the actual desired partition after it with its start point a multiple of 4 KB from the start of the disk (then delete the preceding small partition if if you needed 3 more primary partitions).
At least if you were creating a partition for a Win2K or later NTFS system, where (IIRC) the file clusters (if a multiple of 4 KB themselves) begin at 4 KB multiples from the partition's start (yes, that offset may be configurable in the Volume Boot Record, but just in case some brain-damaged software is ignoring that it seems best to leave it 'standard').
But in FAT partitions (in all Windows environments, or just in Win9x?) my vague recollection is that clusters (even if a multiple of 4 KB themselves) are not so nicely aligned with respect to the partition's start. Perhaps RLoew's format utility changes the Volume Boot Record and first-cluster offset to fix this - but if one knew the 'standard' offset (if there is one, you could simply create a FAT partition with 4 KB clusters and see what the alignment was of some file in it) you could, again, just adjust the partition's start location to make the file clusters fall on disk 4 KB boundaries.
Logical partition placement is complicated by the existence of an Extended Partition Boot Record (one fictitious track, like the MBR 'track') embedded in but not actually part of the associated logical partition (so you'd need to have the preceding partition end on a 'cylinder' boundary that's 63*512 bytes before a 4 KB boundary to leave room for it - again, with a partition file system that maintained 4 KB cluster alignment internally, so adjust differently for FAT). Still, eminently feasible.
As I noted above, one of the reasons I prefer this approach is because it does nothing unusual that might cause traditional disk utilities to screw things up. For example, using pre-Vista utilities (including Windows Disk Management itself) on new-style Vista/Win7-partitioned disks can cause data loss (documented by Microsoft, though I don't have the link at my fingertips), as has use of Vista/Win7 Disk Management to alter the layouts of traditionally-partitioned disks (this last can be fixed by modifying Vista/Win7 Registry values to make them use the traditional partitioning layouts, but the former cannot).
So if offset-to-first-cluster is a standard value I'd prefer this approach on any disk where I thought I might wish to operate on it with pre-Vista partitioning software (which is still true for most disks I use, given my fondness for multi-boot environments). Any insights into whether I'm overlooking something significant here?
0 -
tommyp -
Indeed, you keep a running changelog in the first post of this thread. The fact that this thread is specifically directed at 'test releases', and the fact that its first entry starts with the statement "These versions are test builds and are pretty much stable. As usual, use them at your own risk", and the fact that it then redirects people (twice) to the 1.7.8 release, pretty much ensures that anyone looking only for base functionality rather than for the latest bells and whistles will first check out the 1.7.8 release and if it appears to offer the facilities they need look no farther (at least until they find it doesn't work, at which point they'll start notifying you of the fact, as I did: where I come from, released but not yet retired software that no longer works has a high priority for fixing - or at the very least documenting its limitations).
Perhaps you misunderstood my previous comment: it was in no way a complaint that you're not working your tail off (something I've come to appreciate even more as the complexity of this task became more apparent), or that HFSLIP is not a useful project. It was very specifically a comment to the effect that HFSLIP is poorly described as a tool. In particular (and I now realize that this is somewhat beyond your control at HFSLIP.org, but not here) HFSLIP 1.7.8 is presented as a stable and hence presumably usable tool, when in fact on any kind of on-going basis only a recent beta (assuming that it works reasonably well, which 1.7.9 s seems to have done for me) comes anywhere near that definition.
If HFSLIP is going to be presented as a tool that anyone with moderate technical skills can use, rather than as an interesting development project that anyone may participate in and perhaps benefit from, it needs to be presented in a way that people can use without knowing the kinds of things I've had to learn over the past few weeks about how it works internally and how it is maintained. One way to do this might be to track the most recent beta release that seems to have been reasonably stable, snapshot the set of updates that it worked well on, and present that as the release of choice for people just looking for a tool rather than a project. Any release presented as such a tool should be kept up to date *for that set of updates* - i.e., if some flaw in its handling of those updates is later discovered, it should be documented or, preferably, fixed (that's the definition of 'released' - as distinct from beta - but not yet 'retired' software, at least it was back when I was developing software more actively).
This is the second time that you've suggested that I was posting in the wrong thread, which demonstrates another area that could benefit from better explanation (i.e., what topics belong where).
Once again, I'm not requesting anything here save that you present HFSLIP as what it actually is. If you don't care to deal with anything but the current beta, just say that so that new arrivals will know that HFSLIP is not something they can 'just use'. If you want to take another relatively small step and create something that people can 'just use', pick a recent beta that works well, snapshot its associated set of updates, and point people there if they aren't interested in having a more intimate and on-going relationship with your project (maintaining that as a separate topic which gets reinitialized with each new apparently stable beta would give them a place to report problems so that others could see them and you could make sure that they're fixed in the next beta placed there, while otherwise keeping those discussions out of your hair if you don't have the time to engage in them).
Beyond giving people that minimal understanding of what they're getting into if they choose to try out HFSLIP I'm not suggesting that you have any additional moral obligations whatsoever: it's not as if you were getting paid for any of this, and the input presented here by others should make it clear how well HFSLIP is meeting its stated goals.
- bill
0 -
Got distracted for a while by real life, but I did mean to get back to the problems I was describing in the Windows Update topic.
It turns out that they don't seem to occur (though I did switch test machines too) when using the 1.7.9 S release rather than the nominally stable 1.7.8 release (I did mention at one point that I was using that release, but perhaps not prominently enough). Since HFSLIP.org encourages people to report problems in the forums here I did so; since I was using the stable release rather than a test release, I did so in what appeared to be the appropriate topic.
It might be helpful to explain (if indeed this is the case) that HFSLIP development (and in particular bug-fixing) focuses on the beta releases rather than on the stable release. It might also be helpful to capture a snapshot of the set of set of updates which the stable release seems to handle correctly and associate that snapshot with the stable release, since it appears likely that updates occurring after the freezing of that code may well not work correctly with it (at the very least, warning people about this would have prevented the kind of wasted time on both my part and yours that occurred). Failing that, I'm not sure what useful purpose having a stable release (and directing people to it) serves.
- bill
0 -
I never did get Win98SE to awaken from standby with this board but the problem here does not involve that - just letting the monitor power down after some period of inactivity (which I've never had any problem with in Win98SE elsewhere, and which it would do even on this board with the MX 4000 as long as the refresh rate was not set to 'optimal').
- bill
0
Slow subdirectory expansion in left-hand Win2K Explorer pane
in Windows 2000/2003/NT4
Posted
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).