regutils Code
regutils - Win9x registry tools in Unix C & INI file tools in Perl
Brought to you by:
jsquires
Menu
▾
▴
Tree [852345] default tip / History
jsquires
jer
Read Me
Last updated: March 5, 2014 (version 0.15)
Regutils is a collection of programs to help in managing the configuration
of Windows software and systems. The utilities can be used to apply user
and machine specific customizations on the fly as users log in or as machines
are booted. They can also be used to identify and correct similarities and
differences between software configurations. These may be helpful in debug
situations or when consistency or differences need to be maintained.
This package was created out of a larger set of scripts that allowed windows
95 machines to be served disklessly, entirely from unix servers. Since this
is a subset of a larger system, and since some of the utilities apply only
to windows 95 which was end of life on January 1, 2003, there are likely some
things in the way these programs operate which seem odd or out of place
(especially the registry manipulation utilities, gen-app-changes, fix-w9x-lnk
and apply-app-changes).
This package does not attempt to keep pace with the registry changes in newer
versions of Windows, as Microsoft has delivered a number of tools and APIs
for performing that type of manipulation. The INI utilities stand alone and
apply to any software using a variety of INI formats and are still relevant
and useful in newer versions of Windows. The registry utilities will
continue to be delivered in case there is a continuing need for them, but
there is currently no test environment for debugging, so patches will need
to be tested by those who submit them to the package maintainers.
Enhancements and bug fixes may be submitted through sourceforge; the current
version is available from https://sourceforge.net/projects/regutils/.
Previous versions are available from http://www.cs.mun.ca/~michael/regutils
and from ftp://ftp.cs.mun.ca/pub/regutils/.
The package contains the following programs:
Utilities to manipulate .ini files:
inicat - cat dos/windows .ini files to standard output.
inidiff - generate the differences between two dos/windows .ini files.
iniedit - edit (or patch) a dos/windows .ini file.
inifilter - filter a dos/windows .ini file by making substitutions
and deletions to keys and entries.
Utilities to manipulate windows 9x registries and dumps there of:
regdiff - generate the differences between two windows 9x registries.
regedit - dump or edit a binary windows 9x registry file.
regfilter - filter a windows 9x registry dump by making substitutions
and deletions to keys and entries.
reghexprint - prints hex entries in registry dumps as characters.
regsort - sorts a dump of a windows 9x registry.
Utilities to generate and apply lists of changes resulting from
the installation of a software package:
[currently undocumented]
gen-app-changes - generate a catagorized, filtered and generally munged
set of differences which are (almost) suitable
for automatic application by apply-app-changes
apply-app-changes - apply a set of changes to the shared windows files
as well as to the client (machine) and user profile
files.
fix-w9x-lnk - fix the paths and flags in a .lnk file (very crude).
To understand why this package exists, one must know how software is installed
on diskless windows 9x machines (this is a pretty offal process):
One begins by setting up a diskful machine so it has user profiles
enabled(and any other set details that are important) and you take
a snapshot of the disk. You then install a software package (or many,
if you prefer), configure it, etc. so its the way you want it, then
(after a couple of reboots, to allow new dlls to be installed and old ones
to be completely removed) you compare the contents of the disk to
what it was like before the installation. These changes (including
new files, changed old files, changed .ini files, changes in the
system, default user and user registries), are then munged to correct
path names (which are typically quite different in a diskless situation)
and to do other miscellaneous tweaks, and are applied to the diskless
environment (ie, put in the common `share', the client share, and in
the user's profile).
[the reason for doing this instead of a `network install' is that it works
(most install programs die when they can't find a hard disk, others die
for other random reasons); also it allows the system and user registry
changes to be isolated so that they can be replicated to other machines
and users and so conflicts with other installed packages can be discovered
and resolved]
Obviously, sorting out what has changed from what hasn't is a fair amount
of messing around, especially when you have a pile of packages to install.
So, the natural thing to do is to automate the process as much as possible.
The gen-app-changes script does a recursive diff of the before and after
images (ie, directory trees) and sorts out the changes into three
categories:
sbs: the common share used by all diskless clients (has most of the
windows/ directory, plus lots of other stuff). This is
generally mounted read-only.
clients: the computer specific things and the stuff that needs to
be changed.
profile: things that go in the user's profile (eg, start menu items,
user registry changes, user config files, etc.).
In each of these categories, certain files are treated specially:
.ini files: changes to existing ini files are generated using inidiff
registries: changes to system.dat and user.dat are handled by regdiff
text files: handled by diff -c
binaries: handled by saving the new or modified version.
The contents of ini and registry diffs may be modified by pre-configured
`filters' (applied by inifilter and regfilter programs) to do common
substitutions such as changing paths referring to the windows directory, etc.
Once the differences have been noted, sorted and munged by gen-app-changes,
the user gets to look things over and tweak things further (esp, the registry
changes and any application specific files). The changes can be integrated
into the diskless server using the apply-app-changes script - this script
is used in two ways: first, it can be used to check for conflicts between
the existing system and the changes that are to be applied (this is pretty
painful at the moment, as it just lists the problems and doesn't sort them
out for you - it could be alot smarter); second, it can be used to actually
apply the changes (obviously). Then you're ready to test the newly
installed software to see if it actually works.