Did you know SD-WANs can improve network connectivity? Check out this webinar to learn how an SD-WAN simplified, one-click tool can help you migrate and manage data in the cloud.
Course Of The Month
4 days, 14 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
What is the Windows Registry?
Posted on 2004-10-13
Ok, here is the next in my series of dummy questions! In leymans terms, can anyone give a good explanation of the Windows registry? Like why it's there, what it does and how it works etc.
Usual thing with points: 350 points (at grade A) will go to best, all round description, in leymans terms. The rest will be shared out as appropriate to assisted answers.
Many thanks
Usual thing with points: 350 points (at grade A) will go to best, all round description, in leymans terms. The rest will be shared out as appropriate to assisted answers.
Many thanks
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
4
2-
2
- +8
16 Comments
Hi Jason210,
Look at those 2 questions earlier asked here:
http://www.experts-exchange.com/Operating_Systems/Win95_3x/Win95/Q_10032459.html
http://www.experts-exchange.com/Operating_Systems/Q_20596419.html
Cheers!
Look at those 2 questions earlier asked here:
http://www.experts-exchange.com/Operating_Systems/Win95_3x/Win95/Q_10032459.html
http://www.experts-exchange.com/Operating_Systems/Q_20596419.html
Cheers!
The registry is an information store, much like the windows file system.
The registry is intended to be used for storing very small pieces of information (such as user preferences for a particular application) rather than whole documents.
Some very old applications (plus unix apps like apache) store this kind of stuff in an INI file. Most modern windows apps use the registry instead of using INI files. A disadvantage of INI files, is that you need to tell the application where the INI file is, and that inforamation needs to be stored somewhere ... Chicken and egg. When applications use the registry, it always use the same location within the registry. Windows itself uses the registry for most of its internal settings.
There is a rough correspondence of terms used when referring to registry and file access. A drive is roughly equivalent to a registry hive, a folder is like a registry key, and a file is like a registry value.
Security can be set to limit access toregistry keys and values in much the same way that it can be done with folders and files.
In the windows NT registry, there are 4 hives already created with specific uses in mind
HKEY_Local_Machine - stores information about the local PC
HKEY_Current_User - stores information about the user currently logged in and their preferences.
HKEY_Classes_Root - provides a description of the file types being used and how to handle them (eg if user clicks on a file
ending with .XLS then load Excel)
HKEY_Users - information about other users on the system.
If you want to browse the registry, use Start / Run , and type regedit. Be careful changing stuff here, as the registry editor doesn't check to see if you're making changes that will cause errors.
Physically the registry exists in about 4 files on the file system somwhere. I can't remember what their called, but it doesn't matter becuase one would never manipulate the registry by altering the files directly. There are lots of ways of accessing the registry either manually or programatically. The easiest method to get used to first, is to use regedit.
The registry is intended to be used for storing very small pieces of information (such as user preferences for a particular application) rather than whole documents.
Some very old applications (plus unix apps like apache) store this kind of stuff in an INI file. Most modern windows apps use the registry instead of using INI files. A disadvantage of INI files, is that you need to tell the application where the INI file is, and that inforamation needs to be stored somewhere ... Chicken and egg. When applications use the registry, it always use the same location within the registry. Windows itself uses the registry for most of its internal settings.
There is a rough correspondence of terms used when referring to registry and file access. A drive is roughly equivalent to a registry hive, a folder is like a registry key, and a file is like a registry value.
Security can be set to limit access toregistry keys and values in much the same way that it can be done with folders and files.
In the windows NT registry, there are 4 hives already created with specific uses in mind
HKEY_Local_Machine - stores information about the local PC
HKEY_Current_User - stores information about the user currently logged in and their preferences.
HKEY_Classes_Root - provides a description of the file types being used and how to handle them (eg if user clicks on a file
ending with .XLS then load Excel)
HKEY_Users - information about other users on the system.
If you want to browse the registry, use Start / Run , and type regedit. Be careful changing stuff here, as the registry editor doesn't check to see if you're making changes that will cause errors.
Physically the registry exists in about 4 files on the file system somwhere. I can't remember what their called, but it doesn't matter becuase one would never manipulate the registry by altering the files directly. There are lots of ways of accessing the registry either manually or programatically. The easiest method to get used to first, is to use regedit.
visit this link or
http://www.winguides.com/registry/
Read below
Master the System Registry
by Dan Fergus
Reprinted with permission from Visual Basic Programmer's Journal, 4/98, Volume 8, Issue 4, Copyright 1998, Fawcette Technical Publications, Palo Alto, CA, USA. To subscribe, call 1-800-848-5523, 650-833-7100, visit www.vbpj.com, or visit The Development Exchange
Using an INI file to store your settings is for amateurs. Work around the limitations of SaveSetting and GetSetting and really access the registry.
Odds are you still use INI files for storing application-specific information. But to really make your apps a part of Windows 95, Windows NT or whatever comes next, you need to leave the INI file behind and start using the System Registry. I'd like to show you why the INI file has outlived its usefulness, the advantages of using the registry, and how to use and modify a class I built to do the dirty work of registry access.
Admittedly, Win.ini had its place. In the early days of Windows, all programs that needed to store custom information used the Win.ini file, and it worked fine. But Windows grew. Moreand more apps began to write to the Win.ini file. It became big, slow, and fragile. If anything corrupted your Win.ini, countless apps were affected.
Then Windows 3.0 appeared, with support for using API calls to write and read from private INI files. GetPrivateProfileString and WritePrivateProfileString soon became many a programmer's favorite API calls. This method beat sharing a single file, but it too began to have problems. Hundreds-sometimes thousands-of INI files started popping up all over folks' hard drives. These files had no security, and were restricted to a maximum size of 64K.
The basic INI file provided no mechanism for easily storing user-specific information. Worse yet, those who started using private INI files discovered that different apps could no longer share information.
A potential solution appeared with Windows 3.1: its Registration Database, implemented in a tree hierarchy and as a binary file. But the registration database didn't expose an API, because it was intended only for the use of the system to store OLE-specific information. That changed with Windows 95, whose System Registry can be accessed. In fact you get two sets of APIs to use for accessing registry values. The system registry also eliminates the 64K limit that existed in both the INI file and the Win 3.1 registry. It is still based on the tree hierarchy device of the Win 3.1 Registration Database, but it has been divided across multiple files.
The 16-bit versions of the API calls don't let you assign more than one value to a key, nor do they let you assign a name to the value you put in the registry. I mention the older versions in case you come across them in the documentation. You can spot them by the absence of the Ex on the end of the API call for the 32-bit version. You use the API calls RegSaveKey and RegSaveKeyEx to save a Name\Value pair to the registry. Don't use the older versions unless you need to read an unnamed value that had been written to by the older version.
Map your app
As the registry has grown, so has the amount and type of data being stored. Make no mistake about it, the registry contains a lot of information. For example, you'll find all the system Shell information stored in registry keys. And every creatable OLE class has an entry in the registry. Here I'll focus on how to store application-specific information though direct manipulation of the registry. If you want to delve into the registry's system and shell data, see Keith Pleas's article, "Hacking the Windows Registry" [VBPJ March 1996].
The complexity of the API calls used to access the registry led me to create my CRegistry class (see Table 1). Being an old C/C++ coder, I can handle most API calls; but the registry calls are some of the hardest to use and understand.
Table 1: PropertyDescription
RootSets the active Root Key
KeySets the active SubKey
AutoCreateWhen True, creates active key if nonexistent
ValueCountThe count of values found in a key
SubKeyCountThe count of subkeys in the active key
MethodDescription
CreateCreates a new key and makes it active
DeleteKeyDeletes the key and any subkeys
DeleteValueDeletes the Name\Value pair from a key
GetNameReturns the name of a Name\Value pair
GetValueReturns the value of a Name\Value pair
SetValueSets the value of a Name\Value pair
GetSubKeyReturns the name of a subkey in the active key
RefreshReloads the cached data from the active key
Table 1: The Hardest-Working Class in Registry Business. The CRegistry class was designed to have an "active" key. This active key is defined by the values in the Root and Key properties. The active key's values are held in the class and can be accessed using class methods. The default for AutoCreate is True and the default for Root is HKEY_LOCAL_MACHINE.
To view the registry, use RegEdit.exe or Regedt32.exe. Regedt32, the NT version, separates each root key into its own window. Both editors provide the same basic operations, so feel free to choose either.
As you begin to look into the registry you'll notice the similarity to the directory/folder structure of Windows (see Figure 1). The registry has top-level keys, often called root keys. Windows NT and Windows 95 have six root keys (see Table 2).
Each root can hold any number of values or keys. A key is a node of the registry hierarchy. Each key can have can have one or more named values and any number of subkeys.
Each value is associated with a name (unless you're still using the 16-bit API calls). These name/value pairs provide the values you set using the API. You can also create a new key under any Root Key or any other key, in the same way that you create folders in the Windows file structure.
When you create a name for the Name\Value pair, you can use spaces or backslashes but not wildcard characters. The value portion of the Name\Value pair has to be one of the 10 data types you can store in the registry (see Table 3). Only three are used with any regularity. In my sample code I only implement the REG_SZ type, a null-terminated string. REG_BINARY is restricted to 1 MB.
A key doesn't have to have any named values associated with it. However, every key does have a default value-always of the REG_SZ data type-that may or may not have a value assigned to it.
As I've said, VB does give you access to the registry through four calls: SaveSetting, GetSetting, GetAllSettings and DeleteSetting. All your entries are placed in the registry's 'HKEY_CURRENT_USER\Softwar
For example, just try to delete a key when it has subkeys. Using DeleteSetting generates a runtime error, Error 5 - Invalid Procedure Call. The workaround requires you to traverse the sub-key structure yourself and delete each bottom key, working your way up the to the parent that you wanted deleted in the first place. And you can store only string data using SaveSetting, so you lose the flexibility of data stores that the registry provides.
Access to other parts of the registry is what makes using the registry so useful. In particular the SOFTWARE subkey from HKEY_LOCAL_MACHINE is used by just about every application on the system. If your program is well behaved, it will create a company key under SOFTWARE and store your application-specific information there. If your group produces more than one app, each should have its own subkey under your group key.
Table 2: HKEY_CLASSES_ROOTUsed by Windows for filename-extension associations and OLE application information
HKEY_CURRENT_USERA subkey of HKEY_USERS that defines the profile for the user who is currently logged on
HKEY_LOCAL_MACHINEConfigur
HKEY_USERSStores user profiles on the local machine
HKEY_CURRENT_CONFIGContain
HKEY_DYN_DATAContains performance data
Table 2: Get to the Root of the Matter. There are six root keys in your operating system, each of which has its own purpose. Knowing what that purpose is will help you use the system registry.
Table 3
REG_SZA null-terminated string
REG_BINARYData stored in a binary format of any form
REG_DWORDA long value
REG_DWORD_BIG_ENDIANA long (32-bit) number with the low-order byte being the most significant
REG_EXPAND_SZA string containing unexpanded refernces to environment variables
REG_MULTI_SZA string containing several strings, separated by single null characters and terminated by two null characters
REG_NONENo data type defined
REG_RESOURCE_LISTA device-driver resource list
Table 3: Data for the Asking. Several types of data can be stored in the registry. The first three types are used most often. Only REG_SZ data types are used in the article code.
Use the registry API set with care
As a developer, you use the registry to store application- and user-specific information. Where were the windows when the application was closed? Do users want tooltips? Do they want large toolbar buttons or small? Any kind of information that should carry over from previous executions can be put into the registry.
It was tough to maintain information in an INI file that related to different versions. Yet in the hierarchical structure of the registry you can just add a new key for a new version. Then you can easily support multiple versions of your app.
Windows stores software and hardware information in the registry. You may not want to write into these keys-but you may want to know what sort of hardware is available, and you can get much of that information from the registry.
Figure 1: The View from RegEdit. To view the registry, use RegEdit.exe or Regedt32.exe (the NT version). Both editors provide the same basic operations. Note the similarity to the directory/folder structure of Windows. The registry has top-level keys, often called root keys. Windows NT and Windows 95 have six root keys. Each root can hold any number of values or keys. A key is a node of the registry hierarchy. Each key can have one or more named values and any number of subkeys.
To get data from the registry, first open a key. Once it's open, you can get data from any value in that key. However, when you open a registry key you consume system resources. Be sure to close every key you open. Pseudocode for this simple operation looks appropriately simple:
OpenKey( key name )
GetValue
CloseKey
You should be so lucky. The real thing is complex and loaded with declare statements (see Listing 1). Use the RegOpenKeyEx API call to open a key, RegQueryValueEx to get a value, and RegCloseKey to close the key.
Now I'm going to show you how to dive deeply into the registry. I'm also going to warn you that GPFs in abundance await the unwary. Writing the right thing to the wrong place (or the wrong thing to the right place) can not only lock up your system, it may even kill the OS. Be careful what you do, and back up your registry before you start poking around.
Still there? Good. But don't say I didn't warn you.
That said, I will provide something of a net for your high wire act: all my samples use a new key in HKEY_LOCAL_MACHINE: SOFTWARE\DFergus. It should be a pretty safe key for you-one where you can freely delete and add values without affecting other programs on your system.
Listing 1 (VB5)
Declare Function RegOpenKeyEx Lib "advapi32" Alias _
"RegOpenKeyExA" (ByVal hKey As Long, _
ByVal lpSubKey As String, _
ByVal ulOptions As Long, ByVal samDesired As Long, _
phkResult As Long) As Long
Private Declare Function RegQueryValueEx Lib "advapi32" _
Alias "RegQueryValueExA" (ByVal hKey As Long, _
ByVal lpValueName As String, _
ByVal lpReserved As Long, ByRef lpType As Long, _
ByVal szData As String, _
ByRef lpcbData As Long) As Long
Private Declare Function RegCloseKey Lib "advapi32" _
(ByVal hKey As Long) As Long
Listing 1: Opening Up the Register. To get data from the registry, first open a key. Once it's open you can get data from any value in that key. However, when you open a registry key, you consume system resources. Be sure to close any and every key you open. As you can see, going beyond VB's easy but limited calls takes some doing. But in my experience it's worth it for the added flexibility. Use the RegOpenKeyEx API call to open a key, RegQueryValueEx to get a value, and RegCloseKey to close the key.
I designed the class to hide the 'open, read, close' architecture of the registry and expose only methods resembling the SaveSetting and GetSetting statements. You define an "active" key by setting the Key property. This causes the class to open, read, and close the key. You then get values from the cached data. Originally I designed the class to open the key and keep it open until the class was destroyed or the user closed it through a Close method. But after much angst (and discussion with colleagues), I thought better of keeping a system resource open for an extended period. Internally the Name\Value pairs are kept in a multiple-dimension array. My class only reads and writes strings, ignoring the other data types that can be stored in the registry.
Windows NT has a lot to do with security. Windows 95 does not. The CRegistry class uses system default security privileges. You'll see several API calls that use security attributes type definitions. I didn't design an advanced implementation of this class that would handle the NT security concerns, but you're welcome to do so.
Turn key, unlock class
As I mentioned earlier, you'll write all your sample Name\Value pairs into the SOFTWARE\DFergus subkey of HKEY_LOCAL_MACHINE. Create this new key using the Create method:
Dim cReg As New CRegistry
cReg.Root = RootValues.HkeyLocalMachin
cReg.Key = "SOFTWARE"
cReg.Create("DFergus")
bRet = cReg.SetValue("Version", "5.00.11")
Set the desired root key and subkey using the properties Root and Key. The default for Root is HKEY_LOCAL_MACHINE, so you could skip the first line of my sample. Key is the subkey of the root key. No "\\" precedes the subkey name. Often programmers try to use the UNC naming style in their registry work, but trust me-you won't get far. Because you can specify multiple subkeys in the value of this property, you might just as well have entered "SOFTWARE\Microsoft\Crypto
Once you've created the desired key, you'll put in some values. The class's SetValue method takes a name and value, then writes the information into the active key. Or you can use the optional parameters of the Create method to perform both actions in one call:
bRet = cReg.Create("DFergus", _
"Version", "5.00.11")
If you try to create a subkey that already exists, the class opens that subkey and reads the values. But if you try to open a nonexistent one, you might run into trouble. The underlying registry APIs provide two methods of opening a key, RegOpenKeyEx and RegCreateKeyEx:
RegOpenKeyEx(m_varRoot, m_varKey, _
0, lAccess, m_lOpenKey)
RegCreateKeyEx(m_varRoot, m_varKey, _
0, vbNull, REG_OPTION_NON_VOLATILE, _
KEY_ALL_ACCESS, sa, m_lOpenKey, _
lpdwDisposition)
The CRegistry class has a property called AutoCreate, set to True by default. Whenever a key is opened, AutoCreate tells the class to use RegCreateKeyEx instead of RegOpenKeyEx. Consequently any subkey you specify gets created if it doesn't exist. Using the class with this property set to False raises an error when you try to set Key to a nonexistent key.
Some differences between WinNT and Win95 affect what you do next. If you try to open the same key multiple times under Win95 without closing the previous handle(s), the same handle returns each time. Win95 keeps a reference count of how many times the key was opened. If you close the handle only once, you leave the key open and tie up system resources. On the other hand, WinNT returns a different handle each time you open a key. If you then close each handle, the key gets closed and all is well.
Also, Win95 doesn't care what access mask is passed to RegOpenKeyEx. Passing KEY_READ still lets you write to the opened key. But WinNT forces you to pass the correct access or it won't let you perform the operation. I learned this when I did my initial development on the road with Win95, then came back to the office and my WinNT machine. Suddenly the class I'd been using for weeks stopped working. Needless to say, be sure to test your code on both platforms. And to manage these operating system differences, the private function OpenKey method of CRegistry performs a Boolean OR operation on the KEY_READ and KEY_WRITE:
Private Function OpenKey( _
Optional lAccess As Long = KEY_READ _
Or KEY_WRITE) As Boolean
Fortunately, using the CRegistry class hides this type of detail and keeps you from tripping over Win95/WinNT incongruities, but it's still interesting to note the things you run into as you go about your daily chores.
Get data back
Now that you can create a key and place values in it, you'll have no trouble getting data out of the registry. You had added the values to the key, so you know what you're looking for. Just use the GetValue method directly:
Dim cReg As New CRegistry
Dim sValue as String
cReg.Root = RootValues.RegLocalMachine
cReg.Key = "SOFTWARE\DFergus"
sValue = cReg.GetValue("Version")
If you were just browsing through the registry, you wouldn't know what values were in a key. In this case you'd use the ValueCount property to iterate through the entries of the key and get both the name and value of each pair:
Dim cReg As New CRegistry
Dim sValue as String
Dim sName as String
cReg.Root = RootValues.RegLocalMachine
cReg.Key = "HARDWARE\Description\Syst
For i = 0 to cReg.ValueCount - 1
sName = cReg.GetName(i)
sValue = cReg.GetValue(i)
Next I
Passing the parameter as a Variant allows the class to effectively overload the method, allowing you to access the data either by index or name (for the code for GetValue and GetName, see Listing 2).
As I've said, each key has a default value. To access the default value using the CRegistry class, you use the same GetValue and SetValue pair you use when you access a named value. However, you leave the vRequest field blank:
cReg.key = _
"SOFTWARE\DFergus\Applicat
CurrentVersion"
tmp = cReg.GetValue("")
cReg.key = "SOFTWARE\ _
DFergus\Application\Versio
tmp = cReg.GetValue("ReportError
Last stop on this excursion through the class methods is DeleteKey. This method takes care of another difference between Windows 95 and Windows NT, along with the DeleteSetting runtime error problem I mentioned earlier. CRegistry uses the API RegDeleteKey. Under Win95 this key deletes not only the key specified but any associated subkeys as well. In contrast, the WinNT version of RegDeleteKey deletes only the particular key specified and leaves subkeys alone. So DeleteKey uses a recursive call to make the same method work for either operating system (see Listing 3).
You won't have trouble with the public members of the CRegistry class. To get a feel for what's happening, look into the private method that drives the class, GetKeyInfo. This method performs all direct access to registry data. The first part of the function checks the AutoCreate flag and opens the key (see Listing 4). The call to RegQueryInfoKey gets information about the requested key. This is done to get the count of keys and values, along with the maximum size of the buffers you'll need as you iterate through the key getting data. It would have been just as easy-but not as foolproof-to define maximum sizes for the buffers.
Here we go loop do loop
Once these values are obtained, the function goes into a Do Loop until it runs out of values to query. The first action inside the loop determines the value's data type. A call to RegEnumValue is made, with all nonessential values set to a null value. The open key is specified, along with the desired index. You're looking for the IType value that reveals what type of data is stored in the value. Possible values for the data types are defined in the Enum RegTypes. Once you ascertain that you have a string data value, read the data and store it into your array. Reset the strings and length variables before each call to RegEnumValueStr. Otherwise you may get an error back from the API call, stating that more data is available. This error results from passing a string that lacks the space needed to hold the data passing back.
Listing 2 (VB5)
Public Function GetName(ByVal iRequest As Integer) _
As String
If iRequest >= LBound(m_aStringData, 2) _
And iRequest <= UBound(m_aStringData, 2) Then
GetName = m_aStringData(0, CInt(iRequest))
Else
GetName = ""
End If
End Function
Public Function GetValue(ByVal vRequest As Variant) _
As String
On Error GoTo GetValue_Error
If VarType(vRequest) = vbInteger Then
GetValue = m_aStringData(1, CInt(vRequest))
Else
Dim i As Integer
i = LBound(m_aStringData, 2)
Do
If StrComp(m_aStringData(0, i), vRequest) = 0 Then
GetValue = m_aStringData(1, i)
Exit Do
End If
i = i + 1
Loop While i <= UBound(m_aStringData, 2)
End If
GetValue_Exit:
Exit Function
GetValue_Error:
MsgBox Err.Description, , Err.Source
GoTo GetValue_Exit
End Function
Listing 2: A Variant Paramter. Using a Variant parameter lets the class use both indexes or names when retrieving values from a key. GetName is more straightforward in that you always get the name by an index.
If you've browsed the API calls, you may wonder where I got RegEnumValueStr. Actually it's an aliased call that causes the data to be passed back into a string variable. Another quirk of VB arose while I was testing the code. I'd defined one of the parameters incorrectly. The test app ran fine inside the IDE, but when I compiled the app and ran it I got an access error and the program terminated. Now I've often seen VB totally disappear when I've improperly used an API call from within the IDE. When I'm using APIs I always save my work before I run the app. But this is the first time I've found VB running the app normally as p-code, then crashing after compiling.
I use the last loop in GetKeyInfo to gather the subkey names within the active key. Using the RegEnumKeyEx call, each name is retrieved and added to the member variable array m_aSubKeyData. Once all the data is stored in internal, private string arrays, the public members of the class can access it.
Listing 3 (VB5)
Private Function DeleteKeyAdv(sKey As String) As Long
Dim lIndex As Long
Dim lpftLastWriteTime As FILETIME
Dim lRet As Long
Dim lRet1 As Long
Dim lValuename As Long
Dim strValueName As String
Dim lOpenKey As Long
Dim sPrevKey As String
lRet1 = -1
sPrevKey = m_varKey
If ERROR_SUCCESS = RegOpenKeyEx(m_varRoot, _
m_varKey & "\" & sKey, 0, KEY_ALL_ACCESS, _
lOpenKey) Then
lIndex = 0
Do
lValuename = 255
strValueName = String$(lValuename, 0)
lRet = RegEnumKeyEx(lOpenKey, lIndex, _
strValueName, lValuename, 0&, 0&, 0&, _
lpftLastWriteTime)
If lRet = ERROR_NO_MORE_ITEMS Then
RegCloseKey lOpenKey
If ERROR_SUCCESS = RegOpenKeyEx(m_varRoot, _
m_varKey, 0, KEY_ALL_ACCESS, lOpenKey) Then
lRet1 = RegDeleteKey(lOpenKey, sKey)
End If
Else
Dim s As String
m_varKey = m_varKey & "\" & sKey
s = Left$(strValueName, lValuename)
lRet1 = DeleteKeyAdv(s)
m_varKey = sPrevKey
End If
Loop While lRet <> ERROR_NO_MORE_ITEMS
RegCloseKey lOpenKey
End If
DeleteKeyAdv = lRet1
End Function
Listing 3: A Recursive Call. Using a recursive call into DeleteKeyAdv, we can make the DeleteKey method work on Windows 95 or Windows NT.
You may feel some concern over the caching of the data. Well, I've provided a method to update the cached data. Calling the public member Refresh causes the class to go through the work detailed above, thereby getting new data from the registry. The simplicity of the public class members can make your transition from INI files to open use of the registry a snap.
Download the code for this article here
--------------------------
Naeem Shehzad Ghuman
http://www.winguides.com/registry/
Read below
Master the System Registry
by Dan Fergus
Reprinted with permission from Visual Basic Programmer's Journal, 4/98, Volume 8, Issue 4, Copyright 1998, Fawcette Technical Publications, Palo Alto, CA, USA. To subscribe, call 1-800-848-5523, 650-833-7100, visit www.vbpj.com, or visit The Development Exchange
Using an INI file to store your settings is for amateurs. Work around the limitations of SaveSetting and GetSetting and really access the registry.
Odds are you still use INI files for storing application-specific information. But to really make your apps a part of Windows 95, Windows NT or whatever comes next, you need to leave the INI file behind and start using the System Registry. I'd like to show you why the INI file has outlived its usefulness, the advantages of using the registry, and how to use and modify a class I built to do the dirty work of registry access.
Admittedly, Win.ini had its place. In the early days of Windows, all programs that needed to store custom information used the Win.ini file, and it worked fine. But Windows grew. Moreand more apps began to write to the Win.ini file. It became big, slow, and fragile. If anything corrupted your Win.ini, countless apps were affected.
Then Windows 3.0 appeared, with support for using API calls to write and read from private INI files. GetPrivateProfileString and WritePrivateProfileString soon became many a programmer's favorite API calls. This method beat sharing a single file, but it too began to have problems. Hundreds-sometimes thousands-of INI files started popping up all over folks' hard drives. These files had no security, and were restricted to a maximum size of 64K.
The basic INI file provided no mechanism for easily storing user-specific information. Worse yet, those who started using private INI files discovered that different apps could no longer share information.
A potential solution appeared with Windows 3.1: its Registration Database, implemented in a tree hierarchy and as a binary file. But the registration database didn't expose an API, because it was intended only for the use of the system to store OLE-specific information. That changed with Windows 95, whose System Registry can be accessed. In fact you get two sets of APIs to use for accessing registry values. The system registry also eliminates the 64K limit that existed in both the INI file and the Win 3.1 registry. It is still based on the tree hierarchy device of the Win 3.1 Registration Database, but it has been divided across multiple files.
The 16-bit versions of the API calls don't let you assign more than one value to a key, nor do they let you assign a name to the value you put in the registry. I mention the older versions in case you come across them in the documentation. You can spot them by the absence of the Ex on the end of the API call for the 32-bit version. You use the API calls RegSaveKey and RegSaveKeyEx to save a Name\Value pair to the registry. Don't use the older versions unless you need to read an unnamed value that had been written to by the older version.
Map your app
As the registry has grown, so has the amount and type of data being stored. Make no mistake about it, the registry contains a lot of information. For example, you'll find all the system Shell information stored in registry keys. And every creatable OLE class has an entry in the registry. Here I'll focus on how to store application-specific information though direct manipulation of the registry. If you want to delve into the registry's system and shell data, see Keith Pleas's article, "Hacking the Windows Registry" [VBPJ March 1996].
The complexity of the API calls used to access the registry led me to create my CRegistry class (see Table 1). Being an old C/C++ coder, I can handle most API calls; but the registry calls are some of the hardest to use and understand.
Table 1: PropertyDescription
RootSets the active Root Key
KeySets the active SubKey
AutoCreateWhen True, creates active key if nonexistent
ValueCountThe count of values found in a key
SubKeyCountThe count of subkeys in the active key
MethodDescription
CreateCreates a new key and makes it active
DeleteKeyDeletes the key and any subkeys
DeleteValueDeletes the Name\Value pair from a key
GetNameReturns the name of a Name\Value pair
GetValueReturns the value of a Name\Value pair
SetValueSets the value of a Name\Value pair
GetSubKeyReturns the name of a subkey in the active key
RefreshReloads the cached data from the active key
Table 1: The Hardest-Working Class in Registry Business. The CRegistry class was designed to have an "active" key. This active key is defined by the values in the Root and Key properties. The active key's values are held in the class and can be accessed using class methods. The default for AutoCreate is True and the default for Root is HKEY_LOCAL_MACHINE.
To view the registry, use RegEdit.exe or Regedt32.exe. Regedt32, the NT version, separates each root key into its own window. Both editors provide the same basic operations, so feel free to choose either.
As you begin to look into the registry you'll notice the similarity to the directory/folder structure of Windows (see Figure 1). The registry has top-level keys, often called root keys. Windows NT and Windows 95 have six root keys (see Table 2).
Each root can hold any number of values or keys. A key is a node of the registry hierarchy. Each key can have can have one or more named values and any number of subkeys.
Each value is associated with a name (unless you're still using the 16-bit API calls). These name/value pairs provide the values you set using the API. You can also create a new key under any Root Key or any other key, in the same way that you create folders in the Windows file structure.
When you create a name for the Name\Value pair, you can use spaces or backslashes but not wildcard characters. The value portion of the Name\Value pair has to be one of the 10 data types you can store in the registry (see Table 3). Only three are used with any regularity. In my sample code I only implement the REG_SZ type, a null-terminated string. REG_BINARY is restricted to 1 MB.
A key doesn't have to have any named values associated with it. However, every key does have a default value-always of the REG_SZ data type-that may or may not have a value assigned to it.
As I've said, VB does give you access to the registry through four calls: SaveSetting, GetSetting, GetAllSettings and DeleteSetting. All your entries are placed in the registry's 'HKEY_CURRENT_USER\Softwar
For example, just try to delete a key when it has subkeys. Using DeleteSetting generates a runtime error, Error 5 - Invalid Procedure Call. The workaround requires you to traverse the sub-key structure yourself and delete each bottom key, working your way up the to the parent that you wanted deleted in the first place. And you can store only string data using SaveSetting, so you lose the flexibility of data stores that the registry provides.
Access to other parts of the registry is what makes using the registry so useful. In particular the SOFTWARE subkey from HKEY_LOCAL_MACHINE is used by just about every application on the system. If your program is well behaved, it will create a company key under SOFTWARE and store your application-specific information there. If your group produces more than one app, each should have its own subkey under your group key.
Table 2: HKEY_CLASSES_ROOTUsed by Windows for filename-extension associations and OLE application information
HKEY_CURRENT_USERA subkey of HKEY_USERS that defines the profile for the user who is currently logged on
HKEY_LOCAL_MACHINEConfigur
HKEY_USERSStores user profiles on the local machine
HKEY_CURRENT_CONFIGContain
HKEY_DYN_DATAContains performance data
Table 2: Get to the Root of the Matter. There are six root keys in your operating system, each of which has its own purpose. Knowing what that purpose is will help you use the system registry.
Table 3
REG_SZA null-terminated string
REG_BINARYData stored in a binary format of any form
REG_DWORDA long value
REG_DWORD_BIG_ENDIANA long (32-bit) number with the low-order byte being the most significant
REG_EXPAND_SZA string containing unexpanded refernces to environment variables
REG_MULTI_SZA string containing several strings, separated by single null characters and terminated by two null characters
REG_NONENo data type defined
REG_RESOURCE_LISTA device-driver resource list
Table 3: Data for the Asking. Several types of data can be stored in the registry. The first three types are used most often. Only REG_SZ data types are used in the article code.
Use the registry API set with care
As a developer, you use the registry to store application- and user-specific information. Where were the windows when the application was closed? Do users want tooltips? Do they want large toolbar buttons or small? Any kind of information that should carry over from previous executions can be put into the registry.
It was tough to maintain information in an INI file that related to different versions. Yet in the hierarchical structure of the registry you can just add a new key for a new version. Then you can easily support multiple versions of your app.
Windows stores software and hardware information in the registry. You may not want to write into these keys-but you may want to know what sort of hardware is available, and you can get much of that information from the registry.
Figure 1: The View from RegEdit. To view the registry, use RegEdit.exe or Regedt32.exe (the NT version). Both editors provide the same basic operations. Note the similarity to the directory/folder structure of Windows. The registry has top-level keys, often called root keys. Windows NT and Windows 95 have six root keys. Each root can hold any number of values or keys. A key is a node of the registry hierarchy. Each key can have one or more named values and any number of subkeys.
To get data from the registry, first open a key. Once it's open, you can get data from any value in that key. However, when you open a registry key you consume system resources. Be sure to close every key you open. Pseudocode for this simple operation looks appropriately simple:
OpenKey( key name )
GetValue
CloseKey
You should be so lucky. The real thing is complex and loaded with declare statements (see Listing 1). Use the RegOpenKeyEx API call to open a key, RegQueryValueEx to get a value, and RegCloseKey to close the key.
Now I'm going to show you how to dive deeply into the registry. I'm also going to warn you that GPFs in abundance await the unwary. Writing the right thing to the wrong place (or the wrong thing to the right place) can not only lock up your system, it may even kill the OS. Be careful what you do, and back up your registry before you start poking around.
Still there? Good. But don't say I didn't warn you.
That said, I will provide something of a net for your high wire act: all my samples use a new key in HKEY_LOCAL_MACHINE: SOFTWARE\DFergus. It should be a pretty safe key for you-one where you can freely delete and add values without affecting other programs on your system.
Listing 1 (VB5)
Declare Function RegOpenKeyEx Lib "advapi32" Alias _
"RegOpenKeyExA" (ByVal hKey As Long, _
ByVal lpSubKey As String, _
ByVal ulOptions As Long, ByVal samDesired As Long, _
phkResult As Long) As Long
Private Declare Function RegQueryValueEx Lib "advapi32" _
Alias "RegQueryValueExA" (ByVal hKey As Long, _
ByVal lpValueName As String, _
ByVal lpReserved As Long, ByRef lpType As Long, _
ByVal szData As String, _
ByRef lpcbData As Long) As Long
Private Declare Function RegCloseKey Lib "advapi32" _
(ByVal hKey As Long) As Long
Listing 1: Opening Up the Register. To get data from the registry, first open a key. Once it's open you can get data from any value in that key. However, when you open a registry key, you consume system resources. Be sure to close any and every key you open. As you can see, going beyond VB's easy but limited calls takes some doing. But in my experience it's worth it for the added flexibility. Use the RegOpenKeyEx API call to open a key, RegQueryValueEx to get a value, and RegCloseKey to close the key.
I designed the class to hide the 'open, read, close' architecture of the registry and expose only methods resembling the SaveSetting and GetSetting statements. You define an "active" key by setting the Key property. This causes the class to open, read, and close the key. You then get values from the cached data. Originally I designed the class to open the key and keep it open until the class was destroyed or the user closed it through a Close method. But after much angst (and discussion with colleagues), I thought better of keeping a system resource open for an extended period. Internally the Name\Value pairs are kept in a multiple-dimension array. My class only reads and writes strings, ignoring the other data types that can be stored in the registry.
Windows NT has a lot to do with security. Windows 95 does not. The CRegistry class uses system default security privileges. You'll see several API calls that use security attributes type definitions. I didn't design an advanced implementation of this class that would handle the NT security concerns, but you're welcome to do so.
Turn key, unlock class
As I mentioned earlier, you'll write all your sample Name\Value pairs into the SOFTWARE\DFergus subkey of HKEY_LOCAL_MACHINE. Create this new key using the Create method:
Dim cReg As New CRegistry
cReg.Root = RootValues.HkeyLocalMachin
cReg.Key = "SOFTWARE"
cReg.Create("DFergus")
bRet = cReg.SetValue("Version", "5.00.11")
Set the desired root key and subkey using the properties Root and Key. The default for Root is HKEY_LOCAL_MACHINE, so you could skip the first line of my sample. Key is the subkey of the root key. No "\\" precedes the subkey name. Often programmers try to use the UNC naming style in their registry work, but trust me-you won't get far. Because you can specify multiple subkeys in the value of this property, you might just as well have entered "SOFTWARE\Microsoft\Crypto
Once you've created the desired key, you'll put in some values. The class's SetValue method takes a name and value, then writes the information into the active key. Or you can use the optional parameters of the Create method to perform both actions in one call:
bRet = cReg.Create("DFergus", _
"Version", "5.00.11")
If you try to create a subkey that already exists, the class opens that subkey and reads the values. But if you try to open a nonexistent one, you might run into trouble. The underlying registry APIs provide two methods of opening a key, RegOpenKeyEx and RegCreateKeyEx:
RegOpenKeyEx(m_varRoot, m_varKey, _
0, lAccess, m_lOpenKey)
RegCreateKeyEx(m_varRoot, m_varKey, _
0, vbNull, REG_OPTION_NON_VOLATILE, _
KEY_ALL_ACCESS, sa, m_lOpenKey, _
lpdwDisposition)
The CRegistry class has a property called AutoCreate, set to True by default. Whenever a key is opened, AutoCreate tells the class to use RegCreateKeyEx instead of RegOpenKeyEx. Consequently any subkey you specify gets created if it doesn't exist. Using the class with this property set to False raises an error when you try to set Key to a nonexistent key.
Some differences between WinNT and Win95 affect what you do next. If you try to open the same key multiple times under Win95 without closing the previous handle(s), the same handle returns each time. Win95 keeps a reference count of how many times the key was opened. If you close the handle only once, you leave the key open and tie up system resources. On the other hand, WinNT returns a different handle each time you open a key. If you then close each handle, the key gets closed and all is well.
Also, Win95 doesn't care what access mask is passed to RegOpenKeyEx. Passing KEY_READ still lets you write to the opened key. But WinNT forces you to pass the correct access or it won't let you perform the operation. I learned this when I did my initial development on the road with Win95, then came back to the office and my WinNT machine. Suddenly the class I'd been using for weeks stopped working. Needless to say, be sure to test your code on both platforms. And to manage these operating system differences, the private function OpenKey method of CRegistry performs a Boolean OR operation on the KEY_READ and KEY_WRITE:
Private Function OpenKey( _
Optional lAccess As Long = KEY_READ _
Or KEY_WRITE) As Boolean
Fortunately, using the CRegistry class hides this type of detail and keeps you from tripping over Win95/WinNT incongruities, but it's still interesting to note the things you run into as you go about your daily chores.
Get data back
Now that you can create a key and place values in it, you'll have no trouble getting data out of the registry. You had added the values to the key, so you know what you're looking for. Just use the GetValue method directly:
Dim cReg As New CRegistry
Dim sValue as String
cReg.Root = RootValues.RegLocalMachine
cReg.Key = "SOFTWARE\DFergus"
sValue = cReg.GetValue("Version")
If you were just browsing through the registry, you wouldn't know what values were in a key. In this case you'd use the ValueCount property to iterate through the entries of the key and get both the name and value of each pair:
Dim cReg As New CRegistry
Dim sValue as String
Dim sName as String
cReg.Root = RootValues.RegLocalMachine
cReg.Key = "HARDWARE\Description\Syst
For i = 0 to cReg.ValueCount - 1
sName = cReg.GetName(i)
sValue = cReg.GetValue(i)
Next I
Passing the parameter as a Variant allows the class to effectively overload the method, allowing you to access the data either by index or name (for the code for GetValue and GetName, see Listing 2).
As I've said, each key has a default value. To access the default value using the CRegistry class, you use the same GetValue and SetValue pair you use when you access a named value. However, you leave the vRequest field blank:
cReg.key = _
"SOFTWARE\DFergus\Applicat
CurrentVersion"
tmp = cReg.GetValue("")
cReg.key = "SOFTWARE\ _
DFergus\Application\Versio
tmp = cReg.GetValue("ReportError
Last stop on this excursion through the class methods is DeleteKey. This method takes care of another difference between Windows 95 and Windows NT, along with the DeleteSetting runtime error problem I mentioned earlier. CRegistry uses the API RegDeleteKey. Under Win95 this key deletes not only the key specified but any associated subkeys as well. In contrast, the WinNT version of RegDeleteKey deletes only the particular key specified and leaves subkeys alone. So DeleteKey uses a recursive call to make the same method work for either operating system (see Listing 3).
You won't have trouble with the public members of the CRegistry class. To get a feel for what's happening, look into the private method that drives the class, GetKeyInfo. This method performs all direct access to registry data. The first part of the function checks the AutoCreate flag and opens the key (see Listing 4). The call to RegQueryInfoKey gets information about the requested key. This is done to get the count of keys and values, along with the maximum size of the buffers you'll need as you iterate through the key getting data. It would have been just as easy-but not as foolproof-to define maximum sizes for the buffers.
Here we go loop do loop
Once these values are obtained, the function goes into a Do Loop until it runs out of values to query. The first action inside the loop determines the value's data type. A call to RegEnumValue is made, with all nonessential values set to a null value. The open key is specified, along with the desired index. You're looking for the IType value that reveals what type of data is stored in the value. Possible values for the data types are defined in the Enum RegTypes. Once you ascertain that you have a string data value, read the data and store it into your array. Reset the strings and length variables before each call to RegEnumValueStr. Otherwise you may get an error back from the API call, stating that more data is available. This error results from passing a string that lacks the space needed to hold the data passing back.
Listing 2 (VB5)
Public Function GetName(ByVal iRequest As Integer) _
As String
If iRequest >= LBound(m_aStringData, 2) _
And iRequest <= UBound(m_aStringData, 2) Then
GetName = m_aStringData(0, CInt(iRequest))
Else
GetName = ""
End If
End Function
Public Function GetValue(ByVal vRequest As Variant) _
As String
On Error GoTo GetValue_Error
If VarType(vRequest) = vbInteger Then
GetValue = m_aStringData(1, CInt(vRequest))
Else
Dim i As Integer
i = LBound(m_aStringData, 2)
Do
If StrComp(m_aStringData(0, i), vRequest) = 0 Then
GetValue = m_aStringData(1, i)
Exit Do
End If
i = i + 1
Loop While i <= UBound(m_aStringData, 2)
End If
GetValue_Exit:
Exit Function
GetValue_Error:
MsgBox Err.Description, , Err.Source
GoTo GetValue_Exit
End Function
Listing 2: A Variant Paramter. Using a Variant parameter lets the class use both indexes or names when retrieving values from a key. GetName is more straightforward in that you always get the name by an index.
If you've browsed the API calls, you may wonder where I got RegEnumValueStr. Actually it's an aliased call that causes the data to be passed back into a string variable. Another quirk of VB arose while I was testing the code. I'd defined one of the parameters incorrectly. The test app ran fine inside the IDE, but when I compiled the app and ran it I got an access error and the program terminated. Now I've often seen VB totally disappear when I've improperly used an API call from within the IDE. When I'm using APIs I always save my work before I run the app. But this is the first time I've found VB running the app normally as p-code, then crashing after compiling.
I use the last loop in GetKeyInfo to gather the subkey names within the active key. Using the RegEnumKeyEx call, each name is retrieved and added to the member variable array m_aSubKeyData. Once all the data is stored in internal, private string arrays, the public members of the class can access it.
Listing 3 (VB5)
Private Function DeleteKeyAdv(sKey As String) As Long
Dim lIndex As Long
Dim lpftLastWriteTime As FILETIME
Dim lRet As Long
Dim lRet1 As Long
Dim lValuename As Long
Dim strValueName As String
Dim lOpenKey As Long
Dim sPrevKey As String
lRet1 = -1
sPrevKey = m_varKey
If ERROR_SUCCESS = RegOpenKeyEx(m_varRoot, _
m_varKey & "\" & sKey, 0, KEY_ALL_ACCESS, _
lOpenKey) Then
lIndex = 0
Do
lValuename = 255
strValueName = String$(lValuename, 0)
lRet = RegEnumKeyEx(lOpenKey, lIndex, _
strValueName, lValuename, 0&, 0&, 0&, _
lpftLastWriteTime)
If lRet = ERROR_NO_MORE_ITEMS Then
RegCloseKey lOpenKey
If ERROR_SUCCESS = RegOpenKeyEx(m_varRoot, _
m_varKey, 0, KEY_ALL_ACCESS, lOpenKey) Then
lRet1 = RegDeleteKey(lOpenKey, sKey)
End If
Else
Dim s As String
m_varKey = m_varKey & "\" & sKey
s = Left$(strValueName, lValuename)
lRet1 = DeleteKeyAdv(s)
m_varKey = sPrevKey
End If
Loop While lRet <> ERROR_NO_MORE_ITEMS
RegCloseKey lOpenKey
End If
DeleteKeyAdv = lRet1
End Function
Listing 3: A Recursive Call. Using a recursive call into DeleteKeyAdv, we can make the DeleteKey method work on Windows 95 or Windows NT.
You may feel some concern over the caching of the data. Well, I've provided a method to update the cached data. Calling the public member Refresh causes the class to go through the work detailed above, thereby getting new data from the registry. The simplicity of the public class members can make your transition from INI files to open use of the registry a snap.
Download the code for this article here
--------------------------
Naeem Shehzad Ghuman
Hi, the following is the simplest description of Windows Registry:
A central hierarchical database used in Microsoft Windows 9x, Windows CE, Windows NT, and Windows 2000 used to store information necessary to configure the system for one or more users, applications and hardware devices.
The Registry contains information that Windows continually references during operation, such as profiles for each user, the applications installed on the computer and the types of documents that each can create, property sheet settings for folders and application icons, what hardware exists on the system, and the ports that are being used.
The Registry replaces most of the text-based .ini files used in Windows 3.x and MS-DOS configuration files, such as the Autoexec.bat and Config.sys. Although the Registry is common to several Windows operating systems, there are some differences among them.
Registry data is stored in binary files.
For further info try this: http://support.microsoft.com/default.aspx?kbid=256986
A central hierarchical database used in Microsoft Windows 9x, Windows CE, Windows NT, and Windows 2000 used to store information necessary to configure the system for one or more users, applications and hardware devices.
The Registry contains information that Windows continually references during operation, such as profiles for each user, the applications installed on the computer and the types of documents that each can create, property sheet settings for folders and application icons, what hardware exists on the system, and the ports that are being used.
The Registry replaces most of the text-based .ini files used in Windows 3.x and MS-DOS configuration files, such as the Autoexec.bat and Config.sys. Although the Registry is common to several Windows operating systems, there are some differences among them.
Registry data is stored in binary files.
For further info try this: http://support.microsoft.com/default.aspx?kbid=256986
Hi :
In short :
The Windows registry is where software programs and Windows itself identify themselves and keep information for use between different running sessions.
For example, each time Windows is started, it brings up the programs you have used before, such as the Explorer. It remembers your previous actions by storing the information in the registry.
Another example is that each file type is associated with a software program. For example, when you double click a GIF file, the file is displayed in your browser - or a drawing program, such as PaintShop Pro. A software program registers itself when it is installed and tells the registry what file type(s) it can handle.
The registry is actually the battle fields for huge commercial wars. For example, both IE and Netscape are trying to register as the default browser.
--------------
If you like to know more in details with sceenshot then visit this page :
http://www.freepctech.com/pc/002/Windows_registry_faq.shtml
Hope it helps!
rsdn
In short :
The Windows registry is where software programs and Windows itself identify themselves and keep information for use between different running sessions.
For example, each time Windows is started, it brings up the programs you have used before, such as the Explorer. It remembers your previous actions by storing the information in the registry.
Another example is that each file type is associated with a software program. For example, when you double click a GIF file, the file is displayed in your browser - or a drawing program, such as PaintShop Pro. A software program registers itself when it is installed and tells the registry what file type(s) it can handle.
The registry is actually the battle fields for huge commercial wars. For example, both IE and Netscape are trying to register as the default browser.
--------------
If you like to know more in details with sceenshot then visit this page :
http://www.freepctech.com/pc/002/Windows_registry_faq.shtml
Hope it helps!
rsdn
Naaeemg: Thanks for the reprint. Interesting to some, I'm sure, but what I was looking for was a simple explanation in leymans terms.
Also, everyone else - where is the registry stored on the hard drive? And why are there two registries (regedit & regedt32)?
Thanks
Also, everyone else - where is the registry stored on the hard drive? And why are there two registries (regedit & regedt32)?
Thanks
> In leymans terms, can anyone give a good explanation of the Windows registry?
No. Really, it is a mess. No good explanation, IMO. ;-)
> Like why it's there,
Because.
Not a simple answer really, since its role has changed since original conception.
The origin or roots for registry was more personal, with sole intention of being a mechanism for assisting users to run products that they are authorized for, and for products to deny access to unauthorized users.
All this is well and good, were that all there was to it, for we do want a system that works and satisfies validity and security concerns. But the design itself was objected to on both sides of fence, basically due to concerns for right to privacy. Users did not want excessive release of personal information. Companies competing with Microsoft did not want their competitor to gain unfair advantage by collecting information on their products. Also, there were a number of companies seeking to market their own versions for product installations, validations, and tracking systems. Question was, is MS the operating system or the competitor, and the focus of question was just this, the registry. So a revision was made to attempt to satisfy both, such that when a user installs a product, very often the registry will be used to support a subsequent validation process. This is the 'feature' that lends its name to the product.
Since the original concept became near to null, another role was rolled in, that being for configuration files, for information specific to how users want their products to operate. For technicality stuff (not lay), this is like having a config.sys file to boot up a PC, expanding its potential to have separate collections of information for each product, where before, each product had to use its own files for storing configuration information, typically in a text file such as config.txt or install.txt or update.txt or install.cfg or setup.txt, etc. or even in a database such as bTrieve or a dBase. Skimping any technicality concerning the files, a layperson should be able to see and agree that where each company marketing a product has a different methodology, were they to use a common means to implement same strategy for maintaining configuration information, their time to market can be reduced as well as needs for upgrades. Or, in a nutshell, less training costs, in particular to new developer employees, staff who would not need to be retrained in yet another methodology. Turnover becomes a little less of a problem, and most can get to compete on more equal basis with most others.
Why? - to have a common method for any developer of products to store and retrieve information.
> what it does
It waits. Does not do anything at all, it is simply a repository for information that can be used, if indeed it is used. How it is used is really up to the program that can deposit and/or retrieve information with the depository
> and how it works etc
It works like a database, a multi-treed hierarchy, like a corporate oraganization chart. In each category there can be a subcategory, if one were to drill down to the bottom layer one would eventually arrive at the level of the individual (not organization) where there is the actual content of information (not the structure)
In practice, it is very heavily abused, in particular by the company of origin, Microsoft, which dumps just too much junk in it that would be better placed elsewhere. This leads to a bloat (see VS for example) that can dramatically and adversely impact access times, both at runtime and at boot time. This can be less noticeable if one continual ly buys H/W upgrades each year or so to improve speed.
[asking about how products use it is another question and tends to become more for technical person than for a layperson]
No. Really, it is a mess. No good explanation, IMO. ;-)
> Like why it's there,
Because.
Not a simple answer really, since its role has changed since original conception.
The origin or roots for registry was more personal, with sole intention of being a mechanism for assisting users to run products that they are authorized for, and for products to deny access to unauthorized users.
All this is well and good, were that all there was to it, for we do want a system that works and satisfies validity and security concerns. But the design itself was objected to on both sides of fence, basically due to concerns for right to privacy. Users did not want excessive release of personal information. Companies competing with Microsoft did not want their competitor to gain unfair advantage by collecting information on their products. Also, there were a number of companies seeking to market their own versions for product installations, validations, and tracking systems. Question was, is MS the operating system or the competitor, and the focus of question was just this, the registry. So a revision was made to attempt to satisfy both, such that when a user installs a product, very often the registry will be used to support a subsequent validation process. This is the 'feature' that lends its name to the product.
Since the original concept became near to null, another role was rolled in, that being for configuration files, for information specific to how users want their products to operate. For technicality stuff (not lay), this is like having a config.sys file to boot up a PC, expanding its potential to have separate collections of information for each product, where before, each product had to use its own files for storing configuration information, typically in a text file such as config.txt or install.txt or update.txt or install.cfg or setup.txt, etc. or even in a database such as bTrieve or a dBase. Skimping any technicality concerning the files, a layperson should be able to see and agree that where each company marketing a product has a different methodology, were they to use a common means to implement same strategy for maintaining configuration information, their time to market can be reduced as well as needs for upgrades. Or, in a nutshell, less training costs, in particular to new developer employees, staff who would not need to be retrained in yet another methodology. Turnover becomes a little less of a problem, and most can get to compete on more equal basis with most others.
Why? - to have a common method for any developer of products to store and retrieve information.
> what it does
It waits. Does not do anything at all, it is simply a repository for information that can be used, if indeed it is used. How it is used is really up to the program that can deposit and/or retrieve information with the depository
> and how it works etc
It works like a database, a multi-treed hierarchy, like a corporate oraganization chart. In each category there can be a subcategory, if one were to drill down to the bottom layer one would eventually arrive at the level of the individual (not organization) where there is the actual content of information (not the structure)
In practice, it is very heavily abused, in particular by the company of origin, Microsoft, which dumps just too much junk in it that would be better placed elsewhere. This leads to a bloat (see VS for example) that can dramatically and adversely impact access times, both at runtime and at boot time. This can be less noticeable if one continual ly buys H/W upgrades each year or so to improve speed.
[asking about how products use it is another question and tends to become more for technical person than for a layperson]
Jason210> where is the registry stored on the hard drive?
;-(
Who cares. Really. [imo]
Basically, it can be anywhere, somewhere where you cannot find it. However, it got put in filesystem beneath c:\Windows, not because of functional need, but because of too many lazy hires who dunno anything about a filesystem so they ever put files somewhere under c:\windows to make it easier to be found. [IMO, nothing other than OS itself should be in an OS directory] [oh, they also dunno about using a system with multiple partitions and drives. Another benefit to having a commonality such as registry, to reduce filesystem access and structure and need for knowledge and experience from so-called programmers who can do little more than run some wizard]
> And why are there two registries (regedit & regedt32)?
Again, who cares!
My reasoning is, there is only one editor (not registry) and it is RegEdit. The other one, whatever its name is no layperson need know. It was meant to be upgrade (32 bigger than 16) but some useful features got omitted while some nice ones, less used, were added for some technical reasons.
In lay terms, where NotePad is an editor than can display text of text files, a RegEdit can display the text (version) of content stored in an otherwise unintelligible registry (like database), and in so doing, it employs an interface for user similar to Windows Explorer (familiar), in capability to have some meaningful icons than can be used to navigate the structure to point of "drilling down" to the single unit of information sought.
;-(
Who cares. Really. [imo]
Basically, it can be anywhere, somewhere where you cannot find it. However, it got put in filesystem beneath c:\Windows, not because of functional need, but because of too many lazy hires who dunno anything about a filesystem so they ever put files somewhere under c:\windows to make it easier to be found. [IMO, nothing other than OS itself should be in an OS directory] [oh, they also dunno about using a system with multiple partitions and drives. Another benefit to having a commonality such as registry, to reduce filesystem access and structure and need for knowledge and experience from so-called programmers who can do little more than run some wizard]
> And why are there two registries (regedit & regedt32)?
Again, who cares!
My reasoning is, there is only one editor (not registry) and it is RegEdit. The other one, whatever its name is no layperson need know. It was meant to be upgrade (32 bigger than 16) but some useful features got omitted while some nice ones, less used, were added for some technical reasons.
In lay terms, where NotePad is an editor than can display text of text files, a RegEdit can display the text (version) of content stored in an otherwise unintelligible registry (like database), and in so doing, it employs an interface for user similar to Windows Explorer (familiar), in capability to have some meaningful icons than can be used to navigate the structure to point of "drilling down" to the single unit of information sought.
(also/further)
- Registry is a file that enables/facilitates the finding of other files. It's data content can be either name of file, or location of file, or even what parameters to pass a file/program when used.
- Registry also is not at all for any layperson. Review of any reputable company site and they will say it just so, and that includes Microsoft. They often produce simple answers to configuration questions, with Registry changes being recommended, yet contain some caveat cya that the registry should not be edited by layperson, uninformed non-professionals, each in their own words of course.
So... for layperson, another answer is, don't even think of registry ever at all. Just use the computer and have some fun with it as it is.
- Registry is a file that enables/facilitates the finding of other files. It's data content can be either name of file, or location of file, or even what parameters to pass a file/program when used.
- Registry also is not at all for any layperson. Review of any reputable company site and they will say it just so, and that includes Microsoft. They often produce simple answers to configuration questions, with Registry changes being recommended, yet contain some caveat cya that the registry should not be edited by layperson, uninformed non-professionals, each in their own words of course.
So... for layperson, another answer is, don't even think of registry ever at all. Just use the computer and have some fun with it as it is.
simple terms
the registry in the windows operating system
is equal to what your brain is to your body
the registry in the windows operating system
is equal to what your brain is to your body
Another way to put it into the simplest possible terms:
The registry contains all the settings and parameters needed to make your computer run the way it does. Putting it somewhat simplistically, without the registry your computer's operating system and all the applications on it would be inidistinguishable from anybody else's computer with the same OS and those same applications and drivers.
There's a bit more to it than that because many of those settings and parameters are essential for the OS and for the applications to work. The registry is a critical component of your operating system. But the important principle is the separation of program code and the data that customizes it. Your copy of Windows, Word, Excel etc. is exactly the same as anybody else's and the registry contains all the information that adapts it to your specific computer environment. This principle has become so important the Microsoft made the decision to integrate the increasingly complex .INI and other files into this single repository called the registry. Many have disputed the wisdom of this kind of mega-integration; it has its advantages and disadvantages.
As to how it's used, it's queried all the time - at OS startup, at application startup, and at any other time when those settings need to be retrieved.
The first incarnation of the registry in Windows95 was just two files stored under the Windows directory - system.dat and user.dat. In subsequent OS's like Windows XP, it has become significantly distributed, and also more protected and more self-healing.
The registry contains all the settings and parameters needed to make your computer run the way it does. Putting it somewhat simplistically, without the registry your computer's operating system and all the applications on it would be inidistinguishable from anybody else's computer with the same OS and those same applications and drivers.
There's a bit more to it than that because many of those settings and parameters are essential for the OS and for the applications to work. The registry is a critical component of your operating system. But the important principle is the separation of program code and the data that customizes it. Your copy of Windows, Word, Excel etc. is exactly the same as anybody else's and the registry contains all the information that adapts it to your specific computer environment. This principle has become so important the Microsoft made the decision to integrate the increasingly complex .INI and other files into this single repository called the registry. Many have disputed the wisdom of this kind of mega-integration; it has its advantages and disadvantages.
As to how it's used, it's queried all the time - at OS startup, at application startup, and at any other time when those settings need to be retrieved.
The first incarnation of the registry in Windows95 was just two files stored under the Windows directory - system.dat and user.dat. In subsequent OS's like Windows XP, it has become significantly distributed, and also more protected and more self-healing.
that's ok, well and good enough, providing one does not presume it too critical to non-MS programs and applications, which may still place settings elsewhere, such as its own directory or even beneath your home directory, wherever that is (varies by OS). The program itself need never use registry, need never be registered, if it wants to, all it needs to is run well on its own.
> Microsoft made the decision to integrate the increasingly complex .INI and other files into this single repository called the registry. Many have disputed the wisdom of this kind of mega-integration; it has its advantages and disadvantages.
yeah. I skip the .ini as leading to such complexions, not for layperson. If not clear, I am in a disputer camp, so I validate Wolfpup99 remark. With XP selfhealing I also like idea, but could disagree with it having a beneficial experience (such as its method of restoring virus for you after you remove it. So you thought)
> Microsoft made the decision to integrate the increasingly complex .INI and other files into this single repository called the registry. Many have disputed the wisdom of this kind of mega-integration; it has its advantages and disadvantages.
yeah. I skip the .ini as leading to such complexions, not for layperson. If not clear, I am in a disputer camp, so I validate Wolfpup99 remark. With XP selfhealing I also like idea, but could disagree with it having a beneficial experience (such as its method of restoring virus for you after you remove it. So you thought)
I'll give my shot at explaining the registry:
The Windows registry is basically a simple database of "settings" for both Microsoft Windows itself, and most (but not all) software that runs on Windows.
For example- when you pick a certain desktop background, or a screen saver - those settings are stored in the "registry" for use later on. That's how Windows remembers how things are set.
Registry settings are sometimes "computer wide" (meaning- the registry settings apply no matter WHO is logged in- things like disk drive settings and so on). There are also registry settings that are "user specific" - meaning, the settings are different, depending on who is logging into the PC. That's how different users can have different screensavers, for example.
The registry is used a lot by Windows itself; but it is ALSO used by tons of applications and software- like Microsoft Office, for example. Note, software is not REQUIRED to use the registry for settings - but in general, it's a great idea and seems to work well.
Final note- depends on your version of Windows, but the registry "databases" are SYSTEM.DAT and USER.DAT.
This also hopefully gives you an idea of why the registry is very important, and why you need to be CAREFUL when using the REGEDIT program. One small thing-- one wrong "key" or "data" thing changed wrong, and Windows can become totally screwed up. At best, you may end up accidently erasing some important settings that take a while to re-do. At worst, you can make Windows unbootable.
While the registry stores all these SETTINGS-- they are also IMPORTANT settings.
I hope this helps!
--kcb
The Windows registry is basically a simple database of "settings" for both Microsoft Windows itself, and most (but not all) software that runs on Windows.
For example- when you pick a certain desktop background, or a screen saver - those settings are stored in the "registry" for use later on. That's how Windows remembers how things are set.
Registry settings are sometimes "computer wide" (meaning- the registry settings apply no matter WHO is logged in- things like disk drive settings and so on). There are also registry settings that are "user specific" - meaning, the settings are different, depending on who is logging into the PC. That's how different users can have different screensavers, for example.
The registry is used a lot by Windows itself; but it is ALSO used by tons of applications and software- like Microsoft Office, for example. Note, software is not REQUIRED to use the registry for settings - but in general, it's a great idea and seems to work well.
Final note- depends on your version of Windows, but the registry "databases" are SYSTEM.DAT and USER.DAT.
This also hopefully gives you an idea of why the registry is very important, and why you need to be CAREFUL when using the REGEDIT program. One small thing-- one wrong "key" or "data" thing changed wrong, and Windows can become totally screwed up. At best, you may end up accidently erasing some important settings that take a while to re-do. At worst, you can make Windows unbootable.
While the registry stores all these SETTINGS-- they are also IMPORTANT settings.
I hope this helps!
--kcb
What is the Registry? The Registry has been made out to be a phenomenal mystery probably due to the CLSID keys alone and as such has inspired a number of books, faqs websites etc. It is very unfortunate that Microsoft has chosen to deal with the Registry and Registry editing as a "black art," leaving many people in the dark as to the real uses of all the settings in the systems. Microsoft's refusal to adequately, and publicly, supply information about the correct settings is extremely frustrating and added further mystery to registry. Certainly, more damage has and will be done because of lack of knowledge than because of too much information.
The Windows Registry is a set of data files used to help Windows control hardware, software, the user's environment, and the "look and feel" of the Windows interface. The Registry is contained in two files in the Windows directory (in NT they are called "hives"): system.dat and user.dat, with backup copies system.da0 and user.da0. The Registry database is accessed with regedit.exe which is in the Windows directory. Formerly, in older version of windows (before windows 95) these functions were performed by WIN.INI, SYSTEM.INI, and other .INI files that are associated with applications.
The evolution of application and operating system control has three distinct levels:
In Legacy Windows systems, SYSTEM.INI and WIN.INI held all the control functions for the operating systems and applications. Essentially, SYSTEM.INI controlled the hardware while WIN.INI controlled the desktop and applications. All changes to drivers, fonts, settings, and preferences would be stored in the .INI files. Any new application that was installed added pointers to the .INI files. Those pointers would then be referenced in the application's code.
Additional .INI files that controlled the applications were added by programmers who needed more control than was available because of the limited size of the WIN.INI and SYSTEM.INI files. For example, Microsoft included with Excel a file called EXCEL.INI, which held the options, settings, defaults, and other information critical to making Excel work correctly. The only pointer that was then required in WIN.INI was to the EXCEL.INI path and filename.
The Registry was initially developed as a reference file for data-file associations to applications. It was expanded to include all functions for 32-bit operating systems and applications.
Originally, SYSTEM.INI and WIN.INI controlled all Windows and application features and access. It worked well when average users used only a few applications. As the number and complexity of applications grew, so did the number of entries to the .INI files. The downside of this approach, in a growing environment, is that everyone would make changes to the .INI files when applications were added to the system. However, no one ever removed references from their .INI files when they removed applications, so SYSTEM.INI and WIN.INI continued to get larger and larger. Each incremental size increase meant slower performance. Even upgrading applications presented its challenges. The upgrade would add entries but never take the old ones away, presumably to ensure compatibility if another program was to access the settings.
Because the maximum size of an .INI file is 64KB, an obvious problem arose. To counter the problem, vendors started supplying .INI files of their own, with just pointers to the specific .INI files in WIN.INI and SYSTEM.INI. The downside of this approach was the proliferation of .INI files throughout the system and the hierarchical nature of access. If WIN.INI made a particular setting, and an application's .INI file overrode that setting, who was responsible and where should--or could--a system-wide setting that had priority be made?
The Registry is a set of files that control all aspects of the operating system and how it works with outside events. Those "events" range from accessing a hardware device directly to how the interface will react to a specific user to how an application will be run and much more. It was designed to work exclusively with 32-bit applications, and file size is limited to a about 40MB.
The Registry is complex by its very nature, and on purpose.
What the Registry Does
The Registry is the data file for all 32-bit hardware/driver combinations and 32-bit applications in both Windows NT and Windows 95. Sixteen-bit drivers do not work in NT, so all devices are controlled through the Registry, even those normally controlled by the BIOS. In Windows 95, 16-bit drivers will continue to work as real-mode devices, and they use SYSTEM.INI for control.
Sixteen-bit applications will work in either NT or 95, and the applications still refer to WIN.INI and SYSTEM.INI files for information and control.
Without the Registry, the operating system would not have the necessary information to run, to control attached devices, to launch and control applications, and to respond correctly to user input.
Data File for OS to Hardware/Drivers
The Registry is a database of all the settings and locations of 32-bit drivers in the system. When the OS needs to access hardware devices, it uses drivers, even if the device is a BIOS-supported device.
Non-BIOS-supported devices that are installed must also have a driver. The drivers are independent of the OS, but the OS needs to know where to find them, the filename, the version, and other settings and information. Without Registry entries for each of the devices, they would not be usable.
Data File for OS to Applications
When a user attempts to launch an application, the Registry supplies application information to the OS so the application can be found, the correct data file locations are set, and other settings are available.
The Registry holds information about default data and auxiliary file locations, menus, button bars, window status, and other options. It also holds installation information such as the date of installation, the user who installed the software, the version number and date, and sometimes the serial number. Depending on the actual software installed, it may contain other application-specific information.
Two Types of Control
Although, in general, the Registry controls all 32-bit applications and drivers, the type of control it exercises is based on users and computers, not on applications or drivers. Every Registry entry controls a user function or a computer function. User functions would include the desktop appearance and home directory, for example. Computer functions are related to installed hardware and software, items that are common to all users.
Some application functions affect users, and others affect the computer and are not specifically set for an individual. Similarly, drivers may be user-specific, but, most of the time, they are for general use by the computer. All of the settings discussed in the rest of the book are separated by user and computer.
Some examples of user-type functions controlled by the Registry are
Control Panel functions
Desktop appearance and icons
Network preferences
Explorer functionality and features
Some of those functions are the same regardless of user; others are user-specific.
Computer-related control items are based on the computer name, without respect to the logged-in user. An example of this type of control would be installing an application. The availability and access to the application is constant, regardless of the user; however, icons to launch the application are dependent on the user logging in to the network. Network protocol availability and priority is based on the computer, but current connections are based on user information.
Here are some examples of computer-based control items in the Registry:
Access control
Login validation
File and print sharing
Network card settings and protocols
System performance and virtual memory settings
Without the Registry, Windows 95 and Windows NT would not be possible. They are too complex to be controlled by the older .INI files, and their expansion capabilities allow almost unlimited installation and use of applications. The Registry is, however, much more complex than the .INI files, and understanding how it works, what it does, and how to work with it is critical for effective system administration.
The Registry controls all 32-bit applications and their functions on the system, plus the interaction between multiple applications, such as copying and pasting. It also controls all the hardware and drivers. Though most of the settings are made during installation and through the Control Panel, understanding the Registry is fundamental to reliable and capable management of Windows NT and Windows 95 systems.
http://www.systweak.com/winreg/wr1.htm
The Windows Registry is a set of data files used to help Windows control hardware, software, the user's environment, and the "look and feel" of the Windows interface. The Registry is contained in two files in the Windows directory (in NT they are called "hives"): system.dat and user.dat, with backup copies system.da0 and user.da0. The Registry database is accessed with regedit.exe which is in the Windows directory. Formerly, in older version of windows (before windows 95) these functions were performed by WIN.INI, SYSTEM.INI, and other .INI files that are associated with applications.
The evolution of application and operating system control has three distinct levels:
In Legacy Windows systems, SYSTEM.INI and WIN.INI held all the control functions for the operating systems and applications. Essentially, SYSTEM.INI controlled the hardware while WIN.INI controlled the desktop and applications. All changes to drivers, fonts, settings, and preferences would be stored in the .INI files. Any new application that was installed added pointers to the .INI files. Those pointers would then be referenced in the application's code.
Additional .INI files that controlled the applications were added by programmers who needed more control than was available because of the limited size of the WIN.INI and SYSTEM.INI files. For example, Microsoft included with Excel a file called EXCEL.INI, which held the options, settings, defaults, and other information critical to making Excel work correctly. The only pointer that was then required in WIN.INI was to the EXCEL.INI path and filename.
The Registry was initially developed as a reference file for data-file associations to applications. It was expanded to include all functions for 32-bit operating systems and applications.
Originally, SYSTEM.INI and WIN.INI controlled all Windows and application features and access. It worked well when average users used only a few applications. As the number and complexity of applications grew, so did the number of entries to the .INI files. The downside of this approach, in a growing environment, is that everyone would make changes to the .INI files when applications were added to the system. However, no one ever removed references from their .INI files when they removed applications, so SYSTEM.INI and WIN.INI continued to get larger and larger. Each incremental size increase meant slower performance. Even upgrading applications presented its challenges. The upgrade would add entries but never take the old ones away, presumably to ensure compatibility if another program was to access the settings.
Because the maximum size of an .INI file is 64KB, an obvious problem arose. To counter the problem, vendors started supplying .INI files of their own, with just pointers to the specific .INI files in WIN.INI and SYSTEM.INI. The downside of this approach was the proliferation of .INI files throughout the system and the hierarchical nature of access. If WIN.INI made a particular setting, and an application's .INI file overrode that setting, who was responsible and where should--or could--a system-wide setting that had priority be made?
The Registry is a set of files that control all aspects of the operating system and how it works with outside events. Those "events" range from accessing a hardware device directly to how the interface will react to a specific user to how an application will be run and much more. It was designed to work exclusively with 32-bit applications, and file size is limited to a about 40MB.
The Registry is complex by its very nature, and on purpose.
What the Registry Does
The Registry is the data file for all 32-bit hardware/driver combinations and 32-bit applications in both Windows NT and Windows 95. Sixteen-bit drivers do not work in NT, so all devices are controlled through the Registry, even those normally controlled by the BIOS. In Windows 95, 16-bit drivers will continue to work as real-mode devices, and they use SYSTEM.INI for control.
Sixteen-bit applications will work in either NT or 95, and the applications still refer to WIN.INI and SYSTEM.INI files for information and control.
Without the Registry, the operating system would not have the necessary information to run, to control attached devices, to launch and control applications, and to respond correctly to user input.
Data File for OS to Hardware/Drivers
The Registry is a database of all the settings and locations of 32-bit drivers in the system. When the OS needs to access hardware devices, it uses drivers, even if the device is a BIOS-supported device.
Non-BIOS-supported devices that are installed must also have a driver. The drivers are independent of the OS, but the OS needs to know where to find them, the filename, the version, and other settings and information. Without Registry entries for each of the devices, they would not be usable.
Data File for OS to Applications
When a user attempts to launch an application, the Registry supplies application information to the OS so the application can be found, the correct data file locations are set, and other settings are available.
The Registry holds information about default data and auxiliary file locations, menus, button bars, window status, and other options. It also holds installation information such as the date of installation, the user who installed the software, the version number and date, and sometimes the serial number. Depending on the actual software installed, it may contain other application-specific information.
Two Types of Control
Although, in general, the Registry controls all 32-bit applications and drivers, the type of control it exercises is based on users and computers, not on applications or drivers. Every Registry entry controls a user function or a computer function. User functions would include the desktop appearance and home directory, for example. Computer functions are related to installed hardware and software, items that are common to all users.
Some application functions affect users, and others affect the computer and are not specifically set for an individual. Similarly, drivers may be user-specific, but, most of the time, they are for general use by the computer. All of the settings discussed in the rest of the book are separated by user and computer.
Some examples of user-type functions controlled by the Registry are
Control Panel functions
Desktop appearance and icons
Network preferences
Explorer functionality and features
Some of those functions are the same regardless of user; others are user-specific.
Computer-related control items are based on the computer name, without respect to the logged-in user. An example of this type of control would be installing an application. The availability and access to the application is constant, regardless of the user; however, icons to launch the application are dependent on the user logging in to the network. Network protocol availability and priority is based on the computer, but current connections are based on user information.
Here are some examples of computer-based control items in the Registry:
Access control
Login validation
File and print sharing
Network card settings and protocols
System performance and virtual memory settings
Without the Registry, Windows 95 and Windows NT would not be possible. They are too complex to be controlled by the older .INI files, and their expansion capabilities allow almost unlimited installation and use of applications. The Registry is, however, much more complex than the .INI files, and understanding how it works, what it does, and how to work with it is critical for effective system administration.
The Registry controls all 32-bit applications and their functions on the system, plus the interaction between multiple applications, such as copying and pasting. It also controls all the hardware and drivers. Though most of the settings are made during installation and through the Control Panel, understanding the Registry is fundamental to reliable and capable management of Windows NT and Windows 95 systems.
http://www.systweak.com/winreg/wr1.htm
Thanks everybody, for your efforts. I found molar's explanation the easiest to understand, as a general description, so e got the mian points. Assisted answers contained supplementáry info or were also good simple explantions got 50 points each grade A.
Featured Post
Did you know SD-WANs can improve network connectivity? Check out this webinar to learn how an SD-WAN simplified, one-click tool can help you migrate and manage data in the cloud.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
With the shift in today’s hiring climate (http://blog.experts-exchange.com/ee-blog/5-tips-on-succeeding-in-the-new-gig-economy/?cid=Blog_031816), many companies are choosing to hire freelancers to get projects completed efficiently and inexpensively…
Gift cards are not a new concept - it's been around for a very long time. Undoubtedly, over the past you have received such a card or purchased one for a friend or relative. Are you aware that you've been feeding the machine? If not, read on :)
Saved searches can save you time by quickly referencing commonly searched terms on any topic. Whether you are looking for questions you can answer or hoping to learn about a specific issue, a saved search can help you get the most out of your time o…
Where to go on the main page to find the job listings.
How to apply to a job that you are interested in from the list that is featured on our Careers page.
Suggested Courses
Course of the Month4 days, 14 hours left to enroll
688 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.