Introduction
It is by no means finished or 100%. When I say that, I mean that it may not perform everything I want 100%. That is because I am finding it hard to find time getting it to 100%. If there is someone out there that wants to help me get it to 100%, please let me know!!
I wanted to create a registry editor that used the "Native Registry APIs" instead of using the Microsoft Registry APIs in AdvApi32.dll (which is just a wrapper to the Native Registry APIs). There is still dependency to the AdvApi32.dll because of the all the other APIs in it. I basically wrote a class that does this (I guess it is also a wrapper - see picture below). I wanted to create something that would have the same functionality as Microsoft's Registry Editor but with the ability to do a lot more. I liked working with the SDI Framework, and decided to start with that. I also wanted to make it a bit easier to read the registry data, so I decided on color coding. This would make it easier for a user to color the information to their liking, making it easier to read and more user-friendly.
All registry viewing/modification is done strictly by using the CNtRegistry class I wrote, which can be found here on CodeProject. There are a lot of Registry editors out there, both free and shareware, but they don't use Native Registry APIs to perform their viewing/modifications. My goal is to create a registry editor that can do "exactly" what Microsoft's RegEdit can do and more.
Using the Software
There's really a lot you already know about its functionality (because you know how to use Microsoft's RegEdit) that is available through the interface. I have attempted to hide all the really complicated stuff in the class so that the simplicity comes out. This simplicity was accomplished in the CRegistry class by Robert Pittenger found here at CodeProject, and is where the overall structure of this class comes from. Thanks Robert!
Using the Code (CNtRegistry)
Now, the CNtRegistry class is explained in another article from me here, so I would suggest you go there to get the full story, but I will list just a few of the functions in it:
BOOL SetRootKey(HKEY hKey);
BOOL SetKey(HKEY hRoot, CString csKey, BOOL bCanCreate, BOOL bCanSaveCurrentKey);
BOOL SetKey(CString csKey, BOOL bCanCreate, BOOL bCanSaveCurrentKey);
BOOL CreateKey(CString csKey);
BOOL CreateHiddenKey(CString csKey);
BOOL RenameKey(CString csFullKey, CString csNewKeyName);
BOOL DeleteKey(CString csKey);
BOOL DeleteKeysRecursive(CString csKey);
BOOL FindHiddenKeys(CString csKey, BOOL bRecursive, CStringArray& csaResults);
BOOL Search(CString csString, CString csStartKey, CStringArray& csaResults,
int nRegSearchType = 3, BOOL bCaseSensitive = TRUE);
BOOL CopyKeys(CString csSource, CString csTarget);
As you can see, the functions above are pretty simple and user-friendly. There is a lot more to it, and you should go look at the article to get more detailed info.
Some Visual Capabilities
You can import/export Native Registry (.neg) and/or Microsoft Registry (.reg) files if they are Win2000 or greater (basically, if the registry file's first line is "Windows Registry Editor Version 5.00"). The images below show both examples of exported files (notice that it is the Key shown in the picture above). If you look at the ".neg" file, it has an asterisk (*) after the Key "[HKCU\AppTest\HiddenKey2*]". This is so you can import/export a hidden key.
When you attempt to export a Key, you will see the popup below if there are Keys under the one you are trying to export (thanks to "Defenestration" for the suggestion).
Here is a mapping of the current RegEdit format compared to the NtRegEdit format:
|
NtRegEdit |
RegEdit |
Registry Type |
| @= | @= | (Default) |
| =str: | ="" | REG_SZ |
| =exp: | =hex(2): | REG_EXPAND_SZ |
| =bin: | =hex: | REG_BINARY |
| =dw: | =dword: | REG_DWORD |
| =dwbe: | =dword: | REG_DWORD_BIG_ENDIAN |
| =link: | =hex(6): | REG_LINK |
| =multi: | =hex(7): | REG_MULTI_SZ |
| =reslist: | =hex(8): | REG_RESOURCE_LIST |
| =fullres: | =hex(9): | REG_FULL_RESOURCE_DESCRIPTOR |
| =reqlist: | =hex(10): | REG_RESOURCE_REQUIREMENTS_LIST |
| =qword: | =hex(b): | REG_QWORD |
Key creations/modifications will bring up the dialog box shown below. It performs a number of functions/capabilities like:
- Creating normal/hidden Keys
- Copying normal/hidden Keys
- Finding hidden Keys
- Renaming normal/hidden Keys
- Searching in Keys/values/data
Pressing the "Browse" button allows a user to select a Key (see picture below) that they want to perform the particular task on:
Now, I also added an Application Settings dialog that allows you to set some General/ListCtrl/TreeCtrl things that affect the GUI. There is a lot more that can go in these dialogs (even adding more dialogs), but for now this is it. You can see these dialogs below:
- General tab
- Save window position
- Keep window top-most
- Check OS type on start-up
- Check if user is the administrator on start-up
- Etc...
- List Control tab
- Select a color to use for each Registry type (by clicking on the item)
- Tree Control tab
- Use bold for registry root Keys
- Use bold for hidden Keys
- Select a color to use for each registry root Key (and the subkeys - by clicking on the item)
The Code Inside (Displaying Keys)
The code to get the registry information to build the tree view is also pretty simple, and only shows you the current Keys, and uses the GetSubKeyCount() function to determine if the Key has any subkeys. If it does, it adds a "Fake Item", the whole purpose of which is to show the Key as having subkeys. Every time you drill down in the tree (by expanding a tree item), it reads the registry for the next level of Keys (see below). This allows for a faster loading of the TreeView at start-up.
if (m_ntReg.SetKey(csFullKey,FALSE,TRUE)) {
CStringArray csaKeys;
if (hItem == NULL) {
hItem = m_hRoot;
}
BOOL bOk = FALSE;
m_ntReg.GetSubKeyList(csaKeys);
for (int n=0; n<csaKeys.GetSize(); n++) {
CString csKey(csFullKey);
csKey += _T("\\");
csKey += csaKeys.GetAt(n);
bOk = m_ntReg.SetKey(csKey,FALSE,TRUE);
int nIcon = 5;
if (m_ntReg.m_bHidden) { nIcon = 0; }
HTREEITEM hNewItem =
tc.InsertItem(csaKeys.GetAt(n),nIcon,nIcon,hItem);
SetItemColor(hNewItem,crTextColor);
if (m_ntReg.m_bHidden && theApp.m_clsMainFrm->m_bBoldHidden) {
SetItemBold(hNewItem,TRUE);
}
if (bOk && m_ntReg.GetSubKeyCount() > 0) {
tc.InsertItem(FAKEDITEM,5,5,hNewItem,TVI_LAST);
}
tc.SortChildren(hNewItem);
}
}
Now that we can see the subkeys, when a user clicks on a tree item, it queries the Key for values, and displays them in the list view. How the user has the list control coloring setup depends on how the user sees the information.
There is also the ability to view the permissions of a given Key (as long as you have the permissions to do this).
There is also a number of tabs below the list view. These are for creating/modifying registry data. Since there are only three data formats in the registry (binary, DWORDs, and strings(3)), this was pretty easy. Whatever registry type you click on in the list view, it will activate that tab and fill the data. Once there, you can create a new value, or simply modify the data. If you enter anything in the "Create Name" edit control, it will assume you want to "Create" a new value. If you modify the data, it will assume you want to "Update" the data.
There is also a tab for viewing the "Search and Find Hidden Keys" results (thanks to "Tcpip2005" for the suggestion). If you select Search (and other commands) from the menu or toolbar, you will see a dialog box with some controls.
It doesn't end just there, you can also "double-click" on the Search/Find View, and you will be taken to the Key, value name, and/or value. For example, if you search for a string named "string", it will show you the results in column #1. If the word was found in a value name, it will be put in column #2. If the word was found in a value, it will be put it in column #3. When you double-click on it, the app will show you the Key (visually). If there is a value name in column #2, it will highlight it. If there is a value in column #3, it will highlight it too (basically, it will show you where it is). This works even if it is a "hidden Key".
In Closing...
That is what I got so far. I don't expect this to be perfect, so please give me your ideas to make it better. One thing to remember in life itself and all the challenges that come with it ... if you make a "mistake" and learn from it, then it never was a mistake to begin with...it was a "lesson"!
Thanks to ...
NtRegEdit uses some very useful classes/controls found here at CodeProject:
Things To-Do
- Make it have all the "RegEdit" functionality
- Add a lot more native functionality that RegEdit doesn't have
- Make it really user-friendly!!
History
- September 6, 2006
- Fixed GUI - Tree/List views not initializing correctly
- August 23, 2006 (0.0.2.857)
- Added the Security Permissions dialog
- August 10, 2006 (0.0.2.734)
- Added names to the About dialog (source owners)
- Added bold options to the TreeCtrl
- Added Application Settings dialog boxes:
COptGenDlg() - General
COptListDlg() - List control
COptTreeDlg() - Tree control
- Added coloring to the
CNtRegEditTreeView class (XListCtrl already had it)
- Added label editing for the
CTreeCtrl
- Added the beginning of the new "NtRegEdit" format
- Added virtual keys:
VK_UP (Up to the next "visible" item (displays values))
VK_DOWN (Down to next "Visible" item (displays values))
VK_DELETE (Will prompt user for recursive if subkey exists)
VK_ENTER (Opens a subkey if it exists, else no effect)
- Fixed the
OnKeysRefresh() function (I think)
- July 16, 2006 (0.0.1.689)
- Added Key path in the statusbar (thanks to ...)
- July 10, 2006
- July 3, 2006 (0.0.0.1)
