![]() |
Web Development »
Applications & Tools »
Tools with source code
Intermediate
License: The Code Project Open License (CPOL)
NtRegEdit - Native Registry EditorBy Dan MaddenA replacement for the Registry Editor by Microsoft. |
VC8.0Win2K, Visual-Studio, MFC, Dev
|
|
Advanced Search Add to IE Search |
|
|
|
||||||||||||||||

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.

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!
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.
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:
|
|
|
|
| @= | @= | (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:

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:



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.
// Set the key so we can go through the subkeys if (m_ntReg.SetKey(csFullKey,FALSE,TRUE)) { // Holds the subkeys of the current key 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".
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"!
NtRegEdit uses some very useful classes/controls found here at CodeProject:
COptGenDlg() - General
COptListDlg() - List control
COptTreeDlg() - Tree control CNtRegEditTreeView class (XListCtrl already had it)
CTreeCtrl
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) OnKeysRefresh() function (I think)
General
News
Question
Answer
Joke
Rant
Admin
Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads.
|
PermaLink |
Privacy |
Terms of Use
Last Updated: 18 Sep 2006 Editor: Smitha Vijayan |
Copyright 2006 by Dan Madden Everything else Copyright © CodeProject, 1999-2010 Web19 | Advertise on the Code Project |