CharlotteTheHarlot

ADVANCED USE As mentioned previously, RegCompact uses a simple 2-click process to compact the registry, but what fun is that? 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 ... 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 ) ... 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 ... 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 ... 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. 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' ) ... 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! EDIT: fixed an image, added better text

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: 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 ... ) ... 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! ... 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 ... Never mind the fact that the "previous registry" happens to be the one that blue screened with the bogus VFAT error. UPDATE: In the comments below, Rudolph Loew reminded me to use SmartDrv in the DOS registry creation process. Talk about Doh! 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 ... 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 ... 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! EDIT: typo, added registry backup BAT file, colors EDIT: 2012-09-18 ... re-ran registry CREATION and added spreadsheet comparison

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 ... 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. 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 ... If you would like to read the documentation, here is the most recent README.TXT I found dated 2000-12-01. Press the button ... 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! EDIT: typo EDIT: added a download URL found by I41Mar. Updated the RAR collection too. More typos.

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

Yesterday was the one year anniversary of the Windows 8 Developer's Preview ( which expires on January 15, 2013. ). Windows 8 Developer Preview launched one year ago today ( NeoWin 2012-09-13 ) Which makes it hysterically funny that Microsoft is still fumbling the Metro naming fiasco. It is utterly astounding that they snoozed along for at least a year, probably closer to three, never bothering to check the legal viability of the name. After Metro: Windows Store Apps and Modern Apps ( NeoWin 2012-09-13 ) Just try to make sense out of this gibberish ( it appears to be NeoWin paraphrasing, not direct quotes ). Warning: move your beverage away from your screen and keyboard ... Got that? Didn't think so! I doubt that even IBM could have made a more tangled mess. Microsoft Windows 8 : Metro ( Call it what you want, we got nuthin! )

But don't overdo it , JFYI, last time we had some fun with quote pyramids: http://www.urbandictionary.com/define.php?term=Quote%20Pyramid the Admin of the (other) Board disabled them jaclaz Yeah, you're right. Don't want to kill page load performance either. P.S. That 911cd link is dead? Or was that the point? I did try it with the http and not hxxp.

1st one ... link 2nd one ... link 2nd one short ... link I guess that there is error checking killing that last one that uses the leading pound anchor ="#.

Actually I was just trying to find a NAME= anchor in there to use a # relative link, and it appears the forum software doesn't generate one in the webpage, just ID's ... And since they used ID's in here there appears to be no way to avoid reloading the entire page when only jumping to a specific post. I was trying to use jumping to a #name leaving off the site url. If they had used NAME= in the served webpage ( even in addition to the ID= ) the URL might be something like this ( substituting angle brackets for square for the examples naturally ) ... <A HREF="hxxp://www.msfn.org/board/topic/104871-puzzling-registry-size-issue.html#1010728"> Which could be successfully shortened to this ... <A HREF="#1010728"> Clicking on that link would jump directly to that local anchor defined by <A NAME=> , with no full page reload ( and no extra slot in the browser history either ) But it looks like the actual format is this ... <A HREF="hxxp://www.msfn.org/board/topic/104871-puzzling-registry-size-issue/page__view__findpost__p__1010728"> Using a server side query rather than a static URL, I guess. No big deal anyway, just a test. Thanks for the tips though!

P.S. and totally OT: Cool that here we just managed to nest a quote within a quote within a quote... You know I had no choice but to quote that to see how far the rabbit hole goes. ---------------------------------------------------------- EDIT: chopped the blank lines. I like symmetry.

testing

Please Ignore. Just seeing what BB codes are still working. Test. Full Link to #2 here Test Short Link to #2 here (not working)

Information is the UI in Windows 8, says design guru. How to make sense of the desktop formerly-known-as-Metro ( UK Register 2012-09-12 ) So Microsoft had so much free time on their hands they felt it necessary not just to changes the appearance of their software, but want to alter the visual presentation of everyone's software. Once again we see the thought process: "don't have to need to learn a new UI for each app", as if we were screaming for them to save us from those mean and terrible 3rd party developers confusing us with their custom and signature interfaces. And people call Apple arrogant. How about this, stop fixing stuff that ain't broken, and start fixing the countless bugs in Windows. Good comments over there. Funny too ... I like it when developers are creative. That's our right. Stay out of our business. I'll bet Microsoft must just hate these guys ... EDIT: updated image URLs, and again

Another Headline from an Alternate Universe ... Intel: 80 percent of PC users prefer touch screens ( NeoWin 2012-09-11 ) One might assume that the person was either talking only about phones and tablets or that he was smoking dope. The only clue given ... A mind is a terrible thing to waste.

Thanks for the info! And yes, I believe you are right about that Italian localized being patched, not recompiled. I'm working up info for a new thread so we don't totally 'jack this one. If everyone wants to hold off a bit ( a day or two ) there will be a better place for this all info. I have tested these 6 on Win9x thoroughly ( as did Foxbat above ) and will aggregate the info there. As far as which to use, I can detect no functional difference using the GUI. P.S. Can you put version #7 somewhere and PM me a link? - Thanks.

... And that is so incredibly ironic since the real Microsoft Windows support force exists out here in the wild, are largely unpaid and a million times more thorough and precise than the 'real' paid support staff stationed 8,000 miles away. Every person who nudges against their rules about distributing patches, hotfixes and updates is likely saving them money, at least from a server/download point of view. If tomorrow every person not connected with Microsoft suddenly closed up shop, stopped answering the phone, replying to forums, fixing relatives and friends computers, and all the problems were instantly re-directed to Redmond, they would shut down cold after realizing their software products are an impossible to maintain business model without the massive non-Microsoft employed tech industry. They would be done. They couldn't possibly hire enough people to handle the hundreds of millions of Windows users working with their OS on a daily basis. They might think that their product is almost perfect and that they can handle the tiny remaining amount through official support channels but that is only their delusion. It is likely that 90% of the users never *have* to make support tickets in the first place because of the 'advanced' or experienced 10% who are debugging their problems daily. Seriously, if they were smart and cash conscious they would encourage 3rd party hosting and distribution and simply provide lists of hashes or some other more advanced method so that a recipient could verify the integrity of a given Microsoft file.

johnhc, What is the source of this file? Is it of recent vintage? If it is, it will likely be using the cabinet format since about WinXP, and the original filename will be encoded. Do you have WinRar installed? If you do, all you have to do is open WinRar and then drag and drop the xyz.in_ into the GUI. The GUI then changes to the 'contents' of this xyz.in_ file, and if it is a recent MsCab you will see the real filename and other details. From here you can extract it also. NB: this file is not an archive, it just looks that way. Don't try to add files to it! Examples from WinXP(sp3) found in the \i386 folder dropped into a WinRar window ... -- Information on Disk --- Information shown when dropped into WinRar GUI FILENAME ........ SIZE --- FILENAME ........ SIZE .... PACKED .... DATE Adcjavas.in_ ..... 387 --- adcjavas.inc ..... 629 ...... ? .... 2008-04-13 Adm_Mult.in_ ..... 879 --- adm_mult.inf ... 2,620 ...... ? .... 2001-08-17 System.in_ ....... 319 --- system.ini ....... 219 ...... ? .... 2001-07-21 Perhaps you have 7-zip instead. It can do much the same. However there are quirky differences in it's GUI compared to WinRar. Forget about drag/drop into 7-zip ( unless there is some setting I missed ). You can however just open the GUI and go to the folder with the files and right-click one and select 'Open Inside'. Now you will see the same information with one difference, it will show the packing method. -- Information on Disk --- Information shown by 'Open Inside' the 7-zip GUI FILENAME ........ SIZE --- FILENAME ........ SIZE ... METHOD ..... DATE Adcjavas.in_ ..... 387 --- adcjavas.inc ..... 629 ... LZX:21 .. 2008-04-13 Adm_Mult.in_ ..... 879 --- adm_mult.inf ... 2,620 ... LZX:21 .. 2001-08-17 System.in_ ....... 319 --- system.ini ....... 219 ... LZX:21 .. 2001-07-21 NB: In 7-zip don't double-click the file or right-click it and select 'Open' even though they are functionally equivalent at this step. IMHO you should never execute a file 'inside' an archive because generally that means to extract it to temp and then run it according to system file associations. This is a dangerous practice. 7-zip GUI seems to have 'Open' ( execute outside ) rather than 'Open Inside' ( view inside ) as the default for double-click in most circumstances so I play it safe and then right-click and select the 'Open Inside' choice. EDIT: clarity, typos

Add Toshiba to the good list. They excel in the high end with i7 desktop replacements. In the mid to low range I imagine they wouldn't want to blow their reputation making crap.

So that WinME version of SMARTVSD.VXD is okay after all on Win98se? Good to know. I wasn't sure at all. I have noticed that many of these HDD utilities come with a copy of some version of SMARTVSD.VXD within the installer, and whatever it is I stick into the private folder that the program lives. Presumably these programs are smart enough ( pardon the pun ) to import from a localized file.

If this is to be a keeper for more than a couple of years and not a throwaway wasted on facebook and angry birds or to be lost at school, well, then I'd pass on that one. Two reasons ... - Unless you want an AMD for a specific reason ( uh oh, flamewar incoming ) I would go with Intel, nothing less than an i3 ( and the step from there to i5 is chump change even for 3rd generation ). i3 or i5. - Acer is probably the least loved of the majors, personally I would go with Dell, Asus, Gateway first. Not that they are terrible, but they get very little respect from the many laptop users I am familiar with. YMMV. Probably the only thing that makes that a reasonable price is the 17" screen. In the 15" range there are lots of similarly priced laptops but again, using much better processors. Most of the other specs there are irrelevant ( HDD size, DDR3 is dirt cheap, etc ) and shouldn't be used to decide anything. Not to mention the fact that some of those things *can* be added or swapped later. However, the CPU cannot, she must live with the one that arrives with the computer. Forever. The horsepower from a good CPU will be apparent for years to come, every single time you turn it on. Just my humble opinion.

This is very interesting actually. I can't really say I seen this, ever. Congrats for figuring it out. BTW, using NU can be risky, at least on the FAT disk. When Win95 came out it there were red-flag warnings to never again use the 16-bit apps, and only run the 'new and improved' bloated 32-bit programs. I'm sure a few of them were okay, but everything disk related was considered dangerous. I actually did notice the missing date/time on the files in the screenshot and the very next thing I was going to suggest was to get yourself a real file manager and let that EXPLORER dog die. Anything will suffice really, as long as it shows all the details including file attributes ( actually EXPLORER has that option as well, you should enable that in choose details ). I use PowerDesk out of long-running habit, but there are many others. It's not like you lose EXPLORER or anything by using a 3rd party dedicated file manager, but you gain two things. Most of them store their settings privately rather than bloating the registry full of barely editable or understandable settings. Also, EXPLORER is itself an instance of the Windows shell so if you manage to crash it, you likely take down the shell in the process. And the reverse might be true - if the shell is slow or buggy from some weird problem it might impact your ability to browse files in the Explorer window(s). It's just too tangled in my opinion. 3rd party apps are almost always much more insulated from these things. Oh, what is it anyway, "Windows Classic" or Themes service disabled?

ummm, I don't think you mentioned whether your box is Win98SE or ME. That 4.90 is definitely a WinME level file. If what you try fails ( and it should if you have Win98se ), try using the 4.10 instead in both places. In that other post I should have been clearer, multiple files of different versions can be a problem. I'm pretty sure it is okay if the SAME file is in BOTH locations ( i.e., if 3rd party utilities do not have a local copy of the file in their private folder and simply import functions from the Windows path, they will receive whatever is in \System which now matches what is in \System\IoSubSys ).

Different versions have different syntax. The one you most likely have is in WinXP normally in the \i386 folder and has this /? help ... As well as using the command line, there are a few other ways to accomplish this. For example, if you happen to have WinRar, you can just drop them into an open WinRar window to see what's 'inside' and 'extract' ( expand ) it if you wish. You can create a context menu EXPAND item as X described. My current favorite alternative is assigning all those compressed cabinet extensions to something like WinRar. Unfortunately there is no wildcard allowed ( e.g., .??_ or .*_ ) so each individual extension would need to be associated with the main class. At last count I had 114 extensions. My current list of compressed cabinet archive extensions ... Anyway, I created a new main class called: [HKEY_LOCAL_MACHINE\Software\Classes\_MsCab] with all the subkeys needed to execute WinRar when one of those extensions are opened. So if you doubleclick one, like I mentioned above it opens in a WinRar window like a ZIP or RAR might ( obviously an illusion since they are not archives ). But it is good because I get to see the original file name/date/time/size in the WinRar window and then decide whether to 'extract' ( actually 'expand' ) the file or not. Never did get the dragdrop handler working though. That is the gold ring I think, being able to dragdrop and expand multiple files. Another benefit is that since they are associated, in a file manager window they get assigned a proper icon and description. Obligatory Rant: Microsoft COMPRESS/EXPAND has been a royal PITA since, well, almost forever. Many different incompatible versions, differing syntax and only a few with identifiable signatures to determine which one can be used to decompress a given file. So it was almost always trial and error to get them expanded ( not with WinXP as in your case, but in previous years ). The dumbest idea ever was an /i386 folder with almost 6,000 compressed *.*_ files in a single directory. Yes, some minor amount of disk space is saved in total for larger files but it is eaten away by the numerous files with slack that were originally below or compressed below the minimum file size using 4KB clusters ( yeah I know NTFS has an MFT exception for really small files but that is only ~700 of the 6,000 ) . For some reason they simply refused to incorporate a monolithic archive strategy, that is until much later when they came to their senses and used the WIM idea which they could have done all along with ARC or ZIP or RAR or others. EDIT: arrghh! I thought this was in the WinXP forum. Strike those "WinXP" references.

If you are sure there are no IRQ or other BIOS conflicts *and* no cabling or jumper errors, then follow up on what loblo has said. Is it esdi506.pdr and what version? Patched for large drives? There are several versions of Smartvsd.vxd floating about as well, it sometimes comes with different HDD utilities. What version? Also, search for all occurrences of both of those files within the \Windows directory tree. I seem to remember conflicts when they appear in multiple folders.

( btw good screenshot ), submix is right, need more info ... So this is WinXP? Using "Windows Classic" Theme or Themes service disabled? Two separate Explorer Windows open ( not two panes ). Left Window C:\Program Files is NTFS? Right Window E:\HTML is Fat32? You want them both like the right window? Try right-clicking an empty space in the left window, hold the pointer over Arrange Icons By > and see if Show In Groups is checked. Then see if the same setting exists in the right window.

Another one is PC-Wizard by Franck Delattre ( who authored CPU-Z among other things ). I don't know if it still runs on Win9x but I know for a fact that it used to, and many old versions can be found if necessary. Looks like you mentioned at least two hard lockups. These are almost always a hardware conflict. I highly doubt those programs are to blame but it is possible. I would look first at all the fundamentals. IDE drive cable position, matching jumpers, cables not defective, pushed in all the way, heat ( are the HDD's cool? ). You also mention SCSI ( didn't see that above ). If it is an add-in controller look for an IRQ conflict. You may have to mess with the BIOS of the card and system. I think it is possible for software ( e.g., real-time temp monitors ) to lock-up the system if the BIOS is uncooperative, in this case you either need to get a different ( more advanced ) motherboard or simply not use any software that works at that kind of low-level.