METHODOLOGY, SYSTEM AND COMPUTER READABLE MEDIUM FOR MANIPULATING A

WINDOWS' REGISTRY

BACKGROUND

The Windows operating system stores important configuration information within a set of files called the registry. The format of the registry files is not published by Microsoft, and is not believed to be publicly known to those skilled in registry programming. Microsoft, however, does provide access to the registry via a set of APIs (functions) from which a programmer can store and retrieve data contained within the registry. For example, using the publicly defined RegOpenKey function, a programmer could gain access to a specific registry and then modify the contents of the key through the RegSetValue function.

The Registry is an integral part of the Windows' operating systems, including those in the XP family. Stored within the registry is necessary configuration information that allows the Windows XP operating system to boot up and run. The Registry is logically constructed as a tree with "keys" as the branches and "values" as the leaves. Keys consist of a name and may consist of zero or more child keys. For example, one could have a key called TOP and TOP could have three child keys, ONE, TWO and THREE. A typical representation of the relationship between the key TOP and it's children is:

TOP

ONE

TWO THREE

It is also common to represent a key name as a single character string with the character \ separating the key names. For example, the key ONE could also be represented as TOP\ONE. If the key ONE has a child, KID, the key name of KID could be represented as TOP\ONE\KID. A key name represented in such ^' form is called a

FULL_KEY_NAME. A key name without any parent/child representation is called a SHORT_KEY_NAME (e.g., ONE).

Each key may contain zero or more data elements, called "values". Values consist of a name, a value type and the actual data. The value type is an indicator of how the actual data should be stored and how is should be interpreted by programs that access the registry.

The Registry is integral to the Windows XP boot process. Without the Registry. Window XP does not boot nor become active - rendering the computer useless to the user. This is because important startup information is stored within the Registry in specific predefined keys. As the computer boots, the Windows XP operating system reads these predefined keys and either run programs or manipulates the computer environment based information contained in the predefined key(s) and its values.

The Boot Process

In order to have a functioning computer, the computer must be able to "boot". The "boot" process is a complex interaction between software and hardware that, in the end, hopefully gives control to the user so that he/she may do useful work.

For a typical computer running the Windows operating system (OS), the boot process may be regarded as having several distinct phases - hardware Power On Self Test (POST), boot device, OS load and finalization. The hardware POST phase starts when a computer is powered on. Electrical signals start the actual processor which is engineered to look at a specific area in memory for its first instruction. The first instructions run by the computer do basic validity checks and hardware configurations.

At the end of the hardware POST phase, the computer looks for a "boot device". A boot device could be one of many different devices - a floppy disk, hard disk, CD- ROM, memory stick or other exotic devices. In terms of the Windows OS, the most common boot device is the hard disk. During the boot device phase, information is read from the actual boot device by the computer. If the boot device is a hard disk, the

computer looks for a table called th ^' e partition table, which is a small data structure that tells the computer which operating system is active and where it is located on the disk. The end of the boot device phase sees the computer loading the OS from information, found in the partition table. Once the operating specific information is placed into memory, the computer hands control over from the boot device phase code to the OS code and then next phase, OS boot, begins.

It is during the OS boot phase that the Windows OS requires the use of the registry file. The OS queries the registry file for information pertaining to what drivers are to be loaded and how the system is to be configured. Integral to the OS boot phase within Windows is the establishment of a file system, such as an NTFS file system, a FAT file system or a FAT 32 file system. More prominent is the NTFS file system. In general, a file system manages the logical placement of data onto a storage medium - such as a hard disk - so that the data can be retrieved and modified. File systems are typically designed so that programs requiring the use of the file system access data files through a set of pre-defined utility functions. These functions allow 3 ^rd party applications to read/write files without having to know about the underlying structure of the file system. In the case of the Window OS, there are several access functions to the NTFS file system which allow an application to read or modify a file. However, none of the Windows access functions give any hint as to the actual physical layout of the NTFS file system on the disk.

A computer technician encountering a non-bootable computer will typically first ascertain which boot phase contains the problem. For example, if there is a problem with the actual hardware so that the hardware POST phase fails, then the technician knows the hardware must need servicing. The difficulty arises if there is a problem during the OS boot phase. Typically, the technician is in a catch -22 because he needs Windows to work in order to view files that control the boot process. The typical scenario for the technician is to try to retrieve data from the hard disk (by installing the

hard disk into a second computer as its "second" drive), and then reformatting the hard ' disk and reinstalling Windows.

To retrieve data from a non-bootable hard drive, a technician either installs the hard drive into another computer or boots from a floppy drive and runs a piece of software that understands the NTFS layout. However, this technique only allows a technician to save data found on the non-bootable NTFS hard disk to another location. It does not give him access to boot information found within the registry. Without this additional information, the technician is blind as to possible actions might be taken in order to make the hard disk boot again.

In order to have access to the additional registry information, the technician must have the ability to actually read/write the registry file. However, the ability to read/write of the registry file is linked to the ability of a process (software) to understand the layout of the NTFS file system. That is, coupled with the ability to read/write the registry file is the requirement to actually access the registry file — and to actually access the registry file of the Windows OS, one must understand the layout of the NTFS file system.

There are two known methods available for a technician to access information found on an NTFS volume. The first method is through a self-contained utility program that access the NTFS structures. These programs usually allow a technician to fix the ' partition or save data to another device. Representative such programs include: (1 ) "Boot Disk Professional" distributed by Active Data Recovery Software and available at http://www.ntfs.com/products.htm; and (2) "Omnixray 5.0" distributed by Omnixray and available at http://www.omnixray.com/disk_utilities.html. A second known method involves the establishment of a file system that understands the NTFS volume. There is an open source project currently located at the web address www.sourceforge.net/projects/linux-ntfs/ and a DOS redirector currently located at the

web address www.sysinternals.com/Utilities/NtfsDos.html. These NTFS File systems are designed so tha.t programs, not humans, are capable of accessing the NTFS file system.

Having provided an overview of the Windows registry and the boot process, it can perhaps now be more appreciated why these two components are so integral and intertwined. Unfortunately, because the Windows XP Registry is so integral to the boot process, a computer configured with the Windows XP operating system can become "non-bootable" without a set of properly configured registry key ^' s. However, all known tools which are available to the public for allowing the manipulation and repair of the registry require the Windows XP operating system to be running and active. So, we have a classic "chicken /egg" scenario. Without the Registry, Windows XP will not boot. But, one needs Windows XP to run in order to fix the Registry. As noted above, current solutions to this problem entail reformatting the hard drive and reloading the operating system. One or more of these, as well as other, unresolved needs are addressed by the present invention.

DESCRIPTION OF THE DRAWINGS

Fig. 1 is a diagram of a representative computing environment for implementing one or more aspects of the teachings herein;

Fig. 2a is a high level diagram, in accordance with one aspect of the invention, for addressing a non-boot problem;

Fig. 2b illustrates an exemplary method 220 for accessing the Windows registry through DOS on a non-FAT or non-FAT32 file system;

Figs. 3a-3j collectively represent a method for creating a registry key;

Figs. 4a-4e collectively represent a method for creating a registry value;

Figs. 5a and 5b collectively represent a method for deleting a registry key;

Figs. 6a and 6b collectively represent a method for deleting a registry value;

Figs. 7a-7g collectively represent a method for renaming a registry key; and

Fig. 8 represents a method for renaming a registry value.

DETAILED DESCRIPTION

Described herein is a technique, preferably implemented as a computer program, that that will read and manipulate the Windows Registry, and preferably one associated with the Windows XP family of operating systems, without the aide of the Windows operating system. That is, it is a computer program which is NOT necessarily designed to run under Windows, but under another operating system - DOS, Unix, Linux, etc. By booting a workable non-Windows XP operating system a user could use the invention to manipulate the Windows XP registry thus enabling the Windows XP operating system to boot properly.

While the specific embodiments described herein discuss accessing and manipulating the registry outside of Windows OS, namely via DOS, the ordinarily skilled artisan would nonetheless understand that the teachings contemplate the ability to access the Windows registry independent of the operating system environment and outside of the various functions, for example, described by Microsoft. That is, for example, the teaching herein could be applied to manipulate the Windows registry via programs regardless of whether the program is hosted by Windows, DOS, Linux, or other operating system. Further, if hosted by Windows, this could be accomplished without the need for publicly available API's published by Microsoft.

The following embodiments and aspects thereof are described and illustrated in conjunction with systems, devices, apparatus and methods which are meant to be exemplary and illustrative, not limiting in scope. In various embodiments, one or more of the above-described problems have been reduced or eliminated, while other embodiments are directed to other improvements.

In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration certain exemplary embodiments. The leading digit(s) of the reference numbers in the figures

usually correlate to the figure number; one notable exception is that identical or.similar components which appear in multiple figures are identified by the same reference numbers. The embodiments illustrated by the figures are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and changes may be made without departing from the spirit and scope of the present invention.

Various terms are used throughout the description and the claims which should have conventional meanings to those with a pertinent understanding of computer programming in general. Other terms will perhaps be more familiar to those more particular conversant in the Registry construct of a Windows operating system( OS), and particularly a Windows XP Registry . Additionally, various descriptive terms are used in describing the exemplary embodiments in order to facilitate an explanation of them, and to aid one's understanding. However, while the description to follow may entail terminology which is perhaps tailored to certain computing or programming environments or to the various embodiments themselves, the ordinarily skilled artisan will appreciate that such terminology is employed in a descriptive sense and not a limiting sense. Where a confined meaning of a term is intended, it will be explicitly set forth or otherwise apparent from the disclosure. I. Introduction

A. The Windows XP Registry

A more detailed discussion of the Windows XP Registry, as it has been deciphered by the inventor through extensive de-bugging, will now be provided. The Windows XP Registry information is stored within different data files. Each data file is comprised of the same "registry data structures" (described below). The "Registry" then is a single view, or tree, consisting of many different files. Depending on the file name, the keys contained within the file occupy specific predefined locations within the Registry single view tree. For example, the Windows XP registry contains a key called

HKEY_LOCAL_MACHINE\Software. The registry data found for the key "Software" is located in a file called "Software".

Data Structure of a Windows XP Registry Data File

A Windows XP Registry data file contains keys and values. Keys and values are actually composed of a combination of disk structures. These disk structures are supported by another set of structures which define the registry file itself.

Each Windows XP registry data file consists of two structures - REGF and HBIN. The REGF structure helps define the entire contents of the registry file. An HBIN structure defines a "block" of the file.

A registry data file consists of one REGF structure, located at the beginning of the file, and one to many HBIN blocks. The REGF structure points to the first HBIN structure and each HBIN structure points to the next HBIN structure. Thus a REGF. .HBIN...HBIN... chain is formed.

Within the HBIN block are structures that define registry keys and their associated values. Keys and values are placed into an HBIN block until the HBIN block Is full, at which point the REG...HBIN...HBIM chain is modified to add an additional HBIN block.

The REGF STRUCTURE

The REGF structure defines the registry file as a whole. It is located within the first 4096 bytes in the registry file. The REGF structure has the following fields

The Signature field contains a 4 byte value. This value is always the same and indicates a valid Windows XP Registry file. The LastHBINBIock field contains the file offset of the last HBIN structure on the disk. Navigation of the registry, described below, starts with this field value.

The HBIN Structure

The HBIN structure describes a block of data - usually 4096 bytes in size - that may contain one or more key and value structures. The combination of a single REGF structure followed by n HBIN structures constitutes a registry file. However, this combination does not constitute a valid registry tree. These two structures together constitute an organizational framework to host registry keys and their values. So, from the perspective of the REGF and HBIN structures, a registry file has the following organization:

HBIN-n

The HBIN structure has the following fields:

The signature field contains a predefined value of 0x6e696268 hexadecimal. The ParentBlock field contains the file offset of the preceding HBIN record. If there is no preceding record this value is 0. The SizeOfBlock field contains the size, in bytes, of the HBIN block, typically 4096 bytes. The A field is reserved.

An HBIN block contains the Registry key and value structures, along with other supporting structures. The structures that can exist within an HBIN block are as follows: a key name record referred to as a "KNLRECORD"; a key value record referred to as a "KV _RECORD"; an FLRECORD; an index root record referred to as an "IR.RECORD"; an index leaf record referred to as an "IL_RECORD"; a key security record referred to as a "KS_RECORD";a VALUE.ARRAY and a VALUE_DATA.

While there are many structures that can populate an HBIN block, they all have one element in common - namely a record size field. This field contains a 32-bit value that contains the number of bytes allocated to the structure to the nearest 8-byte boundary. That is, on-disk allocation for KN_RECORDs, KV_RECORDs, etc, must be evenly divisible by 8 - i.e., these are legal "record sizes" :, 8, 1 6, 24, 32, 40, etc. Also, the "record size" value is stored on disk as a negative value. This negative value must be converted to its corresponding positive value prior to determining the actual number of bytes allocated on-disk.

The physical relationship between a parent key and a child key is organized as a parent KN_RECORD and either an intermediary FL_RECORD or an intermediary IR_RECORD(s) with an accompanying ILRECORD(s) followed by the child KN.RECORD.

The FL-RECORD, IR.RECORD and ILRECORD are used to store keys in a sorted order. That is, the key name AAA is referenced prior to the key name BBB.

To store keys in a sorted order a HASH value is used. The calculation and interpretation of the HASH value depends on the record type. If an LF.RECORD is used, the HASH value is the 1 ^st 4 letters of the key name. If IR_RECORDs and ILRECORDs are used, then the HASH value is the key name itself.

(l ) The KN.RECORD

A KN_RECORD defines a registry key. The KN_RECORD structure has the following fields:

The RecordSize field is a signed 32-bit value indicating the number of bytes allocated for the KN_RECORD within the registry file. The record size is described above.

The Signature field contains the value 0x6b6e.

The OffsetToParentKey field contains the file offset of the parent KN.RECORD or the value zero (0) if the key has no parent (i.e., the key represents the root of the tree).

The NumberOfSubKeys field contains the number of children keys or the value zero (0) if the key has no child keys.

The OffsetToSubKeyRecords field contains the file offset of the child FLRECORDs. IR_RECORDs and IL_RECORDS.

The NumberOfValues field contains the number of data values associated with the key described by the KN_RECORD data structure. This value can be zero (0) if the key has no data values.

The OffsetToValueList field contains the file offset to the VALUE_ARRAY structure ( described below) if the NumberOfValues field contains a value one (1) or greater; else the field contains the value zero (0) or minus one (-1 , OxFFFFFFFF) .

The OffsetToSKRecord field contains the fie offset to the SK_RECORD structure or the value of zero (0) or minus one (-1 , OxFFFFFFFF) if the SK.RECORD is not present.

The OffsetToClassName field contains the file offset of the key class name or the value of zero (0) or minus one (-1 , OxFFFFFFFF) if the class name is not present.

The KeyNameLength field contains the number of 8-bit characters comprising the key name.

The ClassNameLength field contains the number of 8-bit characters comprising the class name or zero (0) if the class name is not present.

(2) The NV.RECORD

The KV.RECORD structure defines a key value. The KV.RECORD structure has the following fields:

The RecordSize field contains the number of bytes allocated to the NV_RECORD within the registry file (see description above).

The NameLength field contains the number of 8-bit characters in the value name.

The LengthOfData field contains the number of bytes allocated to the value data contained in the DATA record or zero (0) if the data value is not present. If the high bit (the 32 ^nd bit) is set (e.g., 0x80000000), then the actual data is stored within the

KV_RECORD itself in the OffsetOfData field and the lower 3 bits contain the size of the data (legal values 0...4).

The OffsetOfData fields contains the file offset of the DATA structure or zero or minus one (-1 , OxFFFFFFFF) if data is not present. If the high LengthOfData field contains 1 (e.g., 0x8000000) then the OffsetOfData field contains the actual data (up to 4 bytes of data).

The ValueType field contains a number indicating how the data contained in the DATA field is to be interpreted. The ValueType field can have the following values:

The Value Name field contains the name of the key value. (3) The FL.RECORD

The FL-RECORD contains HASH information about the child key name along with a file offset to the child KISLRECORD record. The FL.RECORD has the following fields.

The RecordSize field is described above. The Signature field always contains the value 0x666c and identifies the FL_RECORD.

The Count field contains the number of following FL_HASH records. Each FL_HASH record corresponds to a single child KN.RECORD.

The Hash field contains 'Count' number of FLHASH records. The fields contained in a FLHASH record are as follows:

It is important to note that the hash values within the FLHASH records must be unique. That is, no two 'HashValue' fields may be the same. If so, then the FLRECORD is converted into a ILRECORD or IR.RECORD, ILRECORD pair.

(4) The IR_RECORD

The IR.RECORD record contains file offsets to ILRECORD records. The fields contained in the IR-RECORD are as follows:

The RecordSize field is described above. The signature field contains the value 0x6972 and identifies the IR.RECORD.

The Count field contains the number of following 32-bit file offset values, each offset file pointing to a corresponding ILRECORD record.

The Offset field contains 'Count' number of 32-bit file offset values. Each 32-bit file offset references a ILRECORD. The 32-bit file offsets are in sorted order. The sort ' key is the key name derived from the last ILRECORD referenced by 'Offset'.

(5) The ILRECORD

The IL.RECORD contains file offsets to KN_RECORD records in sorted order. The fields contained in an ILRECORD are as follows:

The RecordSize field is described above. The signature field contains the value 0x696c and identifies the IL_RECORD.

The Count field contains the number of following 32-bit file offset values, each offset file pointing to a corresponding IL_RECORD record.

The Offset field contains 'Count' number of 32-bit file offset values. Each 32-bit file offset references a KN-RECORD. The 32-bit file offsets are in sorted order. The sort key is the key name derived from the associated KN_RECORD record.

(6) The VALUE_ARRAY Record

The VALUE_ARRAY record contains file offsets to key values in sorted order. Each file offset refers to a corresponding KV_RECORD record. The fields contained in the VALUE.ARRAY record are as follows:

The RecordSize field is described above. The VALUE_ARRAY structure does not have a signature field.

The 'Offset' field contains 32-bit file offset values, each corresponding to a KV_RECORD record. The 32-bit values contained in the 'Offset' array are in sorted order based on the value name derived from the corresponding KV_RECORD record.

(7) The VALUELDATA Record

The VALUE_DATA record contains the actual data corresponding to the KV_RECORD record. The fields contained in the VALUELDATA record are as follows:

The RecordSize field is described above. The VALUE_DATA structure does not have a signature field. ^"

The Data field contains the actual data bytes corresponding to the value. The interpretation of the data bytes depends on the value of the 'ValueType' field in the KV.RECORD record.

B. Representative Computing Architecture and Environment for Implementing the Described Teachings

In its various forms, the invention can be implemented within a "standalone" computing architecture to allow a user to address and, in fact, circumvent boot-up problems. A representative standalone computing environment for use in implementing aspects of the invention may be appreciate with initial reference to Fig. 1 Representative computing environment 1 0 may utilize a general purpose computer system 1 2 for executing applications in accordance with the described teachings. The artisan should appreciate from the description to follow that general purpose computer system 1 2 may comprise either the "standalone" computing architecture, or a computing systems that is part of a larger network architecture.

With this in mind, computer system 1 2 may be adapted to execute in any of the well-known operating system environments, such as Windows, UNIX, MAG-OS, OS2, PC- _r DOS, DOS, etc. System 1 2 includes a processing unit 14 (e.g., a CPU) for executing instructions, a system memory 1 6 for storing programs and data currently in use by the system, and an input output (I/O) system, generally 1 8. These various components are

interconnected by a system bus 1 10 which may be any of a variety of bus architectures. System memory 1 6 may include both non-volatile read only memory (ROM) 1 1 2 and " volatile memory such as static or dynamic random access memory (RAM) 1 14. Programmable read only memories (PROMs), erasable programmable read only memories (EPROMs) or electrically erasable programmable read only memories (EEPROMs) may be provided. ROM portion 1 1 2 stores a basic input/output system (the system BIOS). RAM portion 1 14 stores an operating system (OS) 1 18, one or more application programs 120, as well as program data 1 22.

Various types of storage devices can be provided as more permanent data storage areas for the application programs and other data. These can be either read from or written to such as contemplated by secondary (long term) storage 124. Suitable devices may, for example, include a non-removable, non-volatile storage device in the form of a large-capacity hard disk drive 1 26 which is connected to the system bus 1 10 by a hard disk drive interface 128 such as ATA (IDE, EIDE), SCSI, FireWire/IEEE 1394, USB ₁ or Fibre Channel. Hard disk drive 1 26 generally includes at least one bootable disk which stores the OS that is loaded into RAM 1 14 during a booting sequence, although the OS can alternatively be stored on removable media.

An optical disk drive 1 30 for use with a removable optical disk 1 32 such as a CD-ROM, DVD-ROM or other optical media, may also be provided and interfaced to system bus 1 10 by an associated optical disk drive interface 1 34. Computer system 1 2 may also have one or more magnetic disk drives 1 36 for receiving removable storage, such as a floppy disk or other magnetic media 138, which itself is connected to system bus 1 10 via magnetic disk drive interface 140. Remote storage over a network is also contemplated.

One or more of the memory or storage regions mentioned above may comprise suitable media for storing programming code, data structures, computer-readable instructions or other data types for the computer system 1 2. Such information is then

utilized by processor 14 so that the computer system 1 2 can be configured to embody the capabilities described herein.

System 1 2 may be adapted to communicate with a data distribution network 141 (e.g., LAN, WAN, the Internet, etc.) via communication link(s) 142 so that, for instance, it can communicate with remote servers, clients, etc. Establishing network communications is aided by one or more network device interface(s) 143, such as a network interface card (NIC), a modem or the like suitably connected to the system bus 1 10. These can serve as a common interface for various other devices within a LAN and/or as an interface to allow networked computers to connect to external networks. System 12 preferably also operates with various input and output devices as part of I/O system 18. For example, user commands or other input data may be provided by any of a variety of known types of input devices 144 (e.g. keyboard, pointing device, game controller, power pad, digital camera, image scanner, modem, network card, touch screen, microphone) having associated input interface(s), generally 146. One or more output devices 148 (e.g. monitor or other suitable display device, printer, fax, recording device, plotter) with associated interfaces, generally 1 50, may also be provided. For instance, a display monitor 1 52 may be connected to the system bus 1 10 by a suitable display adapter 1 54 (i.e., video card) having associated video firmware 1 56.

Although certain aspects for a user's computer system may be preferred in the illustrative embodiments, the present invention should not be unduly limited as to the type of computers on which it can be implemented, and it should be readily understood that the present invention indeed contemplates use in conjunction with any appropriate information processing device (IPD) having the capability of being configured in a manner for accommodating the invention. Moreover, it should be recognized that the invention could be adaptable for use on computers other than general purpose computers (e.g. embedded computers), as well as general purpose computers without conventional operating systems.

Software embodying the present invention may be distributed in known manners, such as on computer-readable medium which contains the executable instructions for performing the methodologies discussed herein. Alternatively, the software may be distributed over an appropriate communications interface so that it can be installed on the user's computer system. Furthermore, alternate embodiments which implement the invention in hardware, firmware or a combination of both hardware and firmware, as well as distributing the modules and/or the data in a different fashion will be apparent to those skilled in the art. It should, thus, be understood that the description to follow is intended to be illustrative and not restrictive, and that many other embodiments will be apparent to those of skill in the art upon reviewing the description. " • ■

More particularly, described herein are methods that manipulate the Windows XP Registry along with associated data structures. For descriptive purposes, and not by way of limitation, the methods described are named CREATE KEY, CREATE VALUE. RENAME KEY, RENAME VALUE and DELETE KEY, DELETE VALUE.

Each of these methods is based on a set sub-methods, or sub-routines, which when combined in the proper order and sequence as described herein, produce the proper result. These atomic sub-routines are descriptively named, such as for example, SUB_NAVICATE_TO_KEY, SUB_NAVIGATE_TO_VALUE, SUB_CREATE_NEW_KEY, SUB_CREATE_NEW_ VALUE, SUB1DELETE_KEY, SUB_DELETE_VALUE, SUB_INSERT_KEY and SU BJ NSERT. VALU E.

It is important to note that there are many ways an ordinarily skilled artisan could use the sub-methods (or other sub-methods not described herein) to produce the desired method, other than the preferred approaches discussed herein.

However, before discussing these registry manipulation methods, a technician must first use some approach to determine the actual location of the registry files on an NTFS volume. As mentioned above in the Background section, this can be accomplished using either a self-contained utility program or an NTFS aware file system. Integral to

this is the technician's ability to read/write sectors of a hard disk. While this is a skill which may only be within the scope of the advanced technicians, there are numerous publicly available software programs for accomplishing this including, for instance (1 ) "WinHex" distributed by X-Ways Software Technologies, Germany and available from the website http://www.winhex.com; and (2) "PTS Disk Editor" distributed by . PhysTechSoft.Ltd. and available at the website http://www.geocities.com/thestarman3/tool/de/PTS-DE.htm.

Fig. 2a illustrates an embodiment of the invention which incorporates the general steps a technician might follow to access a registry file from an NTFS volume. Stated somewhat differently, Fig. 2 incorporates a general method 20 for accessing a registry file the NTFS file system is decoded, thus revealing the location of the actual registry data on the hard disk. Upon, accessing the registry file, its keys or key values can either be read or modified, as is discussed with reference to the remaining figures of the application. Method 20 begins by determining at 22 the starting sector of the registry file. Again, this can either be accomplished using a self-contained tool or an NTFS aware file system. The extent (i.e., length) of the registry file is then ascertained at 24. At 26, the registry file can be read and decoded by converting any file offsets into a physical sector + byte offset. The file offsets can be obtained, for example, by knowing data structures of the various registry components, as illustrated above. In using a file system or redirector to access the registry file, this step 26 could potentially be performed automatically, as well. Based on the results of step 26, the physical sector can then be read at 28, after which flow proceeds at 210 to go to the byte offset. If this is the determined at 212 to be the location of the particular registry key or registry value of interest, then flow proceeds read or modify it at 214 (all as discussed below in the remaining figures) before method 20 terminates at 216. Otherwise, flow proceeds again to step 26 until the registry key or key value of interest is ultimately located.

Since the DOS operating system does not automatically support non-FAT file systems, accessing the Windows registry or a batch file through DOS is more entailed than accessing an NTFS volume. For example, if one attaches a hard drive formatted with the NT operating system to a computer and then boots the DOS operating system from a floppy disk, DOS will return an error when an attempt is made to access any files located on the hard disk. Therefore, in order for DOS to work with a non-FAT drive (floppy, CD-ROM, hard disk, etc), one must write a program that will give the added functionality to DOS. To a software engineer, there are four basic methods to add not- FAT file system support to DOS.

A first approach involves trapping all of DOS functions and then sending all non- FAT file system related calls to a set of software codes that translate the DOS function call, perform the required action and then return information to the calling program in the same form DOS would use. This solution has limited general capability - namely poor "current directory" support, but would work in specific circumstances whereby user feedback is either not required or minimal. Original network support, notably Novell Netware, used this approach.

A second approach is to "virtual ize" a DOS FAT disk. That is, a software engineer could attach a disk to DOS and then either at the hardware level or device driver level virtualize DOS's manipulation of a FAT drive. For example, if DOS wanted to read a cluster from the "virtual" disk, the modified device driver or hardware interface would translate the cluster number into a native sector, read the sector data and then return the data to DOS.

A third approach is for the software engineer to create a "redirector". Microsoft created the "redirector" interface for DOS starting with DOS version 3.1. Although not immediately published by Microsoft, the interface has become publicly available through the efforts of independent developers to reverse engineer the interface. The basic idea of a redirector is to set a bit within DOS's internal current directory structure of the drive

letter one wishes to have DOS view as a remote drive. From then on, DOS calls the "multiplex" interrupt (interrupt 20 with its file system requests (e.g., CREATE a FILE or RENAME a FILE, etc). It is up to the developer of the redirector to actually process the request. There is only one redirector for -NTFS which is known to the inventor. This redirector is available as part of the "Administrator's Pak" product distributed by Winlnternals, Austin, Tx (http://www.wininternals.com). The present teachings provide the description of a second NTFS redirector.

A fourth approach is through DOS's "long filename" functions. Native DOS only supports files named with the 8 + 3 convention, wherein the "8" corresponds to the permitted length of the filename and the "3" corresponds to the length of the file extension. DOS filename are not only limited to 8 characters for the filename and 3 for the extension, but may not contain spaces or other special characters. Starting with the introduction of Window 95, however, Microsoft added functions within its int 21 h interface to handle files with long filenames. Much like a redirector, the device by which the "long" filename refers can be anything - a RAM disk, CD-ROM, NTFS file system or even Linux.

With an appreciation of the above, Fig. 2b illustrates an exemplary method 220 for accessing the Windows registry through DOS on a non-FAT or non-FAT32 file system. Indeed, an important aspect of this invention is providing access to a registry file, regardless of the type of file system it is located on, such as through any of the above-mentioned four methods whereby DOS is manipulated to provide support for a non-FAT or a non-FAT32 file system. It should be noted, however, that it is additionally contemplated that the teachings herein not be limited to DOS, and that other operating systems are envisioned. For example, one could install a driver upder LINUX to access an NTFS partition and then utilize the method described herein to modify the. registry.

Turning then to Fig. 2b, following start 222 a request is made at 224 to access the registry file, and this request is sent to DOS. A determination is made at 226

whether there are any "trapped" DOS interrupts. If so, then a determination is made at 228 whether the DOS call is for "Device B". For purposes of explanation, Device B is considered to be one which is accessed by trapping DOS functions (TRAP). If the DOS call is for Device B then TRAP accesses the device at 230 and flow returns at 232. If DOS interrupts are trapped but the call is for another device, referred to as "Device A", which is accessed directly by DOS then flow proceeds instead to 234 so that DOS can access Device A.

If DOS interrupts are not trapped in response to the 226 then a determination is made at 236 whether the request is being made on a drive that has been redirected. If so a determination is made at 238 whether the request is for a device which is accessed through a redirector (REDIR), referred to herein as "Device C" for purposes of explanation. If so, then the redirector handles the request at 240 before returning 232. If, on the other hand, the request is not on a drive that has been redirected then a determination is made at 242 whether the request is through the DOS LONCNAMES interface. If so, then LONGNAMES handles the request at 244. Otherwise, flow continues through DOS at 246, as would also be the case if the response to inquiry 238 is negative. ^L

With the above in mind, the various registry manipulation methods will now be discussed.

CREATELKEY Method Overview

The CREATE_KEY method describes the creation of a new registry key. Creating a new registry key involves creating a new KN_RECORD and inserting the new KN_RECORD into the proper place within the registry based on the new key name. This method does not allow for the new key name to be created if the FULL_KEY_NAME name already exists within the registry. Further, the CREATE_KEY method does not allow for the creation of a new root key. It only allows for the creation of child keys. This is because the Windows XP Registry has predefined root keys.

Using the sub-methods mentioned above, the CREATE_KEY method is as follows. For example, if we are creating the key TOP\ONE\TWO the parent would be called TOP\ONE.

SUB_NAVICATE_TO_KEY (TOP\ONE\TWO)

If ( TOP\ONE\TWO) exists THEN ERROR

SUB_NAVIGATE_TO_KEY (TOP\ONE)

IF does not exist, THEN ERROR

SUB-CREATE-NEW-CHILD-KEY (TOPVONEVTWO)

With the above in mind, an overview of the method 30 for creating a registry key, referred to as "CREATE-KEY" is introduced in Fig. 3a. Collectively, Figs. 3a-3j comprise the detailed CREATE-KEY methodology. According to the method 30, an initial operation is made 32 to navigate to the FULL_KEY_NAME. If the key name already exists at 34 then an error is returned at 36. Otherwise, if the FULL-KEY-NAME does not exist then the SHORT-KEY-NAME is isolated from it at 38. For example, if the FULL_KEY_NAME=TOP\ONE\TWO then the SHORT_KEY_NAME=TWO and the new FULL_KEY_NAME=TOP\ONE. Once the SHORT_KEY_NAME has been isolated, flow proceeds again at 32 to navigate to the FULL-KEY-NAME, at this point TOP/ONE. Another determination is then made at 310 as to whether it exists and, if not, an error is returned 36. Otherwise, if the FULL-KEY-NAME does exist in response to inquiry 310 then the SHORT_KEY_NAME is created 31 2, after which method 30 finishes 314.

Reference is now made to Fig. 3b to describe the operations of navigating to the FULL_KEY_NAME 32 introduced in Fig. 3a. At 316 an attempt is made to navigate to the registry's root key, which subroutine is shown in Fig. 3c. If it is not possible to navigate to the root key at 31 8 then a determination is made at 320 as to whether the FULL_KEY_NAME length=O, corresponding to a request to navigate to the root key. Root keys do not have KN_RECORD records. That is, there is no disk structure that represents a root key. If the length equals zero then flow returns without error at 322. Upo.n returning, the KN-RECORD is populated with data corresponding to the last

SHORT_KEY_NAME value. For example, if the user wishes to navigate to the key TOP\ONE\TWO, the KN_RECORD will be populated with information related to the "TWO" KN_RECORD record. If the full key length is not equal to zero then the first SHORT_KEY_NAME is isolated from the FULLKEY.NAME at 324, and the FULL_KEY_NAME is then updated. In essence, .this step 324 removes the next short key name from FULLKEY.NAME. So, continuing with the above example, if TOP\ONE\TWO is the FULL_KEY_NAME, then the SHORT_KEY_NAME which is isolated is equal to TWO and the updated FULL_KEY_NAME becomes TOP\ONE. Flow then proceeds to 326 to navigate to the SHORT_KEY_NAME, that is, the child key. Upon a ^' successful return from 326, the KN_RECORD record will contain the child key's KN_RECORD data. Presuming step 326 returns without error at 328, flow proceeds again to 320 to ascertain if the updated FULl_KEY_NAME has a length equal to zero. It can be appreciated that operations 320, 324, 326 and 328 will proceed until the updated FULI_KEY_NAME length=0, at which time flow returns (to 34 in Fig. 3a) without error at 322. If, on the other hand, the child key cannot be navigated to, then an error is returned at 330.

Navigation to the root key 316 is now discussed with reference to Fig. 3c. Initially this involves navigating to the root HBIN at 332 (Fig. 3d) since the root HBIN block contains the root key of the registry. This block is read into memory as discussed below at Fig. 3d. If there is an error loading the root HBIN at 334, then an indication of such is returned at 336. Otherwise, a pointer is made to the first record in the HBIN block (i.e. the KN_RECORD) at 338. This memory pointer is formed by first pointing to the base of the root HBIN block and then adding the size of the HBIN data structure (e.g. 32 bytes). If it is determined at 340 that the record is a valid KN_RECORD then flow returns at 342 without error. Otherwise, flow proceeds to the next record in the root HBIN at 344 and if it exists at 346 then determination 340 is then made to ascertain if the KN_RECORD is valid. If the record does not exist at 346 then an error is returned • 336. If everything proceeds normally, then the records in the HBIN block are

sequentially analyzed to ascertain if a valid KN_RECORD exists, i.e. if it has the proper signature.

Navigation to the root HBIN, corresponding to operation 332 in Fig. 3c, is now discussed with reference to Fig. 3d. An initial determination is made at 334 whether the RECF record has been initialized. The RECF record is found within the first 4,096 bits of a registry file, starting at the first byte within the file. If the RECF is not initialized then it is loaded from the registry file at 346 and its signature field is set to equal to the hex value 0x66676572. Assuming the REGF is properly loaded at 348, flow proceeds to 350. If, on the other hand, the REGF has already been initialized the flow proceeds to navigate to the file offset described in the field RECF.LastHBINBIock. This technique 348 involves moving a file pointer to the indicated offset, and is something the ordinarily skilled artisan would be well equipped to do; thus, it need not be described in further detail here.

Once the file offset has been navigated to at 350 then the HBIN block is read at 352. This operation involves reading the HBIN header from the disk and retrieving the HBIN. sizeOfBlock value, and then re-reading the HBIN header + data from offset. Again, it is assumed that the ordinarily skilled artisan would know how to accomplish this without need for further discussion. A determination is then made at 354 whether the encountered HBIN block is valid. If not valid, then an error is returned at 358; otherwise, it is determined at 356 whether there is a parent block. Depending on whether the HBIN.ParentBlock==0 at 356, flow either returns without error at 360 or with error at 362.

The operation of navigating to the SHORT_KEY_NAME (i.e. the child key) at 326 in Fig. 3b is now described in greater detail with reference to Fig. 3e. In doing so, at 364, the record indicated by the KN_RECORD.offsetToSubKeyRecords field is read. Determinations are then made at 365-367, respectively, as to the type of record encountered. Thus, at 365 a determination is made whether it is an FL_RECORD and, if so, flow proceeds at 368 to navigate to the key using the FL_RECORD. Otherwise, at 366

a determination is made whether it is an IR-RECORD and, if so, flow proceeds at 369 to navigate to the key using the IR.RECORD. Otherwise, a determination is made at 367 as to whether it is an IL.RECORD and, if so, flow proceeds at 370 to navigate to the key using the IL_RECORD. Once the respective subroutine 368-370 is executed, flow returns at 372. Of course, if the encountered record does not satisfy any of the inquiries 365-367 then flow returns with error at 374.

In reading the registry record (corresponding to step 364 in Fig. 3e) flow proceeds in Fig. 3f. It should be appreciated that this Fig. 3f applies regardless of the particular record type being read. Armed with data corresponding to the OFFSET and optional SIGNATURE flow initially proceeds at 376 to seek the registry file to OFFSET. In other words, her a file pointer is sought to the byte offset within the registry of one of the registry structures of the record Then, at 378, 4 bytes are read from the registry file into a 32-bit DWORD value, and the RecordSize is set to this 32-bit value. If the 32 ^nd bit is set at 380 then a variable "R" is set at 382 such that R=-RecordSize. If it is then determined at 384 that the size of the record is zero then the registry file OFFSET is sought at 386 and the number of bits in the record size is read from the registry file into a RECORD_BUFFER. If a signature exists at 388 then a determination is made at 390 whether the signature is in the RECORD_BUFFER. The 4 ^th and 5 ^th bits in the RECORD_BUFFER correspond to the signature. If it is in the BUFFER, or if no signature exists at 388, then flow returns without error at 392.

The discussion will now proceed with reference to Figs. 3g-j to describe the appropriate navigation to either the FLRECORD 368, the IR_RECORD 369 or the IL_RECORD 370, whichever the case may be. Navigation to the key using the FL_RECORD is shown in Fig. 3g. Initially, an index value is set to equal 0 at 396. While this index value is less than the FL_RECORD.Count 398, an option can be encountered to use a HASH key at 3910. If this is desirable, then a HASH key is created from the SHORT_KEY_NAME at 3912. A determination is then made at 3914 whether the hash value corresponding to the particular index is equal to the SHORT_KEY_NAME

HASH_VALUE. If not, then the index is incremented by 1 at 3916 and flow continues again at 398. If a HASH value key is not to be used in response to 3910, or if the corresponding index's HASH value is not equal to the HASH value of the SHORT_KEY_NAME at 3914, then the KISLRECORD that is indicated by FL_RECORD.HASH[INDEX]. offset is read at 3918. A determination is then made at 3920 whether the SHORT_KEY_NAME is equal to the KISLRECORD.KeyName. If and when this is the case, flow will return without error at 3922; otherwise, flow proceeds to 3916 to increment the index by 1 and thereafter continue at 398. At any point, if the index is not less than the FL_RECORD.Couπt then flow returns with error at 3924.

Creation of the HASH VALUE 3912 is described now in Fig. 3h. Initially, at 3926, the following variables can be set. INDEX=O and FOU ND_NU LL= = FALSE. While the INDEX<4 at 3926 and FOUND_NULL==TRUE at 3928, then S=O at 3930. Otherwise, if FOUND_NULL is something other than false or true then another variable "S" can be set at 3932 such that S=SHORT_KEY_NAME[INDEX]. If this value is 0 at 3934 then the HASH[INDEX] is set to equal S at 3936, which would also be the case following step 3930 above. If the variable S is not equal to 0 at 3934 then FOUND_NULL is set to be TRUE at 3938 before flow proceeds to set the value of S at 3936. Thereafter, the INDEX is incremented by 1 at 3938. While the index value remains <4 the above repeats itself until eventually flow returns at 3940.

Navigating to the registry key from the IR_RECORD, corresponding to step 369 in Fig. 3e, is now described with reference to Fig. 3i. At 3942, the INDEX=O, and while this value is less than IL_RECORD.Count at 3944, then the KN_RECORD which is indicated by IL_RECORD.offset[INDEX] is read at 3946. A determination is then made at 3948 whether the SHORT_KEY_NAME==KN_RECORD.KeyName. If so, flow returns without error at 3950. Otherwise, the INDEX is incremented by 1 and the above repeats. If at any point in the recursion, the variable INDEX is no longer less than the IL_RECORD. Count, an error is returned 3954.

Finally, navigation to the registry key using the IL_RECORD, corresponding to step 370 in Fig. 3e, is now described with reference to Fig. 3j. Initially again, a variable INDEX is set to zero at 3956. While INDEX < IR_RECORD.Count at 3958, the record indicated by the IR_RECORD.Offset[INDEX] field is read at 3960. A determination is then made at 3962 whether the subject record is a KN_RECORD. If not, a determination is made at 3964 whether it is an IL-RECORD. If it is also not an IL_RECORD, then a determination is made at 3965 whether it is an FL-RECORD. If none of these record types is identified, flow returns with an error a 3966. If, on the other hand, the record is either an IL_RECORD or an FL.RECORD, then it is navigated to at 3967 or 3968, respectively, as discussed above with reference to Figs. 3j and 3g. Flow then returns 3969.

If, on the other hand, the response to inquiry 3962 is in the affirmative then a determination is made at 3970 whether the SHORT_KEY_NAME equals the KeyName of the KN_RECORD. If so, then flow returns without error at 3972. Otherwise, the index is incremented at 3974 and the above repeats itself.

CREATELVALUE Method Overview

The CREATE. VALUE method describes the creation of a new registry key value. Creating a new registry key value involves the creation of a new KV_RECORD record and, if data is associated with the new key value, a new VALUE-DATA record. The CREATE. VALUE method does not allow for the creation of values with duplicate value names.

For example, if we create a new value in the key named TOP\ONE\TWO called TWOVALUE, then the general method would be as follows:

SUB_NAVIGATE_TO_KEY (TOP\ONE\TWO)

IF (TOP\ONE\TWO) does not exist, then ERROR

SUB_NAVICATE_TO_ VALUE (TOP\ONE\TWO, TWOVALUE)

IF (TWOVALUE) exists, then ERROR

SU B_CREATE_N EW.VALU E

The general method 40 for creating a key value, is introduced in Fig. 4a, and the method particulars will be appreciated with reference to Figs. 4a-4e. In creating a new registry key value, flow initially proceeds at 32 to navigate to the FULL_KEY_NAME, as was discussed above with reference to Fig. 3b. If the key does not exist in response to 42 then an error if returned 44. However, assuming existence of the key, flow proceeds at 46 to navigate to its value, descriptively referred to as NEW_ VALUE. If such a value already exists in response to 48 then an error is returned. Otherwise, at 410 the NEW_ VALUE is created before method 40 finishes at 41 2.

Subroutine 46 for navigating to the value NEW_VALUE is introduced in Fig. 4b. At 41 4 a variable INDEX is initialized at zero, after which the VALUE_ARRAY is read into , memory at 364, similar to the approach discussed above in Fig. 3f with reference to HBIN. While the INDEX<NumberOfValues field in the KN.RECORD 41 6 the KV.RECORD is read, again similar to the manner in Fig. 3f. If the names are equal at 41 8 then flow returns without error. Otherwise, the INDEX is incremented by 1 at 420 and the above repeats. If at any point INDFJONumberOfValues contained in the KN_RECORD flow will return with an error at 422.

Creation of the NEW_ VALUE 410 in Fig. 4a is introduced in Fig. 4c. At 424 a new KV_RECORD is created having the specified value name and value type. A new VALUE_DATA record is then created and written to disk at 426. The LengthOfbata and OffsetOfData fields are then updated for the new KV_RECORD at 428 and 430, respectively. At 432 the NumberOfValues field in the KN.RECORD is incremented by 1 . The new KV_RECORD is then written to disk at 434 and its OffsetToValueList field is updated if necessary at 436. Then, at 438, the updated KN.RECORD is written to disk before flow returns 440.

Writing of the KV_RECORD and KN.RECORD to disk is shown in Fig. 4d. It should be noted that Fig. 4d illustrates a method for creating enough data space within an HBIN block. Should the OFFSET value be changed, then any corresponding offset

values contained within the records KISLRECORD, KV_RECORD, etc. are also changed. Fig. 4d does not illustrate the updating of these related values, since the same would be well within the purview of the ordinarily skilled artisan.

With the above in mind, the RecordSize field is initially retrieved at 442 from the record being written. This RecordSize field corresponds to the 1 ^st 4 bytes from the record being written, which can be set to the variable "RS". If the number of bytes to be written (W) is > RS, then the RECF.LastHBINBIock of the HBIN block is read into memory at 446. At this point 448 flow proceeds to locate enough free space within HBIN to accommodate RS bytes. The block returned will have a block size that is evenly divisible by 8. A runtime variable OFFSET is then set to the location in HBIN of this free space at 450, and the record is written to the offset at 452. As can also be seen in Fig. 4d, the record is written to the offset if W < or = RS in response to 444. Once written, flow returns 454.

Locating free space within HBIN is described now in Fig. 4e. This process 448 begins by setting, at 456, another runtime variable AMOUNT_OF_FREE_SPACE equal to HBIN.SizeOf Block minus the size of the HBIN header' size. The 1 ^st Registry Record in the HBIN block is then referenced at 458, and while the RecordSize of the Registry Record is valid at 460 the AMOUNT_OF_FREE_SPACE is decreased by the field value of the RecordSize at 462. Flow then proceeds to the next Registry Record in the HBIN block at 464 and the OFFSET is adjusted to point to the next field. The above repeats as long as the field value in the registry is valid. Once this is no longer the case, the amount of free space is decreased by 4 at 466 to ensure that there will be a last terminating record size field within the HBIN block. If the AMOUNT_OF_FREE_SPACE >= a runtime variable.REQUESTED SIZE, at 468 then the RECORD_SIZE field for the new Registry Record is written at the OFFSET location at 470. Its runtime variable NEW_RECORD_SIZE is made to be evenly divisible by 8. However, if there is insufficient space in response to 468 then a new HBIN is created at 469 which is large enough to satisfy the requested size. This new HBIN is preferably evenly divisible by 4,096 bytes. The OFFSET is then set to

the 1 ^st record space in the HBIN block and the REGF.LastHBINBIock block value is adjusted to point to this new HBIN block. The HBIN.ParentBlock and HBIN.SizeOfBlock field values are also set. Once this is done then the variable RECORD_SIZE field of the new Registry record is written at the offset as discussed previously. Following 470, a new INVALID RecordSize field for the Registry Record is written at OFFSET+NEW_RECORD_SIZE, 472. The OFFSET is then returned 474.

DELETE_KEY Method Overview

The DELETE_KEY method describes removing a key, and all of its associated child keys and ail of its values from the registry. For example, if we're to remove the key TOP\ONE\TWO from the registry, leaving the parent key TOP\ONE intact, the general method would be as follows:

SUB_NAVIGATE_TO_KEY (TOP\ONE\TWO)

IF (TOP\ONE\TWO) does not exist, then NO ERROR

SUB_REMOVE_CHILD_KEY

With the above in mind, deletion of a key50is now discussed with reference to Figs. 5a & b. Upon navigating at 32 to the FULL_KEY_NAME a determination is made at 52 whether it exists. Assuming so, the SHORT_KEY_NAME is isolated from the FULL_KEY_NAME at 54, and a NEW_FULL_KEY_NAME is created at 56. Method 50 then navigates to this NEW_FULL_KEY_NAME, again corresponding to operation 32 discussed above in Fig. 3b, after which the SHORT_KEY_NAME is deleted from the parent key at 58, thus completing the method at 510.

Deletion of the SHORT_KEY_NAME from the parent key is illustrated in Fig. 5b. The record indicated by the parent key is initially read at 512 and it is determined whether it is one of an FLRECORD at 51 3, an IR_RECORD at 514 or an IL.RECORD at 51 5. Assuming it is one of these types, such that an error is not returned at 516, then a suitable search takes place for the associated OFFSET at either 51 7, 518 or 519. Assuming the OFFSET is found 520 then the array element is removed at 522 and the

record updated at 524. The NumberOfSubKeys in the parent KN_RECORD is then decremented by 1 at 526 and the parent KNLRECORD is written at 528.

DELETE_VALUE Method Overview

The DELETE. VALUE method describes removing a key value from the registry. For example, if we're to remove the key value TWOVALUE from the key TOP\ONE\TWO the general method would be as follows:

SUB_NAVICATE_TO_KEY <TOP\ONE\TWO)

IF σθP\ONE\TWO) does not exist, then NO ERROR

SUB_NAVIGATE_TO_VALUE (TWOVALUE)

IF (TWOVALUE) does not exist, then NO ERROR

SUB_DELETE_VALUE

Deletion of a registry key's value 60 is described in Figs. 6a and b. Upon navigating to the FULL_KEY_NAME 32 (See Fig. 3b) a determination is made at 62 whether it exists. Again, assuming it does exist, flow proceeds at 46 to navigate to the key's value name (see Fig. 4b.). Assuming it does exist at 64 the value is deleted from the key at 66 and then method 60 finishes 68.

Actual deletion of the value 66 is shown in greater detail in Fig. 6b. Initially, at 610, the VALUE_ARRAY data is read from the KN_RECORD. This data is referenced by the field OffsetToValueList in the KN_RECORD. An index variable is then set to 0 at 612 and, while this INDEX<KN_RECORD.NumberOfValues at 614, the VALUE_ARRAY.Offset[INDEX] associated with the KV_RECORD is read at 616 and a variable, VN ₁ is set to equal the value name which is read. If at 618 this value name is determined to be equal to the value name to be deleted (denoted "DVN") then the VALUE_ARRAY.Offset[INDEX] value is deleted at 620, the KN_RECORD.NumberOfValues record is decremented at 622, the VALUE_ARRAY is updated at 624, the record of the KN-RECORD is updated at 626 and flow returns without error at 628. On the other hand, if VN and DVN are different, flow proceeds to 630 to increment the INDEX variable

by 1 and the above repeats until such time as either VN=DVN or the INDEX is no longer < KN_RECORD.NumberOfValues, resulting in an error being returned at 632.

RENAMELKEY Method Overview

The RENAME_KEY method describes renaming a key within the Registry- Because- key names are in sorted order and must be unique, the method preferably entails navigating to the original key, copying the key data into a temporary buffer, deleting the original key and then inserting the newly named key, with the original key values, into the registry. For example, if we're to rename the key TOP\ONE\TWO to TOP\ONE\THREE the general method is as follows:

SUB_NAVICATE_TO_KEY (TOP\ONE\TWO)

IF (TOP\ONE\TWO) does not exist, THEN ERROR

IF (TOP\ONE\THREE) does exist, THEN ERROR

A duplicate of the TOP\ONE\TWO key is made. Since it should be well within the ability of the ordinarily skilled artisan to create a duplicate temporary key, further discussion need not be provide here.

DELETE.KEY METHOD σθP\ONE\TWO)

CREATE.KEY METHOD (TOP\ONE\THREE)

With the above in mind, Figs. 7a-7g collectively comprise a process for renaming a registry key. With initial reference to the general method 70 of Fig. 7a, this begins by navigating to the key name that is to be renamed (referred to as OLD_FULL_KEY_NAME), as described in Fig. 3b. Assuming it exists at 72 flow proceeds at 32 to now navigate to the NEW_FULL_KEY_NAME. Assuming it exists at 74 the OLD_FULL_KEY_NAME is deleted at 58 (Fig. 5b), and the NEW_FULL_KEY_NAME is created at 76. General method 70 then finishes 78.

Creation of the NEW_FULL_KEY_NAME 76 is introduced in Fig. 7b and begins at 710 with creation of a new KN_RECORD record with default values. A new FL_RECORD is

then created at 71 2, and its count is set to = 0 to indicate there are no sub keys. Then a VALUE_ARRAY is created at 714, also with its count set to 0 to indicate no values. The VALUE.ARRAY, the FLRECORD and KN_RECORD are then written to disk (generally 716) in a manner corresponding to that described above with reference to Fig. 4d. In doing so, the KN_RECORD.OffSet for the VALUE.ARRAY is set to the ValueList file, and the KN.RECORD.OffSet for the FLRECORD is set to the SubKeyRecords. Then at 71 8, the KN_RECORD is inserted into the Parent KNLRECORD, followed by the Parent KNLRECORD being written to disk at 434 (Fig. 4d) before completion at 722.

Insertion of the key 718 is introduced in Fig. 7c. Given the CHILD.OFFSET (i.e. the file offset of the child KNLRECORD record) and the CHILD_NIAME, at 720 the Registry Record referenced by the KN_RECORD.OffSetToSubKeyRecords field value is retrieved. Determinations are then made at 721 -724, respectively, whether the retrieved record is an IR_RECORD, an IL_RECORD, an FLRECORD or a NULL record. If it is none of the above, then an error is returned at 726. If, on the other hand, it is either an IR_RECORD, an IL_RECORD or an FLRECORD, then flow proceeds to insert the CHILD_OFFSET into the appropriate record at 727-729, respectively. As can also be noted in Fig. 7c, if the retrieved registry record is determined to be a NULL record at 724, then a new FLRECORD is created at 725 prior to insertion of the CHILD.OFFSET into the FLRECORD at 729. Following insertion of the child key, routine 71 8 then returns at 730.

The appropriate routines for inserting the CHILD_OFFSET into either an IR_RECORD, an ILRECORD or an FLRECORD are now discussed with reference to Figs. 7d-7f, respectively. In Fig. 7d routine 727 begins at 32 by setting an INSERT_OFFSET==0. While this variable is < the IR_RECORD.Count at 734, the Record indicated by IR_RECORD.Offset[INSERT_OFFSET] is read 736. If it is determined to be an ILRECORD at 738 then the key is inserted into it at 740, and assuming successful insertion at 742 sub-routine 727 returns 744. If insertion is not successful then INSERT.OFFSET is incremented by 1 at 746 and flow proceeds again to 734. If, on the other hand, the record which has been read at 736 is not an ILRECORD a determination

is made at 748 whether it is a KNLRECORD. If not, an error is returned 750. Otherwise, a determination is made at 752 whether the CHILD SHORT_KEY_NAME (CSKN) < KN_RECORD.keyName, which ^' inquiry determines whether the original space can be reused. If so, then flow proceeds to 746 to increment the INSERT _^ OFFSET. Otherwise, the KN.RECORD.NumberOfSubKeys of the parent is incremented by 1 at 754, as well as the IR_RECORD.Count at 756. Then, at 758, the offset value of the child KN_RECORD is inserted into the IR_RECORD.Offset array. This is again something which would be well within the purview of the ordinarily skilled artisan. Then, at 760, the IR_RECORD is written and sub-routine 727 returns at 762. If, at any time, the INSERT.OFFSET is not < IR_RECORD. Count then an empty IL_RECORD record is created at 764 and the child KN_RECORD is inserted into it at 766, after which it is written to disk at 768.

Insertion of a key into the IL_RECORD 728 is described now in Fig. 7e. Initially the ILRECORD is read at 770 and an index variable is set to 0. While the index variable is < IL_RECORD.Count at 772, the KN_RECORD record which is referenced by the IL_RECORD.Offset[INDEX] is read at 774, and a variable "KN" is set to be equal to KN_RECORD.KeyName. At 776 the key name found in the KN_RECORD is then compared with INSERT.NAME (e.g., KN==INSERT_NAME). If INSERT.NAME < KN at 778 the new size of the IL_RECORD is calculated 780, and a determination is made at 782 whether the record will fit. If so, then at 784 the OFFSET Value is inserted into the ILRECORD at INDEX and the ILRECORD.Count field is incremented by 1 at 786. The ILRECORD is then written at 788 and the sub-routine then returns at 790.

On the other hand, if it is determined at 782 that the record will not fit then the ILRECORD is split at 792 and the IR_RECORD parent is updated. Flow then proceeds again to 770. Also, if it is determined at 778 that the INSERT.NAME is not < KN then the variable index is incremented by 1 at 794 and flow proceeds to 792 if at any time the index is not < than the ILRECORD.Count then an error will be'returned 796.

Insertion of a key into the FLRECORD (729) is now discussed with reference to Fig. 7f. Initially, at 798 the INSERT.OFFSET is set to 0. At 3912 a CHILD_HASH value is

created, similar to that described above in Fig. 3h. While the INSERT_OFFSET < FLRECORD.Count, a variable "H" can be set to equal to the

FL_RECORD.HASH[INSERT_OFFSE ^" η.HashValue at 791 2. At 7914 the CHILD.HASH is compared to the variable H. If < H at 7916. INSERT_OFFSET is incremented by 1 at 791 8 and flow proceeds again to 7910. Otherwise, if the CHILD_HASH is equal to H at 7920 then an IL_RECORD is created at 7922 and the CHILD_HASH is inserted into the IL.RECORD at 728 (See Fig. 7e) before sub-routine 729 returns at 7924.

On the other hand, if the CHILDJHASH is not equal to the variable H at 7920, or if the INSERT_OFFSET is not < FLRECORD.Count at 7910, then flow proceeds at 7926 to increment the FL_RECORD.Count by 1 . Then, at 7928, the Offset of the child KNLRECORD is inserted into the FLRECORD at INSERT.OFFSET. Then, at 7930, the field value for the parent KN.RECORD.NumberOfSubKeys is incremented by 1 after which the FLRECORD is written (See. Fig. 4d) before sub-routine 729 returns at 7924.

Creation of the ILRECORD, corresponding to operation 7922 in Fig. 7f, is shown in Figure 7g. - In creating the ILRECORD it is populated with default values at 7932 such that its count = 0. The new ILRECORD is then written to disk at 7934 before returning 7936.

RENAME_VALUE Method Overview

The RENAME. VALU E method describes renaming a value within the Registry. Because value names are in sorted order and must be unique, the method involves navigating to the original value, copying the value data into a temporary buffer, deleting the original value and then inserting the newly named value into the Registry. For example, if we're to rename the value TWOVALUE found in the key TOP\ONE\TWO to NEWVALUE the short method is as follows:

SUB_NAVIGATE_TO_KEY σθP\ONE\TWO)

IF (TOP\ONE\TWO) does not exist, THEN ERROR

SUB_NAVICATE_TO_VALUE (TWOVALUE)

IF (TWOVALUE) does not exist, THEN ERROR

SUB_NAVIGATE_TO_VALUE (NEWVALUE)

IF (NEWVALUE) exists, then ERROR

Again , a duplicate of the TWOVALUE value is made, a process well within the purview of the ordinarily skilled artisan.

DELETE_VALUE METHOD (TWOVALUE)

CREATE.KEY METHOD (NEWVALUE)

Finally, renaming of a key value 80 is illustrated in the flow diagram of Fig. 8. Upon navigating to the FULL_KEY_NAME 32 (See Fig. 3b) a determination is made at 82 whether it exists. Assuming it does, the process then navigates to the OLD_VALUE_NAME at 46 (See Fig. 4b) to determine at 84 whether it exists. Assuming it does, the process then navigates to the NEW_VALUE_NAME at 46 (See Fig. 4b) to ascertain at 86 whether it exists. If it does, then method 80 ends at 88. Otherwise, the value is renamed at 810 by modifying the KV_RECORD.valueName field. The KV_RECORD is then written at 434, 436 (See Fig. 4d) and the offset to the KV_RECORD is removed from the VALUE_ARRAY at 81 2, as would be known to the ordinarily skilled artisan. As also known to the ordinarily skilled artisan, at 814 the offset to the KV_RECORD is inserted into the VALUE_ARRAY in sorted order by name. The VALUE.ARRAY record is then written at 434, 436 (See Fig. 4d) before method 80 terminates at 88.

Accordingly, the present invention has been described with some degree of particularity directed to the exemplary embodiments of the present invention. While a number of exemplary aspects and embodiments have been discussed, those of skill in the art will recognize certain modifications, permutations, additions and sub- combinations thereof, and it is therefore intended that the invention be interpreted to include all such modifications, permutations, additions and sub-combinations within its true spirit and scope.