jds, on 07 September 2012 - 04:17 AM, said:
I tried to find 'regcompact' of 2000-12-01 to no avail, the nearest I could find was the 2000-10-28 version, which is available in the "Win95\util" directory of your favourite Simtel mirror under the name "regcmp1b.zip". Haven't tried it yet. I don't suppose the newer version is sufficiently similar that patching is an option?
I am looking around for RegCompact at this time, I can see that it will take a while :-( He seems to have moved to NT editions with version 2. There is/was a .NET version and now a 'final' edition v2.6.7 here
( also only for NT ). I found his official website called Experimental Scene
but it has been scrubbed of mention of the program. Wayback
has an archive. I will check the SimTel mirrors and track down the Win9x versions. Notice in my previous post that they are all identical sized, so I will have to diff them to see if he only changed version strings.
jds, on 07 September 2012 - 04:17 AM, said:
Yep, you've hit the nail on the head, as they say. Your description of the creation problem is exactly where I'm stuck.
Your description about protected mode 'regedit' gave me an idea :
If, when you first install a system, and have the bare essentials and drivers working, save the 'system.dat' and 'user.dat' files away as a "minimal" registry. Later, when you need to rebuild, export everything with the protected mode 'regedit', then swap the 'system.dat' and 'user.dat' files with the "minimal" set. Reboot, then import all that you exported earlier using the protected mode 'regedit'. Should work, I think.
After doing a Win9x full install is a great time to make backups, I know I always did. It's easy to grab the DATs at every opportunity and fortunately Win9x does not lock the files from being copied at any point like NT versions do. So copying them and archiving them with a batch file is ridiculously simple and would be crazy not to. I also prefer a corresponding ASCII export to be saved simultaneously ( although RegDat or RegExport will let you do this later naturally ). Windiff'ing the exports is the best way to detect changes and create a manual rollback to fix something gone awry.
"export everything with the protected mode 'regedit', then swap the 'system.dat' and 'user.dat' files with the "minimal" set. Reboot, then import all that you exported earlier using the protected mode 'regedit'. Should work, I think.
" ... of course keeping in mind that within Windows you can kill the registry by adding massive quantities/complexities and won't be aware until the very next reboot.
One other thing about registry importing/exporting is the fact that almost the entire blueprint for a given Win9x system exists in the registry ( aside from a few stragglers in SYSTEM.INI and a few other exceptions ) which means that a complete import is almost never a good idea unless the hardware never changes in the slightest way ( even a mouse ). Many of the system keys require great care! From my personal research ...
... of which this very important one in particular ...
... is machine specific, vital and really the central nervous system and or DNA of a given Win9x computer. It's two important subkeys ...
... to the best of my knowledge are literally the closest comparison in Win9x to a DOS era CONFIG.SYS or Win3x era SYSTEM.INI sequential startup list. Entries in the first one are 'ENUMERATED' and the second one 'STARTED' in the order they literally appear in the exported registry ASCII text ( not the way they necessarily appear in the sorted REGEDIT GUI ). Remove an entry and it is gone, move them out of order ( especially things like Acpi\\*pnp0xxx
entries ) and it can go FUBAR. There are many things that order dependent ( a HDD controller before a disk attached to it, any 'bus' before one of its attached devices, etc )
Consequently, these keys should never be imported unless the hardware has not changed at all.
On a long running system you can export that key and glance through the sequential entries and learn the exact order everything was added to a system, right down to a mouse, or disk, USB included. For example if you added a new CD drive or USB flash drive ( or any hardware ), along with all the more generic entries elsewhere, there will be one one entry at the end of both of those keys ( sometimes only one of the keys ) which IMHO is the flag or trigger during a bootstrap to enumerate and/or start a device. Note, this information is completely from my own experimentation, I searched for authoritative sources over the years to no avail. One other note, hard drives each get an entry too, however they are so generic with many sharing the same IDE type 47 or 80 description that you cannot really determine one from the other historically in this key. Instead Win9x relies on controller and cable position ( PM PS SM SS ) to enumerate and start them.
I know this is a bit off topic, I just want to repeat that dropping entire registry exports into REGEDIT is a very bad idea, even on Win9x ( which itself is very light on registry and overhead compared to WinXP ), that is of course, if you want everything working properly. You can often drop a HDD from one Win9x installation into an entirely different computer and even though every ENUM and other system key is completely different, it seems to boot and operate okay ( if by okay you mean compatibility mode! ). Point being, these keys are very important to a perfectly working system. They must be treated carefully. I have done piecemeal transplants working around these keys many times. Often I exported those specific keys, edited them against a master list of hardware, even re-arranging the enumeration and starting, and then deleted the branch, re-imported them, rebooted and continued. Such work is not for the faint of heart!
But it somewhat corresponds to the DOS days of ultra-managed CONFIG.SYS and AUTOEXEC.BAT entries to get the perfect running system ( but of course the goal there was slightly different in that it was more about getting a driver to load before another to more efficiently fill up the memory space leaving maximum available RAM for applications ).
Sorry about the digression, and I expect you already know of these issues, it is just for the later readers of this thread that I want to say: BE CAREFUL in here.