RegCompact for Win9x

[Foxbat]

I cannot confirm this with the registry files on my 11-year-old Inspiron laptop. scanreg /opt in MSDOS mode did reduce the size of a never compressed system.dat (8905KB) and user.dat (1193KB).

I have not found the exact size where scanreg /opt will fail. Over the years, my occasional tests of system.dat of around 8MB or less optimizes successfully, and system.dat of around 12MB or more fails.

I have no idea whether running scanreg /opt leaves the content of the registry files unchanged, an undocumented feature may not have been tested sufficiently for release.

By default, the registry automatically gets /opt'ed whenever scanreg detects 500KB of excess space (until it hits the size limit), so it looks like it's pretty well-tested.

Edited September 16, 2012 by Foxbat

[PROBLEMCHYLD]

Another possible solution

[CharlotteTheHarlot]

Update to post #3.

I re-ran the DOS registry 'CREATION' process 4 more times with both 512 MB and 1 GB of RAM, once with SmartDrv and once without. Click the button in that post to see the results showing the substantially improvement using a disk cache.

After I resurrect a few more computers with extreme single-core speeds I will take that registry export and do the tests again to determine the sizable effect that CPU speed and L2 cache have on DOS operations like this.

[CharlotteTheHarlot]

1) After running RegCompact my 11-year-old laptop appeared to be a little bit faster and crisper, for example when running Norton Disk Doctor, opening Explorer windows or loading MS Word.

When I first started doing the REGEDIT /c registry creation was back on Win95 or maybe the first service pack. These computers mostly had 8MB of RAM ( and when you think about it, what a miracle that was running many programs in virtual memory! ). So any reduction of the size was immediately beneficial and I think I remember noticing faster bootups when using a compacted registry. Once the computers improved massively after the switchover from SDRAM to DDR, with CPU's going over 2 GHz I seriously stopped noticing the improvements and really stopped worrying about the holes. Of course by then RegCompact came along and I eventually moved into doing it all in protected mode as described in Post #4. Depending on the speed and RAM on that laptop it is either going to be noticeable or, well never underestimate the power of the placebo effect!. Seriously, with a stopwatch marking the bootstrap on an older machine ( SDRAM and 1 GHz or less ) I would imagine the difference in booting with an old registry vs. a freshly compacted one could be measured.

2) Are there any other benefits or uses of RegCompact?

I think the only real interesting uses ( except for those older machines again, SDRAM, slow CPU ) are as described in Post #4, and that is obtaining a freshly compacted 'holeless' new registry in about 10 seconds flat. That is why I used all the pictures in that post, so anyone that wants to try this will know exactly how to do it. This is as opposed to simply copying the binaries ( see the BAT file ), which also only takes seconds, but duplicates them bitwise, holes and all. However, someone that may be stuck on a i486 or early Pentium could use RegCompact to their benefit since it is so simple.

Here an excerpt from Jerry Honeycutt's book about the Win98 registry: "Registry Checker [scanreg] has an undocumented feature [/opt switch, only under DOS] that allows you to optimize the Registry. Registry Checker compresses the Registry whenever it detects that it has over 500KB of dead space"

I have to assume that what ScanReg /OPT does is the same thing that RegCompact does ( or vice versa actually ), which I believe is simply call API functions to read in and write out the registry in one continuous operation. But the fact that it is done in DOS is the dealbreaker even with SmartDrv loaded. It is my opinion that ScanReg was a poor response to creeping registry problems on Win9x, primarily aimed at quietly restoring an archived version when the existing one could not load. That is not a fix. What was needed was a complete re-write of REGEDIT in Win98 ( or earlier ) that accommodated large registries like I suggested by doing the /C work in Windows not DOS, also maybe adding some error checking and other features. It is my belief that they found these problems insurmountable and had already planned on the fork to NT shutting down Win9x so they didn't bother which is why that last attempt ( CLASSES.DAT ) was too little too late.

Under Win98SE I ran Beyond Compare v3.3.4 and made a Registry Compare of the active registry under Win98SE (i.e. the compressed registry files created by RegCompact v1.0) and the exported .reg file created in step 1 above (i.e. the exported Win98 registry before running RegCompact). The purpose of this comparison was to check whether the content of the compressed registry was identical to the content of the registry before compression.

1) It looks like the content of the compressed system.dat/user.dat and of the pre-compression system.dat/user.dat is identical, except for a few differences which still require investigation. If a registry expert repeats a similar experiment, maybe these differences can be explained. The problem is that Beyond Compare can compare a live registry against an exported .reg file, but not against a system.dat or user.dat file.

First off, I would doublecheck this work with WinDiff and also with FC /B both while in Windows. BTW, I also used ExamDiff ( with some tweaking to show all binary differences ). I found tens of thousands or hundreds of thousands of discrete differences between consecutively written binary DATs as shown above in Post #5 using RegCompact (but the exported data matches perfectly with just a few expected exceptions ) . I am working under the assumption that the holes in a registry ( including areas of reserved space such as @ "default value not set" ) are literally transparent placeholders, and when the registry is written out to disk, whatever was in place at that sector of the HDD remains in those 'gaps' in the registry binary. This accounts for those many 3 and 4 byte sequences that have different data in different consecutively written out registry binaries. However, there are other places I cannot account for where there is large-scale relocation of bytes. Now keep in mind I am talking about binaries saved by RegCompact, which I believe uses something like: "write 30 bytes, advance 3 bytes, write 45 bytes, advance 4 bytes ..." which we can think of as a vector operation, the gaps ( which are necessary placeholders not to be compacted ) are thus preserved. Contrast this with simply using that BAT file to copy the registry DATs a few times in a row and they will compare identically because these copies are a bitmap operation. The exported data from these very different binaries are identical, the binaries themselves can be thought of as a container containing exportable data, plus per-machine dynamic data, plus some undocumented bits.

Regdat can compare a live registry to individual .dat files. However, my attempts to check the compressed registries if there are any (unintentional) changes made by RegCompact in the previous thread failed. When compressing the registry, RegCompact flushes any pending registry changes to the compressed files, which makes sense since Windows is intended to be shut down after the compression. The very act of compressing the registry will modify it. Because of this, I could not get an unmodified compacted registry to compare to the original.

RegDat to the best of my knowledge is only comparing the exportable data in two registries ( which is exportable ), live or saved on disk. I believe he even describes this in the HLP by mentioning that the dynamic data and other such keys are ignored. Beyond that, the other undocumented areas in the registry would also be left uncompared. See my consecutive RegCompact outputs experiment which are compaction's saved only seconds apart from an unchanged registry ( and in one case changed by one byte ) as an experimental control to understand what to expect as the minimum threshold for changes between two binaries.

I have not found the exact size where scanreg /opt will fail. Over the years, my occasional tests of system.dat of around 8MB or less optimizes successfully, and system.dat of around 12MB or more fails.

I am quite certain that the number is quite variable from machine to machine ( from all those possible variables I mentioned ). This ties in to one issue that reared its ugly head in Win95 with PnP. Before those days, one could have a static computer with a steady state predictable environment at every single bootup because every resource was decided by the user via jumpers or shipped hard-coded and was never altered. Every session was a mirror of every other. With PnP and ESCD and later BIOS CMOS improvements that all went out the window and every session sees a non-identical environment than every other. The BIOS can reshuffle hardware resources and so can Windows, consequently there is almost never a predictable environment. This is manifested in BOOTLOGs where the order is somewhat similar but not identical. The net result is that a certain size registry might crash on this bootup, but may survive the next one particularly if one changes stuff in the BIOS ( flush ESCD was always a possible option to fix certain problems ). This could mean that 12 MB is okay on one bootup but fails another. Like I say, just make a BOOTLOG every restart, archive them all, and try to make sense of this situation by reading through them. Sometimes certain cards are enumerated and started, other times they appear to not be. Sometimes a list of fonts shows up, other times not. It could be that even the logging system is buggy and some events are simply thrown out. I am fairly certain though that that registry size number is very flexible.

But heck, at least it is very simple to do these experiments on Win9x. You can easily bloat up the registry like I showed by duplicating large keys, then run RegCompact ( keep your file manager aimed at Windows\Temp ) watch the output size, if not big enough do it again. save yourself a set of SYSTEM.DATs ranging from 11MB to 11.5MB to 12MB to 12.5MB to 13MB and then manually replace them in DOS and try booting and you should be able to determine the limit of that machine. Then you could go in and try adding or removing RAM and see how much headroom is gained and really answer some important questions for the rest of the Win9x users ( but I still think the results are machine specific and not really comparable for other users ). As you can see above, when I went from SYSTEM.DAT of 12,738,592 to 15,347,744 from added bloat ( duplicated Microsoft keys ) I went from a perfectly bootable system to a BSOD with a bogus VFAT error. Nailing down the trigger size should be easily accomplished.

EDIT: Foxbat, even though in this last question I know you were talking about ScanReg, by the time I started replying my mind had shifted to Windows generally and this last response is a bit off-topic. Sorry! It is a good question actually, whether ScanReg has a hard limit like 12 MB or whatever. I have no clue since I avoided the program once its purposes were known to me and easily substitutable by other methods ( I archived my own DATs, scanned my own registries, etc ).It certainly would be interesting to know why there is a hardcoded size limit to ScanReg, and if there is not, then what exactly are the conditions that causes it to fail and makes it appear to be a hard limit.

Edited September 19, 2012 by CharlotteTheHarlot

[I41Mar]

@ CharlotteTheHarlot

I think this is a possible download link for the 5° file in your list (contained inside the zipped exe file):

http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip

I41Mar

[Multibooter]

I think this is a possible download link for the 5° file in your list

Something wrong with your link, it doesn't work.

[jaclaz]

I think this is a possible download link for the 5° file in your list

Something wrong with your link, it doesn't work.

It looks like an old link.

This works:

http://wayback.archive.org/web/*/http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip

jaclaz

[PROBLEMCHYLD]

After running the app from the link jaclaz and I41Mar posted, I got a 48% compession and a slightly quicker boot time. Thanks guys

[CharlotteTheHarlot]

@ CharlotteTheHarlot

I think this is a possible download link for the 5° file in your list (contained inside the zipped exe file):

http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip

I41Mar

Yes, thank you! The executable in that installer in that zip is identical to 2000-12-01, of which I had no working links.

I think this is a possible download link for the 5° file in your list

Something wrong with your link, it doesn't work.

It looks like an old link.

This works:

http://wayback.archive.org/web/*/http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip

jaclaz

That is a strange thing!

If you click his link you get a parking page, if you copy the link ( the actual link, not the shown text ) and paste it into a new blank tab it directly downloads. They must have some script at that site that can discern between a clicked link and a pasted URL.

The link from Jaclaz also works ( but also from an interim page ) and is identical to the file from I41Mar.

I'll have to see if I can make it work as a direct URL in Post #2.

EDIT: still getting the interim parking page even using the URL that Opera saves in the 'Downloads' tab.

EDIT2: more strangely, Firefox returns: Server not found. Firefox can't find the server at xoom.virgilo.it.. Pasting the URL into a blank tab DOES work correctly, like Opera.

Edited September 21, 2012 by CharlotteTheHarlot

[jaclaz]

If you click his link you get a parking page, if you copy the link ( the actual link, not the shown text ) and paste it into a new blank tab it directly downloads. They must have some script at that site that can discern between a clicked link and a pasted URL.

Yes, I can confirm this, it works (in a new tab) both in Opera and in Iron, it must be something connected with the "referrer", something similar to this:

(click on second link posted by cdob )

jaclaz

[egrabrych]

RegCompact.exe ... 73,728 ... 1.0 ... 2000-11-18 - 19:59:26 ... 2000-11-18 - 19:59:26 ... Working OK! GUI=English ...... RegCompact1.0.exe (HERE)

Error 403 No hotlinking please

[Multibooter]

A direct download link is http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip'>http://web.archive.org/web/20060207052459/http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip

The link http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip , which I couldn't download directly via Firefox, downloads Ok with FlashGet v1.72.128. Somehow I seem to have a talent for picking out the alternatives which don't work.

The benefit of downloading from http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip with Flashget is that the original server upload date is maintained, which is 23-Jun-2007 8:04:40 AM. When downloading from web archive, somehow the file modification date is the current date.

[CharlotteTheHarlot]

RegCompact.exe ... 73,728 ... 1.0 ... 2000-11-18 - 19:59:26 ... 2000-11-18 - 19:59:26 ... Working OK! GUI=English ...... RegCompact1.0.exe (HERE)

Error 403 No hotlinking please

Yep, looks like that one is broke. No matter, just download the whole RAR instead. It has everything. I just updated it with the rest of the files too. That file will stay in place unless I hear a complaint from the author.

[TmEE]

10.01 seems to work with Regcompact and Irfanview... ?

http://tiido.rocketcat.info/Fileden/ThisVersionSeemsToWork.png

EDIT: Wrong topic, delete please

Edited September 22, 2012 by TmEE

[CharlotteTheHarlot]

The benefit of downloading from http://xoomer.virgilio.it/gloriosus/software/programs/regcompact1.0.zip with Flashget is that the original server upload date is maintained, which is 23-Jun-2007 8:04:40 AM. When downloading from web archive, somehow the file modification date is the current date.

Multibooter, could you try downloading this file, Process Explorer v10.01 with FlashGet and let me know if the DateTime is preserved?

I've tried with a bunch of tools ( don't have FlashGet yet ) and always get today's date, so I suspect that the server doesn't co-operate by sending the necessary info for the touch. I figure if you cannot get it, then there is no way.

Thanks.