Defragmentation software for Win9x

[dencorso]

Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

[jds]

Check. Unofficial 'COPY2GB.EXE' and 'SHELL98.EXE' updates.

@jds: While not mandatory, I usually add the Unofficial Win 9x Stack Corruption, 98KRNLUP, which installs Krnl386.exe v. 04.10.00.2000, to the mix, too. This completes the available updates to Win 9x core files.

Thanks Den,

So it's : Make sure to install the unofficial 'COPY2GB.EXE', 'SHELL98.EXE' and '98KRNLUP.EXE' updates, then the standard WinME defragger is perfectly fine to well beyond the "safe" 192G FAT32 partition size.

I was reading somewhere (maybe one of the links earlier in this thread) that "fast" defraggers (eg the WinME one) achieve speed by omitting safety checks. So at the very least, run ScanDisk prior to using them (probably wise to do that regardless). Also mentioned was the vulnerability to (power) interruptions. Does anyone know if this means the slower Win98(SE) defragger has more safety checks than the WinME one?

Joe.

[dencorso]

I don't know the answer to your latest question. But I do know that both the defragger and ScanDskW depend on the selfsame Dskmaint.dll so:

1) be sure to also use v. 4.90.0.3000 of dskmaint.

2) where scandskw works, so should the defragger, but if scandskw doesn't work neither the defragger does, so, at the very least, using scandskw is a good test to perform before going on to defragging.

The actual limit as to how big a partition may be seems to be related to the number of clusters in it *and* to how much of the common application memory space available to 16-bit programs (the "Shared Arena", see Q125691) is actually available in a given system. Also, please, do read this and this.

[jds]

The actual limit as to how big a partition may be seems to be related to the number of clusters in it *and* to how much of the common application memory space available to 16-bit programs (the "Shared Arena", see Q125691) is actually available in a given system. Also, please, do read this and this.

Hmmm ... In that case, I think the following is also required reading :

Joe.

[rloew]

The actual limit as to how big a partition may be seems to be related to the number of clusters in it *and* to how much of the common application memory space available to 16-bit programs (the "Shared Arena", see Q125691) is actually available in a given system. Also, please, do read this and this.

Hmmm ... In that case, I think the following is also required reading :

Joe.

The amount of available "Shared Arena" does not appear to be an issue. There is normally more than enough space to handle larger Partitions than these Programs can handle.

The Registry Size issue is unrelated to this issue and appears to be related to usage of the first 16MiB of Physical RAM.

[jds]

Hmmm ... In that case, I think the following is also required reading :

Joe.

The amount of available "Shared Arena" does not appear to be an issue. There is normally more than enough space to handle larger Partitions than these Programs can handle.

The Registry Size issue is unrelated to this issue and appears to be related to usage of the first 16MiB of Physical RAM.

Oops! I had thought the Shared Arena was the first 16M of RAM.

From http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Developer/books/T_IRIX_Prog/sgi_html/ch03.html, we have this :

Overview of Shared Arenas

A shared arena is a segment of memory that can be made part of the address space of more than one process. Each shared arena is associated with a disk file that acts as a backing store for the file (see “Page Validation”). Each process that wants to share access to the arena does so by specifying the file pathname of the file. The file pathname acts as the public name of the memory segment. The file access permissions determine which user IDs and group IDs can share the file.

So it sounds like the Shared Arena could be anywhere in RAM. Indeed, it sounds like there can be more than one Shared Arena. So it is no longer clear to me how such a restriction for the WinME (or Win98) defragger would arise, and indeed, I think you are saying that normally, it doesn't.

Joe.

[HardDriv'n]

Thanks Den,

So it's : Make sure to install the unofficial 'COPY2GB.EXE', 'SHELL98.EXE' and '98KRNLUP.EXE' updates, then the standard WinME defragger is perfectly fine to well beyond the "safe" 192G FAT32 partition size.

I was reading somewhere (maybe one of the links earlier in this thread) that "fast" defraggers (eg the WinME one) achieve speed by omitting safety checks. So at the very least, run ScanDisk prior to using them (probably wise to do that regardless). Also mentioned was the vulnerability to (power) interruptions. Does anyone know if this means the slower Win98(SE) defragger has more safety checks than the WinME one?

Would it possible for someone to condense, or edit, all this info into a single post, with links to all of the items? So... nobody has to read through the entire thread for all the requirements.

Maybe the OP could edit the first post?

[dencorso]

Yes, it would. So, I hereby name you, HardDriv'n, volunteer to do it. Please, feel free to go ahead.

[Multibooter]

Would it possible for someone to condense, or edit, all this info into a single post, with links to all of the items? So... nobody has to read through the entire thread for all the requirements. Maybe the OP could edit the first post?

Eventually I'll put a summary into the first posting, when most points have been covered. I assume there will many more postings. I would also be happy if HardDriv'n added a summary posting.

I have been using VoptXP v7.22 under Win98 to defrag the FAT32 WinXP partition before creating a .gho image of it and am very satisfied with VoptXP v7.22. Defragging an external HDD with huge files, where Vopt v7.22 locks up the computer, is not that essential to me at this stage. Here some very interesting findings:

1) I have tested the later version Vopt v9.21 under WinXP. Vopt 9 under WinXP takes about TEN to FIFTY times longer to defrag a partition than v7 under Win98. What takes 10-15 seconds under Win98 takes 3 minutes and often much longer under WinXP. This looks like a WinXP issue, or the focus on defragging NTFS has made defragging software very slow. Maybe Win98 is an operating system better suited for defragging FAT32 partitions than WinXP is.

2) I am currently installing a lot of software, which is running under Win98, on my WinXP opsys selection on the same computer. After the successive clean installations under WinXP of about 3 packages, or 3 hours of installation work, I go into Win98 and create a .gho backup of the WinXP partition with Ghost v11.0.2 (switches: -z9 -cns -fatlimit -szee). Before creating a .gho image under Win98, I run Vopt v7.22, it takes about 15 seconds to defrag the WinXP FAT32 partition. Vopt v7.22 reports then 0 fragments and 0 gaps for the WinXP partition to be imaged. I then run ScanDisk on the defragged WinXP partition and finally create the .gho image.

But, when I eventually restore the .gho image under Win98, using the same Ghost switches, then reboot into Win98 and then run Vopt v7.22 (Analyse only) on the restored WinXP partition, Vopt reports between 7-10 fragmented files. So Ghost, during its restoration of the partition image, turns an unfragmented partition into a partition with fragments.

I have used Vopt v7.22 for defragmenting before the creation of about 20 successive WinXP partition images. All created .gho images restored the WinXP partition fine. In one instance, however, WinXP crashed after the image restore. Then, when WinXP was run again, CheckDisk came up with cross-linked files, lost clusters and truncated files of key WinXP and Kerio Personal Firewall v2.15 files. The restored WinXP image basically became unrepairably unstable. After the 3rd attempt at restoring this .gho image of the WinXP partition, standalone Ghost v11.0.2 created a good partition image and WinXP came up without any complaints.

So if WinXP crashes after the restoration of its .gho partition image, one should not fiddle around under WinXP to get WinXP going, but instead repeat with Ghost the creation of the WinXP partition.

Edited November 24, 2010 by Multibooter

[rloew]

Oops! I had thought the Shared Arena was the first 16M of RAM.

So it sounds like the Shared Arena could be anywhere in RAM. Indeed, it sounds like there can be more than one Shared Arena. So it is no longer clear to me how such a restriction for the WinME (or Win98) defragger would arise, and indeed, I think you are saying that normally, it doesn't.

Joe.

The first 16MB of Physical Memory appears to be critical to some functions such as Ethernet. Some DMA Controllers are also limited to this range. Having a large Registry depletes this resource and causes problems.

The Shared Arena is a 1GiB range of Virtual RAM. There is only one Shared Arena but it can be scattered all over Physical RAM.

The limitations of SCANDISKW and DEFRAG are due their own coding and possible limitations on 16-Bit Code support in Windows.

[dencorso]

The limitations of SCANDISKW and DEFRAG are due their own coding and possible limitations on 16-Bit Code support in Windows.

Those limitations, in particular, is what interests me most, right now...

The limit for SCANDSKW.EXE (4.90.0.3000) is somewhere between 26.4 and 26.6 million clusters, or somewhere between 206.1 and 207.7 thousand sectors per FAT. It crashed with Marius '95 1 TB raid single partition (link), although 98-Guy has reported it works up to 31.2 million clusters (follow the links inside this post).

The 26.4 million clusters (or 206.1 thousand sectors per fat) is a real limit, which I think I determined very thoroughly (using a Corsair Flash Voyager 32 GB pendrive) as described in this post. However, it's clearly not the only one: now I have tried to run scandskw on a real big partittion, a 494,838,793,040 bytes ( 460.85 GiB), which has just 15,105,443 32kiB clusters and received the usual error message:

ScanDisk could not continue because your computer does not have enough available memory.

If any other programs are running, quit one or more of them, and try running ScanDisk again.

So there is a size limitation, too, which, in this case is hit first!

And it appears that the problem lies in dskmaint.dll, since using Tihiy's replacement scandskw, which is a true PE executable (32-bit) that, however, through shell32.dll, relies in dskmaint.dll, AFAIK, gives rise to the same error. Or the problem may be in shell32.dll itself. In any case, with all that thunking up and down going on, it's really hard to ascertain which processes actually ultimately rely on 16-bit code, without some detailed spelunking, in the Win9x/ME world...

[Multibooter]

I have tested the later version Vopt v9.21 under WinXP. Vopt 9 under WinXP takes about TEN to FIFTY times longer to defrag a partition than v7 under Win98. What takes 10-15 seconds under Win98 takes 3 minutes and often much longer under WinXP. This looks like a WinXP issue, or the focus on defragging NTFS has made defragging software very slow. Maybe Win98 is an operating system better suited for defragging FAT32 partitions than WinXP is.

I have installed VoptXP v7.22, the last version for Win98, on the WinXP opsys on the same computer where I am running Win98. Under Win98 VoptXP v7.22 is blazingly fast, under WinXP slow like molasses.

So when it comes to defragging FAT32 partitions, Win98 runs circles around WinXP. Win98 is the operating system of choice for defragging FAT32 partitions.

VoptXP v7.22 does not lock the system under WinXP, in contrast to under Win98. Perhaps the lockup-problem of Vopt when defragging huge files under Win98 can be mitigated by using WinME DLLs. Any suggestions? It would be interesting to see whether VoptXP v7.22 has this lockup-problem also under WinME.

I like old Vopt v7.22 (21-Nov-2003) under WinXP better than v9.21. I guess I'll keep Vopt v7.22 on my WinXP opsys, for defragging FAT32 partitions under WinXP, if needs must be, e.g. before burning a CD or DVD under WinXP, for good burn quality. For defragging NTFS I continue to use PerfectDisk v8.0.67 under WinXP, also for offline defragging of the FAT32 partition with the swap files,.

[jaclaz]

So when it comes to defragging FAT32 partitions, Win98 runs circles around WinXP. Win98 is the operating system of choice for defragging FAT32 partitions.

You haven't "the guts" to try Partition Logic :

http://partitionlogic.org.uk/

jaclaz

[RJARRRPCGP]

NDD detected lost clusters and displayed the error msg: "The boot area on this drive contains invalid information about the drive's free space. Windows may report the drive's free space incorrectly or slowly."

That occurs 99 percent because the PC crashed, the PC was hard powered off or you pressed the case reset button.

Edited November 26, 2010 by RJARRRPCGP

[Multibooter]

"The boot area on this drive contains invalid information about the drive's free space."

That occurs 99 percent because the PC crashed, the PC was hard powered off or you pressed the case reset button.

Thanks RJARRRPCGP, this error described in postig #31 has been bugging me for years, maybe twice a week, and the workaround was to reboot and run NDD. I can definitely exclude that there was a hard power off or that I pressed the reset button. In most cases when Win98 on my 10-year-old laptop freezes out of the blue and I then reboot, NDD displays this error message. Usually I was running too many programs at the same time with a heavy CPU load. This free space error has never occurred on my dual-core desktop under Win98.

I have considered this problem to be unsolvable, although I suspect that it's caused by using a 120GiB HDD which the BIOS reports as 64GB. The problem occurs on all my Inspiron 7500 laptops, so it can't be caused by the old age of a specific hardware component.

If you have any ideas on how to fix this problem, please let me know.

Edited November 27, 2010 by Multibooter