jared Files

JARED (Just Another Registry EDitor)

This software is licensed under the GNU Public License.  See GPL.txt.

The core of this project is portable open source code to read and write Windows
registry files.  It parses the file into a tree of (hopefully) easy to work
with class instances, and provides a method for writing the whole tree.
This core code is currently used by a command line tool for modifying
registry files using a .reg file.

We call this alpha code, but Windows isn't very forgiving about errors
in registry files.  When we can read and then write a 60M file and things
seem to work correctly, I don't think we can be that far off the mark.

It is written in java, but provides a make file for compiling under gcj.
Presumably it could be linked to a C program.

I (Tom) can be reached at jared@srcbin.com

Somebody mentioned that it wasn't obvious that you could make executables
using the Makefile in the make directory.

Release notes:

7/9/10
Makefile was in the wrong place in the tree, requiring tweaking or moving
it.  It is now in jared_xxx/src/main/make/Makefile.  A little weird, perhaps,
but why mess with success?

9/27/09
Qword wasn't working.  Sorry.  Hadn't run across any.
Added support for "db" (data, big?) records.
Support arbitrary data types as BlobVks.

10/2/09
There is, according to chicken, a flag that says if a value is named
or not and I was forgetting to set it.

12/5/09
The field that gives the number of security keys was thought to be
32 bits must really be 16.  The result was that a huge array was
being unnecessarily allocated causing memory issues.

12/6/10
The ri data structure was never well tested apparently and it broke when we
got a huge file which is what it is made for.  Also it seems DWORDs don't
need to be stored inline although they usually are.

12/15/10 We had a 67M hive, and were trying to process it in 512M of
memory and gcj was using too much memory.  We added code to clean up
various data structures on the heap, since gcj's Boehm garbage
collector scans the heap looking for things that look like pointers.
Some simple data compressing methods were used for heap data to reduce
data size.  Simple methods seemed preferable because using more
sophisticated methods was much slower and didn't reduce the footprint,
perhaps because the compressed data looked like a wider range of
pointers.  We had been keeping an image of the whole file in memory
during reading and writing because the random access nature of the
data made it faster to operate on, but changed it to hold a limited
number of 0x1000 blocks and swap them to a file.  Speeds were minimally 
impacted.

1/1/11 Our last enhancement didn't handle the "class" entry right if it 
was null.