Written by Stephen McNamara 30/01/97.
What
is the registry?
What structure does the registry have?
What can be stored in the registry?
What data should programs store in the registry?
What will RWE be doing with the registry?
Example registry usage...
How can I get a pre-release version of the registry?
The registry is a data store area, much like the standard ENV:. It is used to store configuration information about the current machine and the software installed on it.
The idea for the registry came from Windows 95 on the PC - where the registry is a centralised data storage area for the system software. This area is used by programs to store their data and allows other programs to easily link in together to perform joint operations. It also allows other programs to find out what software is installed and what file formats are known to the system.
The registry enables programs to work together in an organised and useful way. It is especially useful for 'plug-in' programs (such as those supplied with SuperTED/REDMapEditor/REDShapeZ) since it allows these programs to find out information about their 'parent' application. It also allows them and their parent application to store configuration information about their current states.
Of course, the REDRegistry is not limited to Blitz Basic developers. C, E and 680x0 programmers can take advantage of the registry's features.
The registry will be supplied freely in the hope that people will take advantage of the functionality it provides and help establish it as a useful system utility. The following will be supplied:
| File | Information |
|---|---|
| registry.library | The actual Amiga system library that manages the registry. |
| Registry Editor | A WB3.0+ program that allows manual user editing of the registry. |
| registry.obj | A Blitz Basic 2 library object that can be used by Blitz programmers to access and modify the registry. |
| Include files | Include files will be supplied for C and assembly language programmers. Also autodoc and FD files will be supplied. |
| registry.txt | Further information and guidelines for use of the registry. |
The registry is made up of libraries and variables. A library is an object that contains sublibraries and variables. Each specific library is identified by a name and a path (much like a folder), e.g. Applications/REDApps/REDDebugger identifies the library that REDDebugger stores its information in. Variables are the actual data objects in the registry. A variable has a name and a path (analogous to a file) and a value. Any sort of data can be stored in the registry. The currently supported types of data are:
| Variable type | Information |
|---|---|
 String |
The value for the variable is a string. E.g. the variable Cmdline would have a value string that holds the command line that would need to be executed to run a program. |
 Data
block |
A block of byte data stored directly in the registry. E.g. the variable Prefs might hold a preferences file in a format known by the owner program. |
 Integer |
The value for the variable is an integer. E.g. the variable Version might have a value 2 to indicate version two of the owner program. |
 Boolean |
Boolean The value for the variable is one of True or False. |
All library and variable names are currently case sensitive.
A registry structure (as viewed with Registry Editor) might be:
The left half of the window shows the registry structure, where the indented items show libraries within parent libraries. The highlighed one is the currently selected library. The right handside half of the window shows the variables inside the library, the three fields are:
means
that the variable is a string.means
that the variable is a boolean value (True/False).means
that the variable is an integer value.means
that the variable holds byte data.the
value shown the the actual string value.the
value shown is either True or False.the
value shown is the integer value of the variable.the
value shown is how many bytes of data the variable holds.This is just a simple example - most of the information is missing but it does allow you to see an example heirarchy. All 'applications' in the system will keep their information in libraries which are themselves inside Applications. Groups such as ourselves who have a large number of applications to store information on would create sublibraries dedicated to their applications (in the example REDApps contains all information for Red When Excited applications). Thus if a user wanted to know what applications from a particular company were installed they would just have to analyse a certain library.
A program (or user) can store any information it requires inside the registry - there is no restriction placed on the type (accept that the format that the data is stored in should be the most appropriate, supported, type) of data stored.
Generally a program should store information about its current state so that other programs can interrogate the registry for information about it. It is also useful to store information that the user may want to interrogate directly (e.g. via Registry Editor) inside the registry (an example from a Red When Excited program would be REDDebugger, where the user can enter a list of programs (or command lines) to execute when the debugger first runs).
A good example of information that can be stored in the registry is a recently accessed files list (such as the one maintained by SuperTED). Also the last directories accessed by the user of your application could be held in the registry and retrieved by your application when it next runs.
Red When Excited will supply a list of a reasonable set of data every application in the registry should store. The list is likely to include items such as:
The standard list of data should thus allow any application to find out basic information about another. In this way operations can be automated easily.
We will be upgrading all of our programs to make use of the registry. E.g. configuration files (including files such as custom menu strips) will move into the registry. Thus the next updates for our Blitz Support Suite programs will require the registry to be installed. This upgrades will be released free to BSS owners via the archives page.
We will also be working on upgrades to the standard registry library (one extension that is planned is user defined data formats - which will allows external programs to interface with the registry to add functionality to it).
In the near future a project manager will be released by us, which will use Registry to keep track of project components (e.g. source code, shape and picture files) and the programs that manipulate them.
The REDMapEditor program has been upgraded to use the registry to store its configuration information inside it. Originally REDMapEditor stores its configuration inside it's icon's tooltypes - at the time of writing the program this was the best place to put them (since all the configuration options were stored in the form of <Name>=<Value>). Whilst, though, tooltypes are useful they only allow you to store string values with the variable names - if you want to store an integer you must first convert it to a string and store that.
Using the registry instead of tooltypes allows REDMapEditor to store its configuration in the best format. Thus integer or boolean values can be stored as such rather than having to convert them to into strings. Also, when the user looks at the configuration in Registry Editor the data is presented in a much more useful way than when using tooltypes - this is because the type of each variable is shown.
Because the registry makes it so easy to handle, REDMapEditor has been upgraded to support the custom menu items found in both REDDebugger and SuperTED (for those of you that do not know what these are, they are a user defined set of menu items that allow a user to run command lines when the items are selected by the user - SuperTED's online help system uses the custom menu to launch AmigaGuide with the correct document). The custom menus are stored directly in the registry.
Finally REDMapEditor's startup directory has been replaced by a registry library that allows any programs to be run when REDMapEditor starts up (the programs to be run do not have to be located in the Startup directory).
Red When Excited will be releasing a pre-release version of the registry library and its components to interested parties to allow others to make suggestions and recommendations. If you are interested in making your applications 'registry aware' then you should email us and ask for more information: