Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

RegCompact for Win9x

- - - - -

  • Please log in to reply
45 replies to this topic

#1
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag
RegCompact for Win9x

This thread was inspired by discussion in another MSFN thread, Puzzling Registry Size Issue. This utility is one of many discussed in that thread but since we were getting deep into the minutiae and mechanics of it's use I thought it deserved it's very own home. This thread can serve as a repository for it's description, use, testing, download links and other experimentation. If anyone wants to copy or move their posts from there to here please do so. The topic grew so quickly I needed to spread it over 5 posts to keep it manageable, but it allows for better link-back options. Here is the layout ...

  • #1 - DESCRIPTION, BASIC USE
  • #2 - DOWNLOADS, FILE DETAILS
  • #3 - THE EVIL WIN9X REGISTRY NIGHTMARE
  • #4 - ADVANCED USE
  • #5 - TEST RESULTS, PECULIARITIES


DESCRIPTION

One of many useful utilities created for the Win9x family was RegCompact by Daniel Werner in 2000. It is a registry compactor, that is to say it is a non-destructive tool that rewrites the current working registry to a new one, without any of the holes that can accumulate when parts within the registry are deleted, consequently leaving gaps in the middle. Registry compactors are designed to remove these gaps. The main thing to understand with the concept of registry 'holes' is this: No matter how many holes or whatever size exist in a registry, it will always always export to same size in ASCII text, however the actual binary DATs will vary in size. RegCompact or any other 'hole' remover changes the latter, reducing the binaries to their minimum possible size for a given set of data.

This is sometimes incorrectly referred to as a defrag operation, as is done for disks. During a disk is defrag, it certainly does mean that any 'holes' ( created when files interior to the used space / free space boundary were deleted ) will be effectively removed when all the files on disk are placed contiguously. However this operation includes re-ordering of the files which is okay because they are used by the operating system via an index ( i.e., it doesn't really matter where it is physically located ) and are not accessed in plain old sequential fashion. Additionally there is some optimal re-ordering as well with strategic file placement used to benefit performance by placing certain files at the outer edge of a disk where there is naturally a higher data transfer rate because of radically faster angular velocity. Therefore 'defrag' is a misnomer as neither of these traditional defrag features benefit the registry as it currently exists since the registry itself is just a collection of a few files ( aka hives ) totaling tens up to a couple hundred MB in size. If the registry were read and written constantly throughout a Windows session it might make sense to worry about location but it is normally only read completely at startup and written out later in small, infrequent periodic flushes.

RegCompact should also not be confused with a registry 'optimizer' or 'cleaner' or 'fixer' or 'repair' or whatever other euphemism is used to describe that far greater number of available registry utilities. These programs have as the main purpose the job of changing the registry, by allegedly correcting things such as structural problems, data errors, unneeded or obsolete keys, incorrect paths and myriad other items. Many of them do a good job, many do not, but these details are beyond the scope of this particular thread. My personal preference is to only use those 'cleaners' that have a safe, passive mode, meaning they will generate a list of potential problems and save this list to disk and then exit cleanly *without* making any changes. RegCompact effectively is a passive utility in the sense that all the data and structure of the registry is preserved, only gaps are removed. So it is clearly not to be confused with this category of registry utilities.

So what does a utility like RegCompact actually do? Well, what it does is to read the entire current registry ( which is in RAM or possibly partially paged out ) and then write it to disk as a completely new registry. Since it cannot replace the current in-use registry ( even on the relatively tame Win9x, certainly no chance on the locked-down NT family ), it must accomplish this by saving them to temporary files and then schedule them to overwrite the existing registry on the next reboot before the operating system loads. The exact mechanics of this follows, but first a quick recap:

Recall that on Win9x the registry consists only of a couple of files, Win95 to Win98se is SYSTEM.DAT and USER.DAT, WinME adds a third one called CLASSES.DAT ( a sizeable subkey relocated from SYSTEM.DAT ). The previous description and the rest of this post leaves aside the possibility of multiple users each with their own user hive since most Win9x systems will have the one user. Frankly I am not aware of how RegCompact will handle multiple users if at all. It does not seem to be mentioned in the README files and I do not recall ever trying it myself. If someone is feeling adventurous enough to test this circumstance please report the result so that others may learn. However, RegCompact is documented as working on WinME, in fact the exact cite is: "Any computer running Windows95, 98, Me, NT 4.0 or 2000 is supported." Feel free try RegCompact on WinME and report the results. However, in the interest of keeping things simple I will limit this topic to only what I have personally tested, and that is Win95 through Win98se with just two hives.

Anyway, the mechanics of RegCompact is to read the current registry, then write out the new registry as two new binary files with temporary names like RC1154.TMP and RC1153.TMP into the C:\WINDOWS\TEMP\ folder. It then uses the WININIT.INI mechanism to move them to their proper home in the C:\WINDOWS\ folder, overwriting the current registry files called SYSTEM.DAT and USER.DAT. WININIT.INI is a special kind of AUTOEXEC script using INI file syntax, it runs very early in the startup sequence ( in the DOS stage before Windows ), and it is executed automatically whenever it is found in the C:\WINDOWS\. In other words, if C:\WINDOWS\WININIT.INI exists then it is executed. Let's get the easy stuff out of the way first. More creative use of the program follows in a later post.


BASIC USE

If you are only interested in a quick compaction of your registry, RegCompact is very simple indeed, in fact just two clicks and your work is done. Run the REGCOMPACT.EXE file ( or a shortcut to it ) and it will quickly process the registry ( the first two screens go by rapidly ) and then a window will appear prompting you to click COMPACT. After doing that, a final dialog will appear asking you to click OK to reboot Windows so that it may replace the old registry with the new compacted one. Then you are done. Here are some screenshots that explain the simple 2-click process ...

Posted Image


That's all there is to it. Run it, wait a few seconds, click COMPACT, click OK.

ORIGINALLY POSTED: 2012-09-14. Okay, that's all for now. If anyone can add anything to this please leave details in the comments. Also, if you spot any errors, typos or otherwise please let me know. Thanks! :hello:

Edited by CharlotteTheHarlot, 14 September 2012 - 05:00 PM.

... Let him who hath understanding reckon the Number Of The Beast ...



How to remove advertisement from MSFN

#2
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag
DOWNLOADS

RegCompact's author, Daniel Werner has an official website called Experimental Scene where he has some pretty interesting and "Free Music Software For Windows", digital audio processing, DAW and VST effects, unfortunately the site no longer carries any mention of the RegCompact program. The Wayback Machine offers a glimpse of an archived copy. He seems to have moved on to NT editions with version 1.x and above. There is ( or was ) a .NET version ( RegCompact.NET.exe ) and now it seems a 'final' edition v2.6.7 exists here ( RegCompact Pro.exe ). Needless to say, the files for Win9x would have to be found elsewhere. When I began looking for working links to downloads for RegCompact, ironically I found a link back to a 2008 MSFN thread of which I had completely forgotten about, almost exactly 4 years ago to that day. I already had located 4 different binaries of RegCompact v1.0. And after further searching I located a 5th and then Jaclaz found a 6th, and Multibooter a 7th. Each file carries identical version resources, but two have somehow had their GUI translated to other languages. Several of the original v1.0 editions for Win9x have been successfully located on SimTel mirrors and elsewhere ( including working direct links to 2 of the 4 files I had originally ) but clearly there are very few remaining. Complete inventory follows below. Get the files while you still can ( don't ask me how they manage to scrub all these files from the Internet, but somehow they do manage to do it ).

RegCompact for Win9x ... 2012 Updated Links ...

-- Filename ------- Size -- Version --- MODIFIED DateTime ------- CREATED DateTime ----------- Testing Notes ----------- Working Links?
RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-15 - 05:36:10 ... 2000-10-15 - 05:36:10 ... NOT Working! ................. (none found)
RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-18 - 01:39:30 ... 2000-10-15 - 05:36:10 ... Working OK! GUI=English ...... Regcmp1a.zip (HERE)
RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-28 - 18:16:16 ... 2000-10-15 - 05:36:10 ... Working OK! GUI=English ...... Regcmp1b.zip (HERE)
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)
RegCompact.exe ... 73,728 ... 1.0 ... 2000-12-01 - 21:33:08 ... 2000-10-15 - 05:36:10 ... Working OK! GUI=English ...... Regcompact1.0.zip (HERE*)
RegCompact.exe ... 73,728 ... 1.0 ... 2001-05-28 - 20:48:52 ... 2001-05-28 - 20:48:52 ... Working OK! GUI=Italian ...... Regcompact_1.0.zip (HERE)
RegCompact.exe ... 73,728 ... 1.0 ... 2001-10-04 - 03:52:02 ... 2001-10-04 - 03:52:02 ... Working OK! GUI=Chinese? ..... (none found)

* ... the denoted direct download for 2000-12-01 uses some sort of scripting that gives you a parking page for the hosting site. If you right-click and copy link address ( or whatever wording ) then paste the URL into a blank new tab the download should directly execute.

NOTE: If anyone comes across more download sites please note them below, even if they are mirrors, and I will add them to the above. Want the Entire Set? I put the entire collection into a single RAR and uploaded it. If other versions come along and as time permits I will re-upload it with the latest set. Since RegCompact falls somewhere between 'donationware' and 'abandonware' I will leave this file available unless I hear from the author. Anyone interested in the files just click this button ...
Spoiler


VIRUS SCANNING. I have tested all known files and also have virus scanned them all as well ...
Results for file 2000-10-15 ... Jotti ... VirusTotal ... VirScan.org. 'Sunbelt': "Porn-Dialer.Win32.CapreDeam.BL (vf)" likely false positive.
Results for file 2000-10-18 ... Jotti ... VirusTotal ... VirScan.org. All clean.
Results for file 2000-10-28 ... Jotti ... VirusTotal ... VirScan.org. All clean.
Results for file 2000-11-18 ... Jotti ... VirusTotal ... VirScan.org. All clean.
Results for file 2000-12-01 ... Jotti ... VirusTotal ... VirScan.org. All clean.
Results for file 2001-05-28 ... Jotti ... VirusTotal ... VirScan.org 'ClamAV'/'ClamWin': "PUA.Win32.Packer.PrivateExeProte-15" likely false positive.
Results for file 2001-10-04 ... Jotti ... VirusTotal ... VirScan.org. All clean.



HASHES. Here are all the hashes as determined by NirSoft HashMyFiles ...

-- FileName ------- Size -- Version --- MODIFIED DateTime ------- CREATED DateTime ------------------ MD5 ------------------------------------- SHA1 ---------------------- CRC32 ------------------------------- SHA-256 -------------------------------------------------------------------------------------------- SHA-512 -------------------------------------------------------------------------------------------------------------- SHA-384 --------------------------------------------
RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-15 - 05:36:10 ... 2000-10-15 - 05:36:10 ... d6c48ea6219abd82c127cf38994e0ed7 ... eabef0b84fc357694daa2f528488f8ac1f615394 ... 98738fc3 ... 3a7860ff36209d68e6763afc500e9c62bdca2237998607fc16c03a0cd1b80169 ... 26262f1271f7ca40c8384a2397b9a2859e66978a965ea5a361d53ac33b80b788a1bfecb59dacdf866b2b41bbb6f7544f7c594bf51af48d7897373b1353a0f34a ... b82d19e5f46d4d761555f54ab4c049bb95679f8fe56ebb4be0efef2320db0495ab00292679315621629a767e49cf1327
RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-18 - 01:39:30 ... 2000-10-15 - 05:36:10 ... 328012d5badf9833ad645d7ca9b08b37 ... ab84d5248a8795470e7c7afcaf0994d18d28c01c ... 2e4d7e33 ... acbc0fc18df3256b13d8fef7b2df2a39565c5dd065fa5d3d68db8e6480c5ca8f ... 62ce76bfca289b92ba075a5388e59f464a011194e54ab05b043a6a79f7293f2a046c8ab9a8fb0960efd4714d03613480b5636fb5c2bc892c08ffb6ccba3741b2 ... 7705722e7c527741fca51a06fd905c37c07f3ebced4e0902ba19459acb2bc773d751a0cce307c5de86b8dfc48c0c8ca4
RegCompact.exe ... 73,728 ... 1.0 ... 2000-10-28 - 18:16:16 ... 2000-10-15 - 05:36:10 ... f5e3fbb6209a0ed15e82be0f2b1847f7 ... 52ab8b8d344c8935e8ff13b6f05a226992008e88 ... 00b40b76 ... 650e939a133da9573ea09b800bd220fb1fe58a00aabd31a3515997aba04097e8 ... 3bdb9a9a4f143aa56334fd2bbd6deb3691f1972bc3ace1070913868e5873957d5f70c827fd111d4a3e80889f65303e5c5814f6f85d3de4a83fc2fceb2df20b4b ... eb8ff46128b2cb57d4897e73b4f14a816d5cbfdb3d142ddec02c1c813901e7ca867b08ce49e6266d0cb6f9e5334060d4
RegCompact.exe ... 73,728 ... 1.0 ... 2000-11-18 - 19:59:26 ... 2000-11-18 - 19:59:26 ... 3610d8baac81a9a7f44a2a8e02c8eca1 ... 592fe9a6e9ea80a7e61cbe1089fffb315c2b2b6b ... 29ff541c ... fbfe55fa3da0490aa5e0bb038fe340973e5358c5161cc815656eb221e59c3bc9 ... 12ed5445d9652bd5ed74d3515bc0152388e366e48f51ec849040ce65554c97f01f8bb74533a65a4f56f13e7d319fc0389d05f848462bea5a016cd592b00f6f39 ... 03dfe7f89e136a7513dcefe0adb39d7b1abcab7942cd577b9de4ba8d45255aa619412f4d815cc5d8c9d4e78c97495652
RegCompact.exe ... 73,728 ... 1.0 ... 2000-12-01 - 21:33:08 ... 2000-10-15 - 05:36:10 ... 5749eb12f8c4f4fa3f2489e62a0c1531 ... a983554b5b05650ae9e56281181d1ed6f3c281f6 ... 036ee115 ... 246d78e5b9964b7d4593076da69ced1a1cb44b0016e9272922f0a7aa80bb45ba ... 5cc9de44ed8cd847941b7e4943748ea15dd53d2af56ab7e38dad37bfbc5280e01c0ddf6f985c41cbde5b81bd1a95b3391bb607d54b08b75da7fb352cafb19611 ... fe66a3fac84b429513ceb7321d6a4a540746f595ca1cc23f2b62271b0348ca949f0793cea9f337c8317125e4021ed12a
RegCompact.exe ... 73,728 ... 1.0 ... 2001-05-28 - 20:48:52 ... 2001-05-28 - 20:48:52 ... fa3f9649f5f5f74b7036a48bcf205d42 ... df965ebc291afe6556f423420703511b2db7574d ... bef289d7 ... ea350d5ea624ce0b7985e7db6d85eb700bf25ff1f3d90ad46ba3bd23f4e7164b ... b801b29768cad3dab3ec6e4ebe28df8d15e9e2cda6d318f71bf6ba50feef1ecef45f8ffb78aa9c0ff0f218336ce1ccdb9edab19f11673e071ba622fc5754d968 ... c2b713c9c77865bef601b602ee8f649de0521053541fd3ad926cf5af2f6fe11b3208ea36295c250de8a4f01f9ccc85a2
RegCompact.exe ... 73,728 ... 1.0 ... 2001-10-04 - 03:52:02 ... 2001-10-04 - 03:52:02 ... 3d5df950b2dcae3b886c4fc625a4f512 ... 2bf6d1d1646346af1473c69b484e5b7febef7497 ... 31d48067 ... 044d18bd359f8b910ff4d3fcd7251601da26a1eaa62b0b3aaafadfadbfca9022 ... 19310335d29becafd26f7c953436b94fa5995a37f46aa92fc2adda71b3d5ab51c643576b1a7b0b3e17da604641ce1e65c4d7dca1c511c3fade1427fec6b2884e ... 6a7512d6a8401a673e17b85eb72933292cd465a09dbabc586e3897262b1b865ef3cc30442efd12fa668e641c7047b1de


FILE DETAILS

The executable files are all identical in size. In the file version resources the languages of all are listed as English (Australia), so presumably all post-compile translation patching left the version resource strings unaltered. They all show v1.0 and a Copyright © 2000 Daniel Werner.

NOTE-0: The oldest known file 2000-10-15 simply will not run. It appears to have a buggy Windows version check because on Win98se it fails with the error message: RegCompact does not yet support WindowsME.

Posted Image


NOTE-1: The 2000-10-18 and 2000-10-28 and 2000-12-01 files come in ZIP downloads ( REGCMP1A.ZIP and REGCMP1B.ZIP and REGCOMPACT1.0.ZIP ) and they have an installer EXE inside the ZIP named RegCompact1.0.exe which is easily extracted using WinRar ( no need to run the installers ). UPDATE: I believe we can say that the 2000-12-01 is the latest official version from the author because the installer SFX has the most recent date of 2003-10-18.

NOTE-2: The 2000-11-18 file is found in the download named REGCOMPACT1.0.EXE and is itself an SFX installer easily extracted with WinRar ( no need to run the installer ). Note that this SFX installer is equivalent to the previous two above except that those enclosed the SFX into a ZIP.

NOTE-3: The 2nd newest executable 2001-05-28 ( inside the ZIP ) is UPX packed to 37,376 bytes. The results shown above are *after* unpacking naturally. This is the one that runs with Italian in the GUI. The README is named LEGGIMI.TXT and appears to have the same information found in the others, but with the translator credit. This download, REGCOMPACT_1.0.ZIP has no installer in it, just the UPX packed exe and doc.

NOTE-4: The newest executable 2001-10-04 like the previous one in Italian is also apparently just language patched. The GUI shows either empty square blocks and Asian characters, my guess is a Chinese translation. Here is a screen shot with the three language variations shown ...

Posted Image


If you would like to read the documentation, here is the most recent README.TXT I found dated 2000-12-01. Press the button ...
Spoiler


ORIGINALLY POSTED: 2012-09-14. Okay, that's all for now. If anyone can add anything to this please leave details in the comments. Also, if you spot any errors, typos or otherwise please let me know. Thanks! :hello:
EDIT: typo
EDIT: added a download URL found by I41Mar. Updated the RAR collection too. More typos.

Edited by CharlotteTheHarlot, 21 September 2012 - 11:58 PM.

... Let him who hath understanding reckon the Number Of The Beast ...


#3
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag
THE EVIL WIN9X REGISTRY NIGHTMARE

In a nutshell, this problem can be nothing short of Cruel and Unusual Punishment. So let's first remember how we got here. The problems can all be traced back to a single reckless decision made by someone on the Windows team during the Win95 Chicago development. That decision was to encourage all software authors to store their settings in the System registry. Prior to this it was standard practice for software which required it, to maintain it's persistent settings in a private file. a .CFG or .INI or .SAV or .TXT or any other filetype or combination of files, binary or plaintext, whatever the author chose. Microsoft's rationalizations for the change included "There's all these INI files scattered all over the system!" or "The registry is much faster!". Yeah, that's pretty much true but completely beside the point. The registry also contains 99% of the core system configuration, and that means no registry = no system. Inviting every single software application or utility to have read and write access to the SAME database that contains the system configuration, well, what could possibly go wrong? The answer of course would have been for Windows to maintain two registries, one for hardware and one for software ( other than the Windows OS ). The former would only be written to at SETUP and for patches, service packs, hotfixes, updates, hardware upgrades and device driver updates. Most importantly it should have been machine specific. The other registry should have been completely hardware independent. Not only would this have built a firewall between Windows and everyone else, it would have prevented that other disastrous problem from ever occurring - the necessity to reinstall every piece of software after reinstalling Windows since that operation creates a new registry, wiping out everything else.

The official sanctioned method for generating a new registry without the 'holes' is by using REGEDIT.EXE with the /C switch while in DOS ( FYI, REGEDIT is a dual-mode executable containing code for both 'real-mode 16-bit true DOS and protected-mode 32-bit Windows ). This official method was often found in many software packages that operated in 32-bit Windows but when you selected an option to compact the registry it would punch some commands into AUTOEXEC, reboot into DOSMODE and launch a batch file scripted to execute the REGEDIT /C (yikes!). A failure here could be catastrophic. This is how things went until a handful of 32-bit programs like RegCompact made the logical step to creating the new registry while in Windows where a failure would be insignificant. Anyway. this is all that Microsoft gave us, and when it failed it was very painful as we'll see in a minute. F8 Command Line DOS: that bare DOS environment is available via the F8 keypressing when the booting computer is just finishing the BIOS and about to start Windows, and is one of the favorite features of the Win9x environment ( unfortunately hidden in WinME and completely lacking in the NT family ). It's availability is due to the bootstrap method of that era where some real-mode DOS files are first loaded prior to the switchover to protected mode Windows and at that specific point there is a small window of opportunity to intercept the sequence and tell the bootstrap to "stop here and let me into DOS please" ( hence the F8 keypressing to be sure to hit the right spot ). This naked DOS environment is especially useful to the expert user because they can replace any file existing on the system without interference from Windows file protection. So if you have a virus or are testing device drivers or patching low-level core files, or as in this case replacing the entire registry this can be easily done via traditional DOS commands after entering F8 Command Line DOS.

Anyway, it is what it is. We have a monolithic registry file ( from the user and from the software's point of view although it is multiple files on disk ) and it can be broken in several ways. Two manifestations of this breakage came up in another MSFN thread here. What can happen in Win9x is that the registry grows in size and complexity and consequently it can both fail to be loaded at bootstrap or it can fail to be created when you use the proper REGEDIT /c command from DOS to rebuild a new registry without 'holes'. My description and speculation of these two problems from that thread:

My understanding is that there are two major but separate registry problems in the Win9x family ...

CREATION ... This occurs in DOS when the real-mode part of REGEDIT using /c cannot create one of the DAT files It is trying to rebuild a new registry ( output binary ) from a previously successful export ( input ASCII ). I discovered this way back in Win95 before the OSR updates corrected it ( temporarily ), when certain software moved all of its settings from private files into the registry and doubled the size. It was cat and mouse for the next few years but eventually even for Win98se large exports couldn't be /c created. Before WinME, the patching and backporting of a later REGEDIT version ( e.g., from 95osr to 95 ) allowed successful creation, but we ran out of luck when WinME changed REGEDIT ( it separated CLASSES out of the SYSTEM hive as a last ditch effort to make it manageable ). The reasons for this CREATION bug seem to be registry size, complexity, available RAM, ( and possibly CPU model, speed and cache ) so it is a chaotic and unpredictable problem, and pretty much unsolvable. Remember, this is the 16-bit universe and even before WinME Microsoft was already breaking things and leaving them broken. :realmad: Microsoft could have fixed this in the 32-bit portion instead, but I am guessing that they did not want to give REGEDIT an option to output binary DATs to an arbitrary selected folder which would be necessary since it cannot overwrite the current in-use registry files. A 32-bit registry tool that can do this ( output binary DATs to an arbitrary selected folder ) would be very desirable for Win9x, hence my previous comment.

LOADING ... BSOD protection error preventing successful bootstrap because one of the DATs cannot be successfully read or loaded. I had long thought that this was for all the same reasons, registry size, complexity, available RAM, etc, but here on MSFN RLoew has also discovered a connection to networking in some way. Consequently, a surprised and unprepared Win9x user is screwed at this point. However a well-prepared user has saved many DAT backups and thankfully in Win9x it is simple to change registries in F8 DOS command line. It is very possible while in Windows to absolutely overload the registry with imports ( or just install every SDK ) and it will appear fine as it fits within the protected-mode available memory space, but then it BSOD's on reboot. With great perseverance a person could manage this situation with lots of REG files used when in Windows and have REG 'deleters' to remove them before restart, and/or have fallback DATs ready to be copied in F8 DOS.



FURTHER DETAIL. These are two different problems entirely but as alluded to they likely have most of the same causes in common. Actual Example. In my own case it was back on Win95 while working at a recording studio when I discovered this evil bug. What happened is that the software from an important hardware company ( ~cough~ Creative Labs ~cough~ SoundBlaster ) followed Microsoft's brilliant advice and moved all their EA presets ( environment presets ) into the system registry. This was many megabytes of strings of seldom used data that bloated the registry to twice the size. Most computers only had 8 or 16 MB total RAM at the time and when the registry was loaded at Windows start a variety of errors would show up. This is the LOADING bug in action. Yes, I thankfully had many backups of the DATs. The workaround was to delete out all the presets except for the one or two that were used by the studio employees. However, as you might have anticipated this immediately led to the other problem, the CREATION bug. Obviously after you delete many megabytes of data from a live registry you have substantial dead space in that registry ( 'holes' ) so now you should go an compact it following Microsoft's instructions to export the registry and re-create it in DOS. Yep, the other problem shows up depending on the export size and complexity. Note: Creative Labs did not cause this particular CREATION error, but they forced us to discover it by instigating the DOS registry creation step. No workaround for this existed yet in 1995-1996, but it did once OSR came out in late 1996 but it wasn't until early 1997 that someone figured out we could just version patch the REGEDIT.EXE from OSR ( 4.00.1111 with presumed improved memory management and other optimizations in DOS ) down-level to Win95 and it would successfully finish the REGEDIT /C procedure when using large exports. This was obviously not sanctioned by Microsoft, and I do not recall them even addressing it. These were fun times indeed, and really the precedent was being set that Microsoft's expert user base would become the ultimate problem solvers since Microsoft was already getting comfortable letting broken things stay broken. We now know that the CREATION problem could have been avoided entirely had REGEDIT.EXE working in 32-bit Windows protected-mode simply allowed the ability to save a new registry to an arbitrary folder instead of only operating in DOS real-mode. In other words, just let REGEDIT export binary, simple! That LOADING problem when it occurs is a big deal because at that point the registry exists as the two files SYSTEM.DAT and USER.DAT and they will either be loaded successfully or fail to be loaded, it is make or break, and on a failure you DO NOT get a nice detailed explanation at all. In fact the displayed error message is almost always completely unrelated to the registry and will send the poor victim on a variety of wild goose chases.

DEMONSTRATION. Well, I decided to give it a go, one final time here in September 2012, revisiting the registry CREATION failure, and also the registry LOADING failure at bootstrap, both due to a large registry. Experimental Control: I carefully designed this experiment methodology to use only one of those possible variables ( registry size, complexity, available RAM, CPU model, speed, cache ). In this case I will make it crash solely due to size. The proof is simply that this is a working registry and only volume will be changed with no added complexity, and no hardware alterations. So I needed a quick way to bloat the registry on a Win98se machine to force both the CREATION and LOADING bug. I finally settled on duplicating two working but already massive keys. I exported both HKLM and HKCU keys rooted at Software\Microsoft, and placed them in a script. Then a quick search-replace the following ( before and after ) ...

HKEY_LOCAL_MACHINE\Software\Microsoft
HKEY_LOCAL_MACHINE\Software\Microsoft2

HKEY_USERS\.default\Software\Microsoft
HKEY_USERS\.default\Software\Microsoft2


Now all you need to do is import those two beasts ( or just drop the script into the open REGEDIT window ) and presto, registry mega-bloat! Reminder: at this point you are sitting in Windows 32-bit protected mode looking at a normal REGEDIT window. Within a few seconds there will be a flush of dirty data in RAM to disk. SYSTEM.DAT and USER.DAT just grew much larger but you wouldn't know there are any potential problems until you reboot. If you now simply export the current registry ( and I did ) it will show the new bloated structure. Here is the before and after ( NOTE: these numbers DO NOT represent any kind of useful comparison to anyone else's computer ) ...

;--- Original Registry Size
SYSTEM.DAT ... 12,738,592
USER.DAT ...... 3,686,432
Export.reg ... 21,075,255

;--- Registry Size after adding bloat
SYSTEM.DAT ... 15,347,744
USER.DAT ...... 3,829,792
Export.reg ... 25,804,411


Once again, by simply duplicating the Microsoft key, no complexity is added, just a dummy key that will NOT be accessed by the bootstrap process. This means that a LOADING failure is solely confined to registry size, and nothing else. BTW, if your system has more 'headroom' and needs more registry size bloat to crash, you can just create a 3rd or 4th key ( HKLM\Software\Microsoft3 ... HKLM\Software\Microsoft4 ... etc ). Rinse and repeat as needed.

Registry LOADING Error. So first I simply do a nice reboot just as any unsuspecting user might. What could possibly go wrong! ( Really, just imagine Joe User who just installed some giant SDK or something that added a massive chunk of useless data to an already large registry. The thing is working just fine in 32-bit Windows. He shuts down and turns the computer on the next morning ... ) ...

Posted Image


The first thing to note is that error message says nothing about the registry. But I can absolutely guarantee that NO OTHER VARIABLES CHANGED except for registry size. So why does it mention VFAT? My own theory is that it was simply due to running out of available memory at this particular step in the startup. Presumably with a different amount of RAM or larger registry size the error would have occurred earlier or later in the bootstrap process possibly resulting in an entirely different error message. I invite others with far more knowledge to explain it more accurately.

So we have established the critically important fact that this BSOD has NOTHING TO DO WITH VFAT or any other VXD. Obviously this is where the average Win9x victim begins his time wasting search for VFAT problems, replacing files and maybe even re-installing Windows. With a slightly different error message the time-wasting search will lead them down all manner of other wild goose chases. Just imagine the many hapless Win9x users stuck at this point. Very few of them likely had sufficient backups of the binary DATs or the knowledge of replacing them manually in DOS ( if on Win98 one could try SCANREG in DOS and quietly revert to an older DAT saved in RBxxx.cab, and now we know why there is such a thing as SCANREG in the first place ). Prior to SCANREG non-experts were simply out of luck, and I would suggest that even with it they still are since reverting to an old registry is not a real solution, especially if it contains older or different hardware and software keys. Only the well-prepared and 'expert' users are not sweating this BSOD, since they can simply drop into DOS and replace the two DATs, and all would be back to normal.


Registry CREATION Error. So I reset the computer ( BTW, that BSOD is a hard lockup, CTL-ALT-DEL will not work here! Only a Power-Off cycle or pressing a physical RESET button attached to an ATX+ power supply will work ). As it booted I got into F8 Command Line DOS and CD'd over to my test directory where I have an ASCII Export of this bloated registry waiting for me ( this should be fun, NOT! ). So now we nicely ask the official Microsoft sanctioned REGEDIT to create a new set of DATs from the 25,804,411 byte registry export. REGEDIT /C Export.reg ... and ... be patient ... really ... really ... REALLY ... patient! ...

Posted Image

Ah fun times again. That camera shot was at 11 minutes into the nightmare. But why explain when I can just show you the actual times that I checked ...

06 minutes = 12%
08 minutes = 13%
10 minutes = 17%
11 minutes = 18%
1.5 hours! = 26%
2.5 hours! = 28%
3.0 hours! = 30%
3.5 hours! = 31%
4.0 hours! = 32%
4.5 hours! = 33%
5.0 hours! = 33%
5.5 hours! = 34%
6.0 hours! = 35%
6.5 hours! = 36%
7.0 hours! = 36%
7.5 hours! = 37%
8.0 hours! = 38%
8.5 hours! = 38%
~12 hours! = Failed


Words cannot describe the feeling after one of those failures in the old days ( well there certainly are words for this, but they are NOT appropriate for this forum ). There must have been more than a few occasions where a sledgehammer met a Win9x computer. Most often I would let the machine go overnight, and hope that I didn't wake up to this ...

Posted Image

Never mind the fact that the "previous registry" happens to be the one that blue screened with the bogus VFAT error. :realmad:

UPDATE: In the comments below, Rudolph Loew reminded me to use SmartDrv in the DOS registry creation process. Talk about Doh! :blushing: Trust me, I knew this 17 years ago, did it routinely, but I completely forgot about it when doing these tests. That disk cache absolutely did substantially speed up the process.

UPDATE-2: I have completed running this operation four more times. Test was conducted with both 512 MB and 1GB of RAM, once each with and without SmartDrv. Running this disk cache will effectively increase the speed of the operation six-fold, reducing the entire duration from 12-hours to 2 hours! Click the following button for the results ...

Spoiler


Remedies. I had a variety of solutions back in the day. The most elaborate was to use a different computer, the fastest single-core that could be found and perform the operation there ( REGEDIT /C is simple binary output, it has no machine check or error testing ) and grab the new files if it was successful. Actually, this computer is clocked just shy of 3 GHz so there really isn't anywhere to go except up a few hundred MHz ( at least in the Intel universe ). There was no way to patch WinME REGEDIT ( that I am aware of ) to use two hives and backport it to Win98se as we had done in the past, even if it would somehow work on larger files. This sums up the pressing need for a way to CREATE a new registry in Windows. Hence the reason I created a kludge utilizing RegCompact we'll see later.

Further Experiments. If someone wanted to pursue this further, perhaps to trigger some of the other possible variables instead of size ( e.g., registry complexity, available RAM, CPU model, speed, cache ), there are many possible ways to go about it. For testing memory amount, obviously RAM can be simply pulled out ( NB: this computer was 512 MB ) and replaced with smaller amounts down to even 8 MB. Inversely, someone might try with more RAM. For complexity one might edit the script to use multiple subkeys ( e.g., HKLM\Software\Microsoft\1\2\3\4\5\6\7\8\...\999\ ) or just research what happens in some versions of RealPlayer that installed values that were too long, among other mistakes. If the BIOS allows you could DISABLE the CPU L2 cache, or underclock the frequency to see if the registry can be loaded successfully. However, I will not likely be doing this myself because this a 17 year-old nightmare that I would prefer to leave alone. This was most likely the last time for me.

How Do You Protect Yourself? Just keep a shortcut handy to a batch file that copies the two binary registry files to a folder on demand. Run it often. Definitely run it before installing some gigantic pig of an application or SDK that might push your registry past the point of no return. I always used one that added a DateTimeStamp as a suffix to the files and ran it often, piling up a collection of registries to rollback to if I ever needed it. Yeah, SCANREG can be set up in a similar fashion, but this is much faster and no CAB files are involved. This one has only one dependency, a 3rd party 16-bit DOS app called FDATE that is still easily found ( link is in comments within the .BAT). Click to see it ...
Spoiler


ORIGINALLY POSTED: 2012-09-14. Okay, that's all for now. If anyone can add anything to this please leave details in the comments. Also, if you spot any errors, typos or otherwise please let me know. Thanks! :hello:
EDIT: typo, added registry backup BAT file, colors
EDIT: 2012-09-18 ... re-ran registry CREATION and added spreadsheet comparison

Edited by CharlotteTheHarlot, 18 September 2012 - 08:52 PM.

... Let him who hath understanding reckon the Number Of The Beast ...


#4
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag
ADVANCED USE

As mentioned previously, RegCompact uses a simple 2-click process to compact the registry, but what fun is that? :lol: Suppose you don't mind getting your hands dirty and want to do something more interesting like having the program simply create the new registry so that you can do something with it manually later. This might be necessary to aid in experimentation to dodge the registry limits sometimes encountered in Win9x. With a little bit of effort RegCompact can be used to save various registry binaries, perhaps after loading a bunch of REG bloat, save the binaries, add more bloat, save those binaries, etc. In that other thread I described one way I used to do exactly this ...

Interestingly enough, one program that I never saw choke on a large registry was RegCompact by Daniel Werner, a 32-bit protected mode app which near as I can tell reads the currently loaded registry in memory and writes it out sequentially, removes any fragmentation 'holes'. It uses WININIT.INI to do this by outputting the DATs as C:\WINDOWS\TEMP\RCxxxx.TMP that are swapped in on next reboot. In my experience it was always successful in this 'defragmentation', and, on the following reboot I don't recall any problems either. But if you stop and think about there shouldn't be any problems because what you are loading in these new' DATs is just a likely smaller, and purified version of the previous working registry. Theoretically it should become problematic when you start pumping in REG files just before you RegCompact.

The way I managed things on Win98se after the WinME registry change forked it up ...

  • Boot Win9x normally without BSOD
  • Backup DATs ( 'A' )
  • Import the required REG data in REGEDIT
  • Backup DATs ( 'B' )
  • Run RegCompact
  • Copy the newly created DATs cited in WININIT.INI, rename to DATs ( 'C' )
  • Now I have three sets of registry DATs, A, B, C
Then I would try booting C having A to fall back on. Note that B was saved just for informational purposes, because C is a purified and smaller version of B. If this concept is understandable and makes sense, then you should be able to do this successfully. Just remember that A, B, C represent three points along the timeline. I never did have a problem here but I never did push it for experimentation's sake. In other words I never imported huge amounts just to learn the limits of that specific computer ( once again assuming the BSOD is related to registry size, complexity, available RAM, Networking, CPU model/speed/cache, etc ).


What I was essentially doing was changing the purpose of RegCompact from an automated compactor to a manual registry generator. In other words, read the current registry ( including any massive imports I might have inserted since the last reboot ), grab these two new registry binaries and then manually terminate and cleanup after RegCompact. The description might be better with pictures.

RegCompact Process in Detail. What happens is this, when you start RegCompact it immediately writes out the two registry binaries to temp files ( which take ~10 seconds to 'create' instead of 12 hours of real-mode processing ). By the time the first dialog for user input appears ( the 3rd actual screen ) that chore is already done! In fact you might not even be able to read the first two, so I saved them ( and it wasn't easy to catch the 2nd one with USER ) ...

Posted Image


FIRST PROMPT SCREEN ... Again, they go by quickly and you are then handed the first dialog allowing input. And all you can really do is select or deselect hives to change out on the next reboot, click 'Compact' to proceed, or click 'X' to cancel the whole thing. NOTE: What you are really selecting here with the checkbox is which filenames will be written into WININIT.INI to be replaced at bootup. Here it is annotated ...

Posted Image


AFTER YOU CLICK 'X' TO CANCEL ... If you choose to cancel, this is a good time to do it because it will clean up after itself completely. Note that WININIT.INI has not been written yet ...

Posted Image


AFTER YOU CLICK 'COMPACT' ... Instead, were you to choose to proceed all that happens next is that RegCompact generates the WININIT.INI in the Windows folder and sends up the next ( and final ) last chance dialog.

Posted Image


KILLING THE TASK TO AVOID RESTART ... At this point, RegCompact is awaiting one more click to force the reboot, then the system will process WININIT.INI and install the new registry. This is where you must be careful if you want to cancel now ( perhaps you wanted a copy of WININIT.INI for some reason like I did for this experiment ). IMPORTANT: to cancel at this step you must terminate the actual RegCompact task, and you CANNOT use Task Manager ( CTL-ALT-DEL ) here because even that will cause a reboot. However if you use something like ProcExp ( Process Explorer ) you can kill it just fine. But remember that doing so means that you MUST manually cleanup after RegCompact. ScreenShot of using ProcExp to kill the task ( in ProcExp you click on the REGCOMPACT.EXE task, then right-click for the popup menu and then finally click on 'Kill Process' ) ...

Posted Image


So if you did choose to kill the RegCompact task, remember from the 2nd to last screenshot that the registry temp files named RCxxxx.TMP are sitting in C:\Windows\Temp\ and the file called WININIT.INI is sitting in C:\Windows\ at this point. If you rebooted now the registry exchange would take place after all. I suspect experts can easily manage from here.

ORIGINALLY POSTED: 2012-09-14. Okay, that's all for now. If anyone can add anything to this please leave details in the comments. Also, if you spot any errors, typos or otherwise please let me know. Thanks! :hello:
EDIT: fixed an image, added better text

Edited by CharlotteTheHarlot, 15 September 2012 - 11:27 AM.

... Let him who hath understanding reckon the Number Of The Beast ...


#5
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag
TEST RESULTS ... ( September 2012 ) Using all 7 known RegCompact binaries.

Quick reminder: RegCompact processes the 'live' registry currently loaded and in-use by the system you are using. This is in contrast to 'opening' an arbitrary offline registry file from disk ( as RegDat does, recent links ). The consequence of this is that during experimentation there is no foolproof way to ensure that the 'live' registry is bitwise ( or datawise ) identical from one test to another. We can get as close to possible by scripting the various steps and by restoring a 'default' identical registry at each reboot in DOS. But there will always be several unavoidable differences between each test because of dynamic changes during the Win9x bootstrap. Fortunately there are very few of these in Win9x as it is a very tame operating system compared to everything since.

METHODOLOGY: I made a default copy of SYSTEM.DAT and USER.DAT to re-use for each test iteration. This was achieved by RESTORE.BAT in DOS which re-installed the default SYSTEM.DAT and USER.DAT to C:\WINDOWS and deleted WININIT.INI if it existed. In Windows a shortcut in C:\WINDOWS\STARTM~1\PROGRAMS\STARTUP to a batch file used to launch RegCompact after waiting for a minute ( an effort to make sure all Windows PnP drivers completed to have a common starting point for all tests. This is a nearly uncontrollable variable. ) Once RegCompact prompted with it's dialog all the registry processing was done, I exported the registry, took screenshots if necessary ( already seen in above posts ), copied the new DATs, clicked 'COMPACT', copied WININIT.INI, terminated the task, rebooted and moved to the next version. For the 2nd pass I add one step to the procedure in which a REG script was imported just after rebooting. This script was designed to add a bunch of registry keys and values, then it deleted a preceding key to force creation of a registry hole. The effect of the script also has a net gain of registry size.

RESULTS: As mentioned, the two new generated registry binaries were collected each time. RegDat was then used to convert them to ASCII REG files in order to do WinDiff comparisons between the default originals to each compacted registry. The primary purpose here was to make sure that the exact same data exists before and after running every version of RegCompact. Summary: What should be expected is that the binary DATs get reduced in size, while the ASCII exports remain exactly identical. And this is exactly what occurred ...

; Binaries -------- BEFORE -------- AFTER
SYSTEM.DAT .... 12,738,592 ... 12,730,400
USER.DAT ....... 3,686,432 .... 3,629,088

; ASCII ----------- BEFORE -------- AFTER
SYSTEM.REG .... 15,485,408 ... 15,485,408
USER.REG ....... 5,589,653 .... 5,589,653


Here are all the sizes as saved in a spreadsheet. The RegCompact file size results were all perfectly identical. Click the button ...
Spoiler


What ASCII differences are there? In a way this is also a test of experimental control methods ( how well did I control all the variables ). Well, The results were astonishingly similar. In fact there were a maximum of 14 bytes difference in a maximum of 8 keys for all comparisons, sometimes less. All of them are accounted for by the dynamic nature of certain Windows elements on each bootup and cannot be easily disabled ( save for one ). There were 4 bytes different found in 4 keys belonging to PnP Audio WDM drivers. There were 4 bytes different found in 1 key belonging to the Ethernet NIC ( which could have been turned off in the BIOS ). There were 4 bytes different found in 2 keys shared by both Windows and MSIE for BROWSEUI.DLL and SHDOCVW.DLL. There were 2 bytes different found in 1 keys belonging to the Explorer shell MRU. Anyone that is familiar with WinDiff'ing registries will recognize them as always different ( with possible variations on the audio drivers and the specific key numbers ). To see these always changing keys, click the button ...
Spoiler


What about Binary differences? The above results are ASCII comparisons, however the small amount of differences seen there DO NOT represent all the changes between any two given DATs. The export of a DAT hive to ASCII only includes what REGEDIT ( or RegDat ) returns using public functions through the API. It does not export everything, even on the relatively tame Win9x ( where there are no security ACL's to worry about ). In fact, the number of differences between two successive registry DATs can be quite numerous while there is no difference at all in the exported data in ASCII text ( exceptions described above ). To illustrate this a few more tests need to be performed. Here are examples of the massive binary differences in registries that have absolutely identical data ( as seen in the ASCII text export ).

Quick Test: 3 runs of RegCompact in rapid succession. Conceptually, this is a perfectly identical 'live' registry in memory processed by RegCompact mere seconds apart ( I copied the temp DATs and canceled and immediately relaunched RegCompact ) ...

;--- SYSTEM.DAT
2012-09-13 - 14:58 ... 12,730,400 Rca126.tmp
2012-09-13 - 14:58 ... 12,730,400 Rca245.tmp .... 93,592 differences!
2012-09-13 - 14:59 ... 12,730,400 Rca372.tmp ... 163,904 differences!
;--- USER.DAT
2012-09-13 - 14:58 .... 3,629,088 Rca127.tmp
2012-09-13 - 14:58 .... 3,629,088 Rca246.tmp .... 14,255 differences!
2012-09-13 - 14:59 .... 3,629,088 Rca373.tmp .... 12,768 differences!

NOTE: ASCII text comparisons were identical

Quick Test: 2 runs of RegCompact in rapid succession, changing 1 byte in REGEDIT in between. Conceptually, this is a nearly identical 'live' registry in memory ( 1 byte different ) processed by RegCompact mere seconds apart ( I copied the temp DATs and canceled and immediately relaunched RegCompact ) ...

;--- SYSTEM.DAT
2012-09-13 - 15:01 ... 12,730,400 Rc1015.tmp
2012-09-13 - 15:01 ... 12,730,400 Rc1176.tmp ... 164,035 differences!
;--- USER.DAT
2012-09-13 - 15:01 .... 3,629,088 Rc1016.tmp
2012-09-13 - 15:01 .... 3,629,088 Rc1177.tmp .... 12,028 differences!

NOTE: ASCII text comparisons were identical EXCEPT for the 1 changed byte


EXPLANATION? Well it is only my speculation but what I believe to be happening is that there are reserved empty 'cells' in the registry, and when the registry is written out as a file on disk, the pre-existing byte pattern in those HDD sectors remain undisturbed. I would guess that the function says "write out this data string of 69 bytes, now skip ahead 3 bytes, now write out 24 bytes, now skip ahead 3 bytes ...". So every time you write out the registry it is written to a new place on the HDD and the empty parts ( e.g., default value not set ) reserve their space with a placeholder showing the contents existing in that HDD sector at that moment in time it was written rather than zeroing them out. Here is a screenshot of some of the bytes, binary compared between two successive registry saves to disk ( mere seconds apart ). I believe the differences seen here are just the pre-existing bytes that existed at that location on the HDD. Click the button ...
Spoiler

Anyway, this may explain some of the binary differences, but there are other vast changes as well, including large blocks of relocated bytes. Others probably can speculate further on this, but me, I am just chalking it up to the fact that the registry database file format remains largely undocumented. It is an interesting detail to be sure, but completely irrelevant for most purposes of Windows use.


What about NT Versions of Windows? In fact there are versions of RegCompact specifically for NT in the form of '.NET' and 'Pro' releases, and they are not discussed here since I haven't tested any of them. There is also the well regarded NTRegOpt ( by Lars Hederer, the author of ERUNT ). However, these tested versions RegCompact v1.0 also support NT in the following manner as described in the README: "Any computer running Windows95, 98, Me, NT 4.0 or 2000 is supported.". So what happens if you execute it on WinXP? Well, I ran the program just to generate the temp files and then canceled it. The following screenshot shows the dialog processing the many hives of the registry and the already written temp hives in the %UserProfile%\Local Settings\Temp folder. Whether it would have successfully restarted and installed the files is anybody's guess. I'm not pursuing this question at this time. Click the button ...
Spoiler


PECULIARITIES

DEFINITE BUG :: I noticed this quirk many years ago. It is not a deal-breaker at all, the program works just fine, but it is the kind of thing that bothers perfectionists! I described it in another thread ...

Looking at my old Win9x notes I just noticed an odd convention used by RegCompact ( well, odd to me, maybe normal for the time ). I didn't log which particular REGCOMPACT.EXE file I tested, but an actual entry found in WININIT.INI was entered by one of them like so ...

[rename]
C:\WINDOWS\SYSTEM\..\USER.DAT=C:\WINDOWS\TEMP\RC1154.TMP
C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RC1153.TMP
C:\WINDOWS\SYSTEM\..\SYSTEM.DAT=C:\WINDOWS\TEMP\RC1153.TMP


I made a note of the fact that there is one error there ( the repeated 2nd entry ) and one odd programming convention ( the parent folder '..' dereferencing ). That repeating error I don't really care for because the [rename] operations using '=' are a MOVE ( to the best of my knowledge ). That means that the repeated command must fail since the file no longer exists by the time it is executed. The parent folder dereferencing is fine but theoretically inefficient because it says look in C: then in WINDOWS then in SYSTEM then back up one level where we just were and use the file named xxx.DAT. Anyway, I noted all of the above and rewrote it like this without the repeat and with tighter code ...

[rename]
C:\WINDOWS\USER.DAT=C:\WINDOWS\TEMP\RC1154.TMP
C:\WINDOWS\SYSTEM.DAT=C:\WINDOWS\TEMP\RC1153.TMP



Since I just tested all the versions several times, I can report that this 'bug' exists in every one ( supplementing earlier testing by Foxbat ), which probably suggests that they are all post-compile edits of the same binary. Here are the WININIT.INI entries from every version. Click the button ...
Spoiler


POSSIBLE BUG :: I just noticed this while doing all the above testing. The problem is the crashing of ProcExp upon launch when either IrfanView is already open alone or IrfanView and RegCompact are already open together ( depending upon which version of ProcExp is used ). In other words, open IrfanView and RegCompact, and now open ProcExp and it crashes. I have no time to run this one down but I can list the tested configurations that definitely crashed ProcExp. Click the button ...
Spoiler


ORIGINALLY POSTED: 2012-09-14. Okay, that's all for now. If anyone can add anything to this please leave details in the comments. Also, if you spot any errors, typos or otherwise please let me know. Thanks! :hello:
EDIT: typos

Edited by CharlotteTheHarlot, 08 January 2013 - 02:41 AM.

... Let him who hath understanding reckon the Number Of The Beast ...


#6
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag
A tiny Patch to REGEDIT makes it think it is running in DOS. I have been able to export and import from arbitrary files while in Windows.

The VFAT Error is the most probable symptom of DMA memory starvation. The Registry and NIC Drivers use this memory and them VFAT can't get enough. I built even larger Registries to test out my fix for this problem.

As I commented in a post years ago, you need to run SMARTDRV when running in DOS or you could end up waiting TWO DAYS for REGEDIT to complete.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#7
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag

A tiny Patch to REGEDIT makes it think it is running in DOS. I have been able to export and import from arbitrary files while in Windows.

The VFAT Error is the most probable symptom of DMA memory starvation. The Registry and NIC Drivers use this memory and them VFAT can't get enough. I built even larger Registries to test out my fix for this problem.

As I commented in a post years ago, you need to run SMARTDRV when running in DOS or you cound end up waiting TWO DAYS for REGEDIT to complete.

Doh! You're right! I completely forgot about SmartDrv, thanks for the memory jogging. I'll run that CREATION again soon.

"... Just when I thought I was out, they pull me back in! ..."

P.S. if you patch REGEDIT, and run it in Windows ( making it think it is in DOS ), how can it output the DAT files?

... Let him who hath understanding reckon the Number Of The Beast ...


#8
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,084 posts
  • OS:98SE
  • Country: Country Flag


A tiny Patch to REGEDIT makes it think it is running in DOS. I have been able to export and import from arbitrary files while in Windows.

The VFAT Error is the most probable symptom of DMA memory starvation. The Registry and NIC Drivers use this memory and them VFAT can't get enough. I built even larger Registries to test out my fix for this problem.

As I commented in a post years ago, you need to run SMARTDRV when running in DOS or you cound end up waiting TWO DAYS for REGEDIT to complete.

Doh! You're right! I completely forgot about SmartDrv, thanks for the memory jogging. I'll run that CREATION again soon.

"... Just when I thought I was out, they pull me back in! ..."

P.S. if you patch REGEDIT, and run it in Windows ( making it think it is in DOS ), how can it output the DAT files?

The Patched REGEDIT will create the DAT files the same way as the normal REGEDIT does in DOS. Use the /L: and /R: arguments to specify the Destinations.
I just ran some experiments that showed with a more complicated import structure a limit of 9-10MB in the size of each of the created or expanded SYSTEM.DAT and USER.DAT Files using 16-Bit REGEDIT in DOS or WINDOWS.

I did find a way of compacting a larger Registry using REGEDIT in 32-Bit Mode, but it is rather complicated.
I built a 23MB SYSTEM.DAT and a 17MB USER.DAT. I was able to boot with them as my machine has the RAM Limitation Patch /M Option installed. In the process of my experiments they grew to 27MB and 22 MB Respectively.
I was able to rebuild them leaving a 22MB SYSTEM.DAT. I didn't check the USER.DAT.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#9
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • OS:98SE
  • Country: Country Flag
Hi CharlotteTheHarlot,
I have made a preliminary test of RegCompact v1.0 #5 [MD5 5749...] on my 11-year-old laptop under Win98SE. I installed Win98SE on this laptop 9 years ago, no re-installation of Win98, and there are about 100+ apps installed under Win98. I do not use software to clean up the registry, or software to compact the registry, but I keep my system clean by creating clean restore points and then re-install new useful apps on a previous clean restore point, building in this way the next clean restore point. I never had any problem with the registry becoming bloated.

Before running RegCompact 1.0 system.dat was 8904kB and user.dat was 1192kB. After running RegCompact they were 8860kB and 976kB respectively, i.e. a decrease of about 2.6% in size. Running RegCompact was easy and did not cause any damage. What are the benefits of running RegCompact?

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.

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

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"

Edited by Multibooter, 15 September 2012 - 01:07 AM.


#10
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • OS:98SE
  • Country: Country Flag

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"

Good to know, but possibly academic. "scanreg /fix" fails when the registry exceeds something like 8M, so I expect "scanreg /opt" will fail similarly.

Joe.

PS. @ CTH : Great write-up! :yes:

#11
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,785 posts
  • OS:98SE
  • Country: Country Flag

Donator

Use the /L: and /R: arguments to specify the Destinations.

Just for the record (quoted from MDGx's Registry Guide):

C:\>REGEDIT

Imports and exports registry files to and from the registry.

REGEDIT [/L:system] [/R:user] filename1
REGEDIT [/L:system] [/R:user] /C filename2
REGEDIT [/L:system] [/R:user] /E filename3 [regpath1]
REGEDIT [/L:system] [/R:user] /D regpath2

/L:system     Specifies the location of the SYSTEM.DAT file.
/R:user       Specifies the location of the USER.DAT file.
filename1     Specifies the file(s) to import into the registry.
/C filename2  Specifies the file to create the registry from.
/E filename3  Specifies the file to export the registry to.
regpath1      Specifies the starting registry key to export from.
              (Defaults to exporting the entire registry).
/D regpath2   Specifies the registry key to delete. Win98/ME ONLY!
/S            UNDOCUMENTED [USE WITH CAUTION!]: executes all
              REGEDIT command line operations quietly, without
              ANY confirmation. Available ONLY in Windows GUI
              mode!
There's still more at MDGx's Registry Backup and Restore...

#12
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • OS:98SE
  • Country: Country Flag
I have made the following test of RegCompact v1.0 #5 [MD5 5749...]:

1) Under Win98SE, with a never compressed registry: I exported with Regedit the whole registry as a .reg file
2) I ran RegCompact and Win98 shut down
3) instead of re-booting into Win98SE I booted into WinXP
4) under WinXP I saved the 2 Rcxxxx.tmp files and Wininit.ini created by RegCompact under Win98, as well as the Win98 user.dat and system.dat files (as backups)
5) I rebooted into Win98SE

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.

Here the results:

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.

2) Regedit seems to have an issue when it exports data as a .reg file: The characters "0A" [=LF] and "0D" [=CR] seem to get converted to something else, at least as displayed by Beyond Compare. The original key value is probably not the same anymore when such an exported registry file is imported. The registry keys of some software packages (e.g. by Iomega, Emailchemy) contain program descriptions containing Linefeeds for nicer display, which seem to get converted when exporting as a .reg file.

Edited by Multibooter, 15 September 2012 - 09:34 PM.


#13
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • OS:98SE
  • Country: Country Flag

2) Regedit seems to have an issue when it exports data as a .reg file: The characters "0A" [=LF] and "0D" [=CR] seem to get converted to something else, at least as displayed by Beyond Compare.

I checked with Hex Workshop 4 the original uncompressed user.dat (created in step 4 above), the exported .reg file and the user.dat compressed/created by RegCompact, for a difference indicated by Beyond Compare.

For this specific string which was different:
- the uncompressed user.dat contained 0D 0A 0D 0A [=CR LF CR LF]
- the .reg export file converted these 4 bytes to 5C 72 5C 6E 5C 72 5C 6E [=\r\n\r\n]
- the compressed user.dat (created by RegComp) contained 0D 0A 0D 0A [=CR LF CR LF], i.e. no error was introduced during the compression by RegCompact.

In Regedit under Win98 the value data 0D 0A 0D 0A [=CR LF CR LF] is displayed as 4 thick vertical lines.

Edited by Multibooter, 15 September 2012 - 10:07 PM.


#14
Foxbat

Foxbat

    Member

  • Member
  • PipPip
  • 122 posts
  • OS:none specified
  • Country: Country Flag

Good to know, but possibly academic. "scanreg /fix" fails when the registry exceeds something like 8M, so I expect "scanreg /opt" will fail similarly.

Yes, scanreg /opt fails when the registry is around 8MB. RegCon also fails at this size. RegCompact seem to be only registry compressor that works where the other tools fail.

...
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.

Here the results:

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.
...

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.

#15
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • OS:98SE
  • Country: Country Flag

scanreg /opt fails when the registry is around 8MB.

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).

scanreg /opt seems to be better at reducing the size of system.dat, while RegCompact v1.0 seems to be much better at reducing the size of user.dat. Here some results of a combined consecutive use of scanreg /opt and RegCompact v1.0:

1) never compressed files before starting the compression experiment:
system.dat 8905KB
user.dat 1193KB
combined size: 10098KB

2) after running scanreg /opt with the files in step 1:
system.dat 8825KB (-80KB)
user.dat 1189KB (-4KB)
combined size: 10014KB (84KB less than uncompressed))

3) after running RegCompact with the files produced in step 2:
system.dat 8873KB (+48KB, i.e. an INCREASE in size)
user.dat 981KB (-208KB)
combined size: 9854KB (160KB less than after step 2)

4) after running scanreg /opt a 2nd time with the files produced in step 3:
system.dat: 8841KB (-32KB)
user.dat: 969KB (-12KB)
combined size: 9810KB (44KB less than after step 3)

So the combined use of scanreg /opt and RegCompact can reduce the size of the registry even more, similar to an improved file compression when a file is first compressed to a .zip file, then the .zip file is compressed to a .rar file. 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.

Edited by Multibooter, 16 September 2012 - 04:07 PM.


#16
Foxbat

Foxbat

    Member

  • Member
  • PipPip
  • 122 posts
  • OS:none specified
  • Country: Country Flag

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 by Foxbat, 16 September 2012 - 04:15 PM.


#17
PROBLEMCHYLD

PROBLEMCHYLD

    The Resurrector for old Windows OS

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,528 posts
  • OS:98SE
  • Country: Country Flag
Another possible solution :thumbup

Believe God is the Alpha and Omega.
Believe Jesus Christ died for our sins.
Repent for your sins now or there will be
BLOOD

The Path to God


U98SESP3 03-11-2013


#18
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag
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.

... Let him who hath understanding reckon the Number Of The Beast ...


#19
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag

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. :thumbup

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 by CharlotteTheHarlot, 19 September 2012 - 12:27 AM.

... Let him who hath understanding reckon the Number Of The Beast ...


#20
I41Mar

I41Mar

    Newbie

  • Member
  • 37 posts
@ CharlotteTheHarlot

I think this is a possible download link for the 5° file in your list (contained inside the zipped exe file):
http://xoomer.virgil...gcompact1.0.zip

I41Mar

#21
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • OS:98SE
  • Country: Country Flag

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

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

#22
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,042 posts
  • OS:none specified
  • Country: Country Flag

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.archi...gcompact1.0.zip

jaclaz

#23
PROBLEMCHYLD

PROBLEMCHYLD

    The Resurrector for old Windows OS

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,528 posts
  • OS:98SE
  • Country: Country Flag
After running the app from the link jaclaz and I41Mar posted, I got a 48% compession and a slightly quicker boot time. Thanks guys :rolleyes:

Believe God is the Alpha and Omega.
Believe Jesus Christ died for our sins.
Repent for your sins now or there will be
BLOOD

The Path to God


U98SESP3 03-11-2013


#24
CharlotteTheHarlot

CharlotteTheHarlot

    MSFN Master

  • Member
  • PipPipPipPipPipPipPipPip
  • 2,054 posts
  • OS:none specified
  • Country: Country Flag

@ CharlotteTheHarlot

I think this is a possible download link for the 5° file in your list (contained inside the zipped exe file):
http://xoomer.virgil...gcompact1.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. :thumbup



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.archi...gcompact1.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 by CharlotteTheHarlot, 21 September 2012 - 11:57 AM.

... Let him who hath understanding reckon the Number Of The Beast ...


#25
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,042 posts
  • OS:none specified
  • Country: Country Flag

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:
http://www.msfn.org/...ost__p__1012283
(click on second link posted by cdob ;) :angel )

jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN