The registry is a fundamental part of the Windows platform. Serving as a configuration database, it is central to the operation of most applications in the Windows environment and the very operating system itself. In this chapter, you will learn how ColdFusion can access and manipulate the contents of the registry by using the CFREGISTRYtag. You will start by taking a look at what the registry is and how it works. Then, you will study the mechanics of how the CFREGISTRYtag can be used to view and alter the contents of the registry ..Finally, you will build an application, a registry viewer that enables a Web browser to be used to view the contents of the registry on the ColdFusion server.
Understanding the Registry
For many users of Windows 95, 98, and NT, the Windows Registry is the source of great mystery. It is viewed as a black hole filled with information so delicate that any tampering with it could cause the complete failure of a PC and the loss of all data it contains. Although working with the registry requires care, precision, and attention to detail, it shouldn’t be seen as a mysterious entity that is best avoided. In fact, the operation of Windows and of almost every application made for the operating system is so closely dependent on the registry that a basic understanding is important for any Windows user. This is especially true if you are considering using the ColdFusion CFREGISTRYtag to view or manipulate the registry on your server.
Using the Registry
The registry is not that complicated. Basically, it is a central database of information and settings used by Windows to start and to launch applications. The registry is used in everything from selecting drivers for devices, managing users, and controlling security settings.
• In the old days of Windows 3.1, these processes would have been done using a myriad of INI files: several for Windows and then one or more for each installed application. In today’s Windows platforms, this information is consolidated into the registry. The registry has several important facets that were lacking in the old INI-file model:
• A logical (once you understand it), hierarchical organization
• The capability to search the database
• Simple tools for adding and changing values stored in the registry
Normally, you do not need to access the registry in day-to-day operations. Windows keeps key system settings up to date, and software installation programs will create new keys and values as needed.
Understanding the Structure of the Registry
The registry is structured in a hierarchical tree, just as files and directories are on a disk. The registry is built out of keys and values. A key ‘can contain individual values as well as sub-keys, which in turn can contain values or sub-keys, This structure maps fairly cleanly to the file and directory model: Keys are like directories, whereas values are like files.
The Windows registry has six basic root keys under which an other keys are placed. These can be seen as similar to drives or partitions under which directories and files are placed. These keys are:
HKEY_ClASSES_ROOT Stores object linking and embedding (OLE) information, as well as file type and extension associations, among-other information.
HKEY_CURRENT_CONFIG .Stores information about the current hardware setup.
HKEY_CURRENT_USERS Stores settings about the user currently using the system.
HKEY_DYN DATA Stores dynamic information needed while using the system’s hardware. Fot instance, Plug-and-Play configuration information might be stored here, as well as performance data.
HKEY_LOCAL_MACHINE Stores information about the hardware and software installed on the system. This is commonly where individual applications will store their own keys and values. I
HKEY_USERS Stores an individual user’s settings, including Desktop configuration. The full name of a key or value is specified in much the same way ‘as file paths: by using the backslash character to mark the hierarchy of keys and sub-keys en route to the destination. For instance,
is the complete name of the Software key, which exists as a sub-key of HKEY_LOCAL_MACHINE.
Accessing the Registry
It may seem unusual to want to access the registry from a ColdFusion template. However, this can be useful for several tasks, including:
• Creating Web-based tools to remotely manage some of the settings on a ColdFusion server
• Checking various system settings to determine the appropriate action to take in a template
• Storing the configuration and settings for a complex Web application, just as other applications store their settings in the registry
Using the Registry on Solaris
The Solaris operating system doesn’t include a registry like that used in Windows. However, Coldf’usion frequently uses the registry, storing settings there, as well as some of the variables created by templates and applications. For this reason, a registry system is included with the Solaris version of Cold Fusion. The registry provides the necessary functionality for these parts of ColdFusion to operate. This scaled-down registry (which doesn’t contain any Solaris system settings)’is available by using the CFREGISTRY tag
Using the CFREGISTRY Tag
The CFREGISTRY tag is fairly straightforward to use, once you understand how the registry works and is structured. This tag provides five major functions:
• Reading all the keys and values and a certain location in the registry hierarchy
• Reading a specific registry value ,A
• Updating an existing value
• Adding a new value or registry key
• Deleting a registry value or key
The value of the AaION attribute determines which action is performed when using the .cFREGISTRY tag. The following list outlines the possible values for the attribute and their effects:
GetA11 Reads ,all keys and values at a certain location
Get Reads a specific value
Set Updates a value or adds a new value or key
Delete Deletes a key or value
Using the ACTION=” GetA 11 attribute causes the CFREGISTRY tag to retrieve all values and keys at a specific location iIt the registry hierarchy. To obtain the value¥nd keys at . a location, you need to use some or all of the following additional attributes:
BRANCH The complete path and name of the location (or branch) to be read. This is a , required attribute
TYPE Specifies the type of data to return, Possible data types include Stri ng (for string values), DWordfor DWord values, Key for registry keys, and Anyfor all keys and values. By default, this attribute is set to String.
NAME Specifies the name of the query result set through which to return the requested values and keys. This is a required attribute.
SORT Specifies the query columns on which to-sort the-returned data. Possible columns to sort on are Entry, Type, and Value. Sorting can be done either in ascending or descending order, and multiple columns can be used as sort keys and can be separated by commas. For example, SORT–Entry ASCI Type DESC”sorts first in ascending order on the Entry column, and then in descending order on the Type column.
The data from this use of the CFREGISTRYtag is returned as a standard query result set, which can then be used like all result sets (including in the CFOUTPUTand CFLOOP tags). The result set contains three columns.
In this location (or branch) of the registry, Windows 95 and 98 store critical information about the current Windows installation. Here, you find values defining everything from the registered owner of the software to the default program files directory to the location where Windows stores Desktop wallpaper. This branch also has numerous subkeys specifying information about specific parts of Windows, such as the logon process or the Control Panel folder.
The following tag retrieves all keys and values at this location and returns them in the query result set called Windows. Information is sorted first by the type of entry, and then by the Entry column. It would be written as follows.
This result set can then be used in a CFOUTPUT tag to produce a table of the values and keys at the specific location:
Using ACTION GeT you can retrieve a specific value from the registry in a finegrained way. You do so by specifying these additional attributes:
BRANCH The complete path and name of the location (or branch) to be read. This is a required attribute.
ENTRY The name of the value to be. retrieved from the specified branch. is a required attribute. .
TYPE Specifies the type of data to return. Possible data types include String (for string values), DWordfor DWord values, and Keyfor registry. By default, this attribute is set to String..
VARIABLE:The name of the variable in which to store the returned value. This is a required attribute.
For instance, to return the value of the Regi steredOrgan~ zati on entry from the location used earlier when looking at AarON-‘ GetA11 the following tag could be used:
ENTRY·’ Regi steredOrgani zation’ .
This will store the value in the RegOrg variable, which can then be used in a template- for instance, to output the name of the organization:
<CFOUTPUT>Registered Organization: IRegOrg'</CFOuTPUT>