dencorso

Post a picture or a scan of the HDD's label. You can put it in the scanner, if you have one, with cover open and just scan it, but take care not to look that way, while the scanning is in progress, because the light may hurt your eyes.

With so many used and new normal HDDs, how in heavens did you find a 4k sectored one? Yes, I think it may be a show-stopper. Let me think about it some more. I have to go now, but I'll be back later tonight. So, for the moment, either get a normal HDD or stand-by and do nothing, please, until my next post.

Yes. Active Killdisk (use the dos extender version, not the real-mode one, which is slower), RPM and LABEL must be run from true DOS, and a bootable CD is OK. XXCOPY16, the DOS version of XXCOPY will mangle the long filenames, so it's a no-no. You must run the Windows version of it, from inside a running Win9x/ME. I don't get why you didn't get the right XXCOPY already, because I gave a direct download link to it, just click on the blue "xxfw2965.zip" and it'll download. Yes, using the good HDD as primary master and the problem HDD as secondary master is OK, if the jumpers are set right on both HDDs... you're right, it should be simpler. But do check that the jumpers in the 80 GB HDD are set right to "master", OK.? Sure.

I am just wondering how many years it took you to get to that impression. Well, for sure less than 10 years, for I've been using it since v. 2.40 (Feb 2001).

Precisely. And 16,384 bytes / 32 bytes per dir entry = 512 entries. The just didn't spell it, but iths there all right. Of course, the entries I've mentioned are short filenames... otherwise, less than 512 files are possible becaus LFNs use more than one 32 byte entry, or, put in a differnt way, they use multiple entries for each file.

Well, I, for one, find RPM intuitive and user friendly! But if that turns out to be a problem, we then may select another tool. But I'd avoid Win 98SE FDISK just because it's part of what has been done before. The fact that I don't know about any bug in it does not mean there isn't any. I'm just being careful here.

The known issues are listed in the 1st section ("Symptoms") of KB120138. The "Applies To" section lists specifically Win 95 and Win 98FE as the OSes where those issues are said to happen. 0x(F)FF6 is truly dangerous to allow, as you just pointed out. However, there's still another thing to be considered, that's not on the current worksheet. Whether we agree to 4084 or 4078 as the maximum number of sector, adress of the last cluster will be 4085 or 4079, because we are counting from 2. When one counts from zero, the maximum address will be the total number minus one, but when the counting starts with 2, the maximum address is the total number *plus* one! The same considerations also apply to FAT-16, of course. KB120138 - Errors Creating Files or Folders in the Root Dir.pdf

@loblo: Yes, in principle. Then again, there are many free and paid-for alternatives to FDISK that are way better. RPM 2.44 is the first of the free alternatives that comes to my mind because it's time proven and reliable. PFDISK is another good choice, while FreeDOS's free FDISK is less satisfying. Symantec's GDISK and RLoew's RDISK are probably the best ones that are commercial. Moreover, in the specific example here, what I'm aiming at is the utmost reliability of tools I'm well acquainted with and which I know for sure should work beyond reasonable doubt. @DeadDude: Yes. For the exercise I'm proposing, there'll be no image at all, really. But that's no general solution, and can only be applied to Win 9x/ME. Most other OSes cannot be cloned while working. I, myself, use images all the time and love them. But what I'm trying to establish, more than anything, here, is whether there's a problem with the HDD, or (which is my current bet) the problem lies with your image acquisition/redeployment routine and/or software tools. So I though up a procedure that does not require imaging, but which can only work because we're talking 9x/ME and the actual hardware is just about the same.

Let's do a more controlled experiment: 1) Get Active KillDisk and use it to zero-out (= write 0s) to the whole of the problem 80 GB HDD. It takes dome time to complete. 2) Get the aforementioned RPM 2.44 and use it to write an standard IPL to the MBR, and to create and format exactly two partitions: the 1st, set active, should be a primary 40 GB partition and the 2nd, an extended partition with a single logical partition inside, spanning the rest of the disk. 3) Use the DOS LABEL.EXE command to give each partition a meaningful label, say, "PRIMARY" to the 1st partition and "LOGICAL" to the 2nd one. 4) Get the free version of XXCOPY (you must get XXCOPY FREEWARE v.2.96.5 - xxfw2965.zip, which is the last version that works in 9x/ME), install it to your working machine and use XXCOPY to clone the live system to the 80 GB HDD's 1st partition. To do this you'll need to either connect it to your internal IDE controller as a slave disk or, much easier, connect it by means of a USB-to-IDE bridge cable that you can get cheaply on eBay or at your local computer shop. Suposing you decide to use the USB-to-IDE bridge, and that your 80 GB HDD gets the letters X: (1st partition) and Y: (2nd partition), and you can ensure you got it right because you know the labels of the partitons, you can clone the live system by simply issuing the command: xxcopy c:\ x:\ /clone /yy /X"c:\win386.swp" 5) Put the 80 GB HDD back to its machine jumpered as master and reboot the machine. I bet it shall work all right, provided that you follow my instructions to the letter, using exactly those tools I indicated (not *any* others), and the exact versions mentioned. If, at any point, you get stuck, do not impovise, but instead post here and wait for my reply, before proceeding. Good luck!

Way to go, jaclaz! Now, here are my comments: 1) I do like standards myself, and ECMA 107 is a generally very sane one at that. However, putting 0x(F)FF0-0x(F)FF5 in use results in a whopping 0.15% gain in maximum size, but *is* less safe. So, my 2 ¢ here are, let's stick with the "other sources", which, pace ECMA 107, *is* a de-facto standard. 2) There is a misformating in the numeric "0" cells which are adjacent to the ASCII text "'000" cell thoughout the "clusters" page, so that instead of them showing "0", they show "-" (it's just a cosmetic issue, solved using "Format Cell", but since you favor, with good reason, locked worksheets, this should be set right for them to display nicely). 3) Testimage #1 and Testimage #2 are identical. 4) Although the BPB allows it, since the Root Directory Entries is two bytes long, more than 512 255 Root Directory Entries can cause problems, as described in KB120138. Your worksheet puts to use all that we've learned in our floppy/superfloppy/El-Torito discussions and more, in a wonderful way! You do rock!

The NT-Family OSes totally override the BIOS. They get rid of it during the first phase of booting (NTLDR/NTDETECT.COM), so they should work regardless of the BIOS. Linux, FreeBSD/OpenBSD and OpenSolaries do so too, so you cannot infer anything about the BIOS from their running OK. Go here, get DETECT, run it in DOS, both on the problem machine and in your identical one that works, and attach the results (zip 'em before attaching, please). Meanwhile I'll look for BIOS updates for that board... Found them here. And found out it's an ICH5 southbridge board! So I was thinking in the wrong direction. I was picturing a *much* older motherboard. So, now: it actually can boot standalone DOS all right, can it not? Your troubles begin after it tries to load Win 9x, right? How much RAM does it have onboard?

I doubt it. But, if so, he should try RPM 2.44, which way better than FDISK. However, I bet on the BIOS. Moreover, if it is one of the BIOS limitis he's hitting, it refers to the whole disk size, not matter how it is partitioned.

Your problem *IS* the BIOS. Read this. Win 98+ supports booting from a 1 TB HDD natively, all right. BTW, you never said it: What actually is the brand and model of the computer (or motherboard) and what's the BIOS version it has installed?

Well, I'm happy you found the source of your problem! Maybe there is some program to disable and/or reenable the AccuPoint from inside Win 95. Do search for it. BTW, here's a pic of an AccuPoint mouse, FTW what does it look like (as I was until I found this pic).

FDISK would delete the partition, but not zero it out. Killdisk can zero out the partition, without deletenig it. Deleting it, then recreating it to fill the full disk is pointless. All the data will stil remain there. Writing zeroes to all the sectors of the partition, on the other hand, will really clean it. That's what I think ought to be done. As to when, well, whenever it's best for you. There's really no hurry.

Do create a second back-up image, just in case. .vhd images are good in that they're browseable. Then use something really hardcore to zero-up the partition: Active KillDisk! They have a great DOS version with an interactive menu that allows very fine control. So you can just zero-up the partition. Then proceed to the plain vanilla install, add IntelliPoint 4.0, and let's see what happens. Good luck!

Thanks a lot, allan2! StuckRects2 is the way to go! You rock!

Is your Win 95 installed in a HDD partitioned as a single partition? << Warning: only proceed to try what I'm suggesting below after you understand fully the implications of doing it. Once started, there's no turning back! >> If so, save a full-disk image (not a common backup) of your current Win 95 installation, then wipe the partition, then reinstall Win 95 with no tweaks or configuring, just plain vanilla. Then add IntelliPoint 4.0, and let's see whether the wheel works or not. Then save a full-disk image of this plain vanilla setup. Then put back your original installation, by deploying the first image. At that point we'll be back to where we started, but much the wiser, and with a ready reference image to compare with your current one. Yes, it's a lot of work. But I think it's the best way to troubleshoot your issue.

I've been searching the Internet, and spelunking Win XP SP3 for some days already, but so far have had no sucess. Windows evidently remembers the height of the taskbar, from one logon to the next, but I just cannot find where it saves that info. Please enlighten me.

You might also try the Kensington Mouseworks 5.61, the last version to support Win 95. I use v. 6.11 under 98SE and v. 6.22 under XP SP3, with a MS Intellimouse Optical 1.1, and never had any problem related to those drivers. And I consider them much better than MS IntelliPoint. Of course, YMMV, but you do have little to loose, at this point.

ntdll.dll is userland's direct bridge into the NT kernel. So, missing dependencies to ntdll.dll usually result in major revisions to the code...

It seems they really never supported 9x/ME: this page is the earliest MS page available in the Wayback Machine regarding MSRIPv6 1.0, and it says: So, it seems MSRIPv6 for 9x/ME is just a urban legend...

Trumpet Winsock 5.0 remains available and supports IPv6, IIRR. It's shareware, so it's not for free, after the 30 day trial period. Peter Tattam is one of the internet pioneers who remains around, and he has recently also released a DOS IPv6 Stack (commercial, there is an older free version, but I think only the new one supports IPv6). There's also this rummor (source Warning: strong anti-9x/ME bias): Is there anybody here with time and patience to track it down? @Drugwash: Yes, you've got me thinking about it.

Selecting "Intellimouse Optical", "Windows 95" and "English" then hitting "Download Now" in this form also yields the Intellipoint 4.0 for 9x/ME. Now, the Wayback Machine rocks, or what?

Install while disconnected from the internet, then open Opera, go to Tools -> Preferences -> Advanced -> Security -> Auto-update and set it to "Do not check for updates". Then close it, reconnect the internet, and you're all set.