As for RegExport, alas, I've seen a few other utilities with this capability, which as I've stated above, can be done quite satisfactorily with 'regedit'. Now, if he'd written an import utility, I'd consider that a "must have".
This program is just a reduced version of RegDat, a subset really, only consisting of the text export function to REG file, without the other bells and whistles, and the registration. Still, a definite must have!
Yes, however, I have no problem exporting from the registry using 'regedit', even when it's about 13MB+2MB. The difficulty is doing the reverse, either "live" or "offline", as 'regedit' crashes and other utilities seem to neglect an import capability.s.
Most likely, 'exporting' ( the ASCII output of the registry on a successfully booted computer ) will always work okay. I probably wasn't clear but what I meant was binary output from a registry tool that saves to a Win9x DAT on disk ( or a no-extension NT hive ) that is perfectly usable at a later bootstrap. Export is done while in protected-mode so by definition the registry was successfully read and loaded. At this point REGEDIT only has to write out the database. If you were to overload the registry with REG files, you could also export it out to a file. It's that next reboot which is scary.
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.
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.
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
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
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 ).
Last registry size that I used on Win98se ...SYSTEM.DAT ..... 12,873,760
USER.DAT ........ 3,665,952
ASCII Export ... 21,261,267
I just want to repeat - that registry was highly managed. I didn't just throw stuff into REG files to experiment and explore the outer limits! What I imported was highly error checked and optimized ( some might say obsessively
) , paths shortened, ~SFN~ removed, font and other paths, etc. And I had a habit of deleting large chunks of unnecessary information ( Shared DLLs, Windows setup info, etc ). If I had left that all in plus all the MSI installer garbage with the absolutely insane amounts of entries ( for every single file found in every SDK ), I bet that registry export might be be closer to 50 MB. The point is, those sizes shown DO NOT REPRESENT any kind of upper limits. Please, don't anyone assume those numbers should be used as guidelines!
NOTE: for RegCompact, there are four different versions that I have seen ... 73,728 ... 10-15-00 ... 4:36a ... Regcompact.exe_(2000-10-15)
73,728 ... 10-18-00 .. 12:39a ... Regcompact.exe_(2000-10-18)
73,728 ... 10-28-00 ... 5:16p ... Regcompact.exe_(2000-10-28)
73,728 ... 12-01-00 ... 8:33p ... Regcompact.exe_(2000-12-01)
... using this
What about this one (Commercial) :
Can't say I ever saw it before. The only problem is it doesn't clearly mention the output of binary hives. Will have to check it out ... Someday.EDIT:
wording, spelling, mistakes
Edited by CharlotteTheHarlot, 06 September 2012 - 11:53 AM.