Talk:Windows Registry

Struture - definitions of key / value

I split the Structure section into a Key/Value heading and a Hive heading. Keys and Values need to be better defined and explained - when I was trying to figure out the registry, I couldn't find this basic information anywhere. If you have thoughts on how to improve this section further, please do. --Cedear 16:27, 21 September 2007 (UTC)

Raymond Chen, of Microsoft, just wrote an article on the Registry nomenclature. I believe it describes all the parts in as much detail as is necessary. Ajmastrean (talk) 20:16, 5 February 2009 (UTC)

Notation

I've seen registry values referenced in the form (key path)|(value name). Is this use of "|" widely understood? --203.206.183.160 04:17, 14 July 2006 (UTC)

As far as I know the only limitation on value names is that they can not start with a backslash. Key names, I believe, can contain any character but backslash anywhere in them and must be at least one character long. So a pipe character could (I believe) be used at the start of a value name, the middle of a value name, the end of a key name, etc, etc. I don't think that the notation that you describe would work for all registry paths. You can find some information *in MSDN and there's a grammar that may or may not be correct at the end of *this thread.

MSDN says that a value name cannot start with a back-slash, but it actually can. I have found examples of it in the registry and win32 doesn't care if you use a leading forward slash in a value name. --24.67.212.211 01:21, 20 March 2007 (UTC)

Anyone knows anything about key classes?

I examined the Win32 API, and I found out that every registry key (the thingies resembling directories) has a "class" property that can be read by RegQueryInfoKey function for example. I googled a lot, but I could not find anything that describes what the hell is this.

If somebody knows of a page that describes it, could she post a link here? I could then add this info to the article and reference the link. Thanks.

Wigy 15:39, 6 December 2005 (UTC)

Here's a link to someone else asking the same question. [1]. The consensus among the replies seems to be that it's completely unused at the present time. The documentation quoted says that there are no such classes defined, so there isn't much point in adding any info. Every single registry key in the world has a null string for this property, and no program accesses it (not even regedit!). I think we can safely say it had an intended use at one point in the distant past, made it to the API, and was then abandoned completely.

Me 14:55, 10 June 2006 (-8)

The class attribute is used in odd places. How it is used I don't know. Here's this: [2]. Good luck.

Raymond Chen, of Microsoft, recently posted on the Registry and it's parts/nomenclature. He is an expert and declares "There's also this thing called a class. I have no idea what it's for, so don't ask." Ajmastrean (talk) 20:18, 5 February 2009 (UTC)

Registry Keys?

I've created a section with a list of a few useful keys in it. This might or might not belong here; I hope others will add to it, at which point it might become a useful page in itself. JulesH 00:18, 16 July 2005 (UTC)

I know plenty of useful registry keys (and a few not so useful ones) but I'm pretty sure they don't belong to a Wikipedia article; listing "useful" keys in a how-to way is not very encyclopedic. They could make for an interesting Wikibooks module, though. JRM · Talk 18:22, 19 July 2005 (UTC)

JRM please don't start the whole Deletionist vs Inclusionist thing again.

JulesH I think your idea is wonderful, this is after all a computing encyclopedia as well as a more traditional history and philosophy encyclopedia (if you don't believe me look for yourself - computing far outways many more traditional (boring?) encyclopedia topics.

The mission of this site is to have "free distribution, free editing and wide range of topics"

"Wikipedia's goal is to create a free, reliable encyclopedia—indeed, the largest encyclopedia in history, in terms of both breadth and depth."

Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. That's what we're doing. --Jimmy Wales, Wikipedia founder

That "sum of all human knowledge" includes the Windows registry (even if everyone in the world should use GNU/Linux ;)

Zeth 19:32, 27 July 2005 (UTC) Zeth

"JRM please don't start the whole Deletionist vs Inclusionist thing again." Uhm, again? And how is that even relevant? I'm not talking about deleting the article. I'm not even talking about deleting the information! What I'm saying is:

• What is or is not a "useful" registry key is completely subjective. How is an encyclopedia supposed to decide on this? How's that for the neutral point of view and original research?
• Wikibooks is perfect for this sort of endeavour. Game strategy guides, cookbooks and yes, registry how-tos all find their place there. It was created for this sort of thing.
• Jimbo's quote could be taken to mean "Wikipedia should include anything anyone could ever write down". But Jimbo didn't mean that. His quote shouldn't be taken literally, or there would be no guidelines at all as to what Wikipedia does and doesn't include. There are, however, things that Wikipedia is not.

Incidentally, please don't split up discussion in a "yes" and "no" side. This is highly unproductive because it emphasizes difference and disagreement, rather than focusing on reaching consensus. JRM · Talk 00:48, 31 July 2005 (UTC)

Registry keys

I actually think that a seperate article could be created that deals with a lot of Windows registry keys. Especially in HKEY_CLASSES_ROOT. That's just my $0.02. - Ta bu shi da yu 07:41, 5 October 2005 (UTC)

== Deleted external link to: "Inside the Registry (article by Mark Russinovich of sysinternals.com)" because it requires subscription to see the artitcle. 192.171.10.24 21:46, 5 January 2006 (UTC)

Registry edit blocking

Iv been using spybot to block most application from editing(it usually asks when i install things) the registry and i was wonder what the effect would be? I have not noticed any changes. Is this a safe thing to do and should this be in some way included in the article.--Whywhywhy 12:26, 28 January 2006 (UTC)

It just blocks known keys used by spyware and adware, such as the Internet Explorer start page. It does not block registry editing in general. That would not be very productive ;)... Lofote 12:30, 26 June 2006 (UTC)

Added Sections for HKEYs

• More modular and easier to reference to a subsection of this topic from other articles.
• If one section expands too far such as HKLM this could be seperated into its own topic easily. SNIa 17:42, 18 February 2006 (UTC)
• Cross references are made to each HKEY section from the Windows NT Startup Process
• HKCR
• HKCU
• HKLM
• HKU
• HKCC

Corrected HKCR Entry

HKCR is a compilation of HKCU\Software\Classes and HKLM\Software\Classes not only on XP but also 2000 and 2003 server. Important detail for anyone trying to write something into this key that needs to be accessible to another user!

Section: Problems with Windows 9x OS

--207.81.225.190 23:52, 10 June 2006 (UTC)

On Windows 9x computers, an older installation can have a very large registry that slows down the computer's startup and can make the computer unstable. This has led to frequent criticisms that the registry leads to instability. However, these problems occur far less often on the Windows NT family of systems, including Windows XP.

I don't see that the above is all that valid.

The speed of the registry has improved from 9x to XP. 9x uses LI structures to index its keys. These structures are just a list of file offsets within a registry hive. NT/2k/XP use LF and LH structures, which contain hashes of the subkey names. In order to look up a record under 9x one has to read subkeys from disk, a slow process. Under NT/2k/XP one can first check the hash in the index and, if it matches, then look up the subkey and check for a match. The LF/LH method is a lot faster than LI. Also, NT disk access is far more effecient than that of 9x.

Though the speed of the registry has unquestionably increased I would argue that registry-related stability issues have actually increased in number and severity in NT/2k/XP, especially XP. Aside from the LF/LH (and RI, different story) registry keys very little else has changed in the binary structure of the hive database.

NT/2k/XP certainly have a more stable kernel. That combined with NTFS would, I would think, lead to less hive corruption resulting from filesystem corruption. However I have only rarely run into binary registry corruption that has been so severe as to be difficult to recover from. Most of the registry-related stability problems that I have experienced have been a result of the data stored in the registry and not the registry itself.

The complexity and importance of the data stored in the registry has grown massively since 9x days. I find that issues with bad software/bad drivers or improperly loaded software/drivers is far worse in more modern Windows OSes than old ones. Note that I am not talking about overall system stability, just stability that pertains to settings in the registry.

Anyhow, NT kernel == more stable; NT filesystem == more stable, faster; NT registry speed == faster; NT stability specifically from registry issues == I would say worse, other would say otherwise. I would say that the grand sum total of the "Problems with Windows 9x OS" section along with what I have written ammounts to about squat. I would have just removed the section, but I don't like to just delete things out of the blue.

Lofote 12:34, 26 June 2006 (UTC) Having to start a lot of programs at startup slows down the computer. This is correct for all Windows systems, as it would be on Linux and anything else - easy formula: Much too load = slower too load. This has nothing to do with the registry, except that the apps to autostart are enumerated in the registry. But it would not be different if that information came from somewhere else, in contrary it would be even slower, because the reading of this information from an indexed registry is faster. Lofote 12:34, 26 June 2006 (UTC)

207.81.225.190 19:58, 14 August 2006 (UTC) I never said anything about system startup speed relating to registry implemenation. I was commenting on changes in system stability between 9x and NT due to their registry use. I probably shouldn't have mentioned speed at all as it was a bit of a red herring. The hashed structures in newer registry implementations do improve access speed to keys with lots of subkeys. In cases where one has to repeatedly traverse through keys with lots and lots of subkeys the speed issues do become significant.

Win32 API?

This doesn't make sense: Both are "written for the Win32 API" so where is the difference?

• REGEDIT.EXE was written for the Win32 API and supported right-clicking of entries in a tree view to adjust properties and other settings.
• REGEDT32.EXE was written for the Win32 API and required all actions to be performed from the top menu bar.

—Preceding unsigned comment added by Lofote (talk • contribs) 26 June 2006

That was a change introduced in this edit by User:Yuhong last year. I don't know enough about Windows programming to comment further. Anyone? —mjb 23:21, 25 July 2006 (UTC)

Hello, I've found the Microsoft Support page that is relevant to your questions and doubts; sorry I can't check and edit the article, I'm pretty busy with Pink Floyd related articles for now.Cheers.--Doktor Who 21:58, 30 July 2006 (UTC)

The article seems to have it right now. In pre-XP Regedit.exe is easy to use, but has some ugly shortcomings (.reg files don't store classes, no way to modify access control). Regedt32.exe is a pain to use but is reasinably complete. Both of these programs use the win32 registry API. I guess they've added the missing features to regedit and dumpted regedt32 in XP. I don't have access to an XP box right now so I can't confirm.

On my machine when I run Regedt32.exe, it closes and brings up regedit.exe I can see in the process list of task manager, is supposed to be normal, I do have full admin rights. —The preceding unsigned comment was added by 71.131.134.213 (talk) 05:38, 19 February 2007 (UTC).

"^ Microsoft's Windows 2000 Security Hardening Guide version 1.3, published May 15, 2003, says "It is highly recommended to use regedt32.exe (a.k.a. the Windows NT registry editor) and not regedit.exe (a.k.a. the Windows 95 registry editor) to modify registry settings. Both editors ship with Windows 2000 and regedit.exe is generally perceived as easier to use. However, regedit.exe does not support all the registry data types and will convert certain types it does not understand. Certain values will not be read properly if they are converted and this can cause serious problems with the system, including failure to boot."

".. In Windows XP and Windows Server 2003, Regedt32.exe is a small program that just runs Regedit.exe."

So um I don't understand, run regedt32 instead of regedit so regedt32 can start regedit?? It sounds like a big contradiction to me. —The preceding unsigned comment was added by 71.131.134.213 (talk) 05:46, 19 February 2007 (UTC).

Prior to Windows XP regedit.exe was easy to use, but broken/incomplete. regedt32.exe, on the other hand, was more complete but had a horrible interface. Microsoft fixed regedit.exe and dumped regedt32.exe for XP. In XP (and Vista, I assume) regedt32.exe has been replaced with a dummy program that runs regedit.exe.--24.67.212.211 21:30, 16 March 2007 (UTC)

regedit and regedt32 are different on vista x64. regedt32 shows some entries that do not appear in regedit. —Preceding unsigned comment added by 24.131.238.27 (talk) 18:33, August 24, 2007 (UTC)

Policy files

Since Windows 95, administrators can use a special file to be merged into the registry, a policy file. The policy file allows administrators to enforce registry settings such as preventing users from changing the background picture of the desktop. The default extension for the policy file is .pol. The policy file filters the settings it enforces on a per user basis and per user group basis. To do that the policy file merges into the registry, preventing users from circumventing it by simply changing back the settings. The policy file is usually distributed through a LAN, but can be placed on the local computer.

Actually this is not correct. Policy files do not prevent changing settings back at all within the current session (they will be reoverwritten at next logon/startup. On Win9x based system the only way to ensure those settings are not set back is to ensure that absolutely no way exists to open regedit, apply a reg file or any other program that can chance it back. On locked down Win9x systems this usually means disabling 99% of the Explorer interface incl. open/save dialogs of most applications, otherwise there will be a way to set it back. On Windows NT-based systems this is a bit different, because the HKCU\Policies keys are non-writable for users. Policies enable administrators to write information there, the users (and even a triggered login script by the admin) are not able to change values there. However any policy that is not inside the protected HKCU\Policies key (or HKLM of course) is open for editing by the user. That is why there are two locations for many options: one inside normal HKCU keys and one for the Policies. The second one is by default unset, as soon as there is a value there, the first one is not used at all. So HKCU\Policies configuration gets a higher priority if existing by Explorer and most of the Windows shell programs. (Such a behaviour must be explicitely supported by the application however). In similar cases -when user-dependand config is not required- both a HKCU and a HKLM configuration key exists, working the same way. Lofote 10:19, 30 August 2006 (UTC)

Can one select multiple keys and change permissions to all of them at once ?

Useful, as some registry cleaners report bad enties that can't be deleted due to permission settings. Of course these nice programs report that they deleted those entries, just to come up with them in the next scan. There are progs (registry finder for - random - instance) that allow selecting multiple keys, but only to "delete" them (with or without quotes, depending on permission settings), not to edit their permissions. Probably one could come up with a piece of code that could do that - I am not into progamming at all. The Ubik 17:44, 22 September 2006 (UTC)

The answer is probably "Yes, if you're prepared to go through a bit of effort."

Since you'll most likely need a completely custom solution, you'll probably have to implement it yourself (doing a websearch aforehand wouldn't hurt though). Learn the basics of a programming language (must be able to make Win32 API calls) and download the Platform SDK and prepare for debugging in the wee hours of the morning...

So's to get you started "Registry Key Security and Access Rights" in the Platform SDK seems an article that may apply. You'll probably need the function "RegSetKeySecurity". Hope this helps... Shinobu 01:18, 23 September 2006 (UTC)

Take a look at subinacl.exe (you can download it from microsoft). It provides a command line interface to windows file and registry (and I think some other things) permissions. The interface is horrible, but once you've figured it out once then you can make a batch file to set permissions on whatever part of the registry/filesystem you like.--24.67.212.211 21:33, 16 March 2007 (UTC)

A book on registy hacks

What about writing a book on registry hacks. Just the hacks bothing about the history etc whatsoever. Anyone interested? --seXie^♭♭_c 08:20, 17 November 2006 (UTC)

HKEY_DYN_DATA

Where's this section? At least we must mention it. MrFirewall 13:50, 16 January 2007 (UTC)

Improving the description of what's in HKCU

HKEY_USERS contains subkeys corresponding to the HKEY_CURRENT_USER keys for each user registered on the machine

Perhaps "registered on the machine" could be changed to something more specific. According to this Microsoft KB article HKEY_USERS "Contains all the actively loaded user profiles on the computer". That's clearer -- "registered" could be misunderstood as defined rather than defined and active. —The preceding unsigned comment was added by 59.144.1.19 (talk) 06:31, 29 January 2007 (UTC).

Vista's Registry

This article needs to be updated to include the location of the Registry on Windows Vista. Cobalt2020 22:07, 7 February 2007 (UTC)

Command line Editing of Registry

Original text..

Command line editing

On NT-based ** systems the registry can be manipulated from the command line with the reg.exe utility. It is included in Windows XP and can be downloaded separately for previous versions. ---

Revised to include Windows 98 as a system type.

74.116.173.139 18:11, 27 February 2007 (UTC)

Restored links

I undid an edit that removed a number of extremely useful links. If the "Low-level Registry and SAM Information" link isn't a good reference source then I don't know what is. --24.67.212.211 19:47, 14 March 2007 (UTC)

Capitalization of Registry

Does anyone know why this article is uncapitalized, as in "Windows registry"? Windows Registry, as in "the" Windows Registry is a proper noun in every sense of the word.

As similar examples, compare "Microsoft Word", "Internet Explorer", and "Windows Update". These are all proper nouns, as these describe a specific product, not a typical word, explorer, or update. Similarly, Do Not Call Registry describes a specific registry, as does Massachusetts Registry of Motor Vehicles. As a counter-example, domain name registry generically refers to any organization that maintains such a registry. Reswobslc 02:31, 30 March 2007 (UTC)

fixed Lyml 19:46, 25 April 2007 (UTC)

Erm... Not quite. Currently the capitalization between the title, the lead, and the rest of the article is inconsistent. Shinobu (talk) 00:02, 1 September 2008 (UTC)

{098f2470-bae0-11cd-b579-08002b30bfeb}

Dirty old clsid's. Now, it is possible that the registry is compressed in some way that these clsid's aren't wasting ridiculous amounts of space, but I don't believe that's the case.

CLSID's are stored as strings, there are six characters ({,-,-,-,-,}) that are common to all of them, and the remaining characters are always one of (0-9) or (a-f), so it works out about 5x the size it needs to be, resulting in an inefficient database etc..

I'm not saying CLSID's are a bad idea, just that they're stored inefficiently, and that I should never have to look at them.

If someone wants to incorporate that rant... Open to feedback T boyd 22:20, 27 April 2007 (UTC)

Registry Structure

...typically look up their settings by first checking for them in "HKEY_CURRENT_USER\Software\Vendor's name\Application's name\Version\Setting name", and if the setting is not found looking instead in the same location under the HKEY_LOCAL_MACHINE key. When writing settings back, the reverse approach is used — HKEY_LOCAL_MACHINE is written first, but if that cannot be written to (which is usually the case if the logged in user is not an administrator), the setting is stored in HKEY_CURRENT_USER instead.

Is there a citation for this comment? I'm not sure this is entirely accurate. HKLM is per-machine settings and HKCU is per-user settings. An application may, indeed, write settings as described above, but that's not fitting with modern security practices, especially Microsoft Best Practices. Attempting to write a system-wide setting (HKLM) first just because you can (instead of writing to the admin's HKCU hive) seems like bad coding and not how the registry was intended to be used. In the above scenario, HKLM should be the "default" setting and HKCU should contain user preferences that differentiate. In this case, HKCU would be written to no matter what access you have, not HKLM. HKLM would only be written if the default values were to change. But I don't find this scenario to be "typical" to me at all. In my experience, HKLM is only written to when a setting is system-oriented (OS related, installation related, things the user shouldn't worry about) OR if the program mistakenly believes all users have HKLM write access (many legacy apps do). Whereas HKCU should be used for all user preferences and settings -- things you don't share with other users typically. I rarely see a double-read, double-write scenario as described above. Additionally, if you look at GPOs, for example, even with settings that contain a separate user and machine setting, the machine setting overrides the user setting, which is opposite of what the above statement says. Stating this is typical use of the registry seems suspect to me. Or at the very least, an administrative headache. :-) Thx1200 14:18, 8 May 2007 (UTC)

External Links

I have added links to Chntpw and Hivetools. In the source of these two projects one can find information on the internal binary structures used in registry hive files. To my knowledge these are the two only sources of such information. "Low-level Registry and SAM Information" does not deal with many of the structure of the registry (RI keys, UTF-16 vs ASCII encoding, etc).

Database or Directory?

The introductory line says its a database, but a directory is probably a better definition. I am thinking of changing it, but would like to know others' opinions first. --soum ^talk 13:12, 30 June 2007 (UTC)

It's not really a better definition. Database is pretty darn descriptive: the registry's built like a database, has typical DB-like properties (such as, I think, atomic updates), and is also descriptive of the function, which is to store the configuration data. "Directory" captures the last bit well enough, but I don't think any better than database, and it totally misses out on the first two properties. It also may imply a connection to file-system directories, which is not really correct either (even though the keys are arranged hierarchically). I would consider that change to be incorrect/losing information enough that I would probably change it back. EvanED 04:57, 7 August 2007 (UTC)

I sometimes find it amusing how antique threads are woken up. :) Anyways, registry does *not* provide transactional access by itself. It is provided by a wrapper API, TxR, which is present only in Windows Vista. IMO, describing registry as a database is too generic a definition (can you do set operations on it?), rather its better described as a directory (not the file system directories, rather the Active Directory type), which by definition is a specialized database and specifically suggests the purpose of registry. In that sense, it provides a more concise definition. The only catch is that registry doesn't have a read-mostly limitation (though config uses are so). --soum ^talk 06:34, 8 August 2007 (UTC)

Updates are atomic (without TxR) in the sense that if two processes try to update the same value or key simultaneously, the updates will serialize. I didn't really intend to suggest you could do full-fledged transactions, though I wasn't very specific about what I said. I will back off of what I said before though, at least if the directory (databases) article is linked. I still think "database" is a more useful term to use for the introduction, but I wouldn't revert the entry if it were changed. EvanED 00:41, 10 August 2007 (UTC)

This article which quotes the Microsoft Computer Dictionary defines it as a database. :) Also, a Google search of this type brings up "database" in most of Microsoft's definitions. —Preceding unsigned comment added by 221.128.180.172 (talk) 18:44, 31 March 2008 (UTC)

What is a filesystem but a hierarchical database? "Filesystem" and "Database" are not very strictly defined. There is a great deal of overlap between the two. I am not aware of anything in any definition that prevents a filesystem-like-system that enforces certain formatting of data to be excluded from the filesystem label. Even if that is the case the format of data stored in values in the registry is very, very minimally enforced. As far as the win32 api is concerned the only formatting to be enforced in registry values is the length. One can store completely invalid UTF16 in a UTF16 value. The other types (I don't know about links) are just binary strings, length-enforced in the case of WORD types or otherwise not.

As far as I can see the statements "the registry is a filesystem" and "the registry is a database" are both correct.

142.179.217.154 (talk) 06:41, 29 April 2008 (UTC)

Registry Cleaner

They deserve some mention, and the article needs attention. Shunted a see also section in there, feel free to put the link wherever it makes sense. Jesus Carp 22:41, 20 July 2007 (UTC)

I don't think that registry cleaners should have an entire section. I would be worried that a section such as this would really be a platform for reg cleaner advertisements. —Preceding unsigned comment added by 75.111.41.242 (talk) 12:47, 6 April 2008 (UTC)

I agree. Giving registry cleaners a section dedicated to them is not a good idea. However, I think that if a particular product provides a solution that cannot be acheived with Microsofts provided toolset and is somethine people would required then it should qualify for an honourable mention.

--DoggyDude96a (talk) 16:40, 19 March 2009 (UTC)

Note that HKEY does not stand for "hive key"

It stands for 'handle of key', in the Windows style of prefixing handle types with 'H'. Examples include HWND for window handles, HPEN for pen handles, etc. —Preceding unsigned comment added by 124.187.9.246 (talk) 06:16, 2 September 2007 (UTC)

Assessment of Microsoft registry usage

"The Windows registry was introduced to tidy up the profusion of per-program INI files that had previously been used to store configuration settings for Windows programs.[1] These files tended to be scattered all over the system, which made them difficult to track." The part "which made them difficult to track" seems to be a positiv assessment of the registry. But the port from one server to another of the registry is not easy and the current usage of the registry make it impossible to transfer between 32- and 64-bit windows version. Most ".ini" datas could be transfered without problem, if the "not operation system" related informations would be stored in ".ini" files.

It seems to better to delete the "which made them difficult to track" part or to write "which made them difficult to track, but easy to port between different servers.". —Preceding unsigned comment added by 195.145.45.7 (talk) 17:32, 8 November 2007 (UTC)

External Link

Would anyone mind us adding an External Link? We produce a Windows Registry Editor that is better than the standard windows RegEdit, and extends its features. I notice there is already a link to Windows Registry Wizard, but I prefer to ask before invading someone's page. Simoncraythorn 13:05, 9 November 2007 (UTC)

Fair use rationale for Image:Registry Editor Vista.png

Image:Registry Editor Vista.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot (talk) 20:11, 26 November 2007 (UTC)

Alternatives?

There is no reason to have "alternatives" from other operating systems listed since they can't be used on Windows, and thus are not really alternatives. It doesn't add to the article's value, and it sounds biased against Windows. The article is not about which operating system has the best registry, it's about the Windows Registry and how it works.Entbark (talk) 17:56, 10 January 2008 (UTC)

I disagree; I think it puts the article more in context to see what the analogue to the registry on other OSes is. If you think it sounds biased against Windows (and I do agree, the OS X paragraph did sound a little biased), the solution is surely to reword to eliminate the bias; not delete the section! -- simxp (talk) 18:33, 10 January 2008 (UTC)

I definitely see where you are coming from, but I also agree with Simxp. Can you suggest another article where the information in that section would fit better? If so, we should put it there, and link to it. If not, I suggest it be reinstated in this article. EvanED 21:15, 10 January 2008 (UTC) —Preceding unsigned comment added by EvanED (talk • contribs)

It would be more informative in a comparison of the operating systems, or in a generic registry comparison. Since Windows is such a large percentage of the market, it's not very likely that people coming to this page are going to be looking for a comparison, especially with AIX, Elektra, or RISC. There are most likely hundreds of registry systems, but this page isn't the best place for them. Entbark (talk) 22:21, 10 January 2008 (UTC)

I disagree. Windows Registry is probably the most known example of configuration databases. People (including me) would begin here if I wanted to research to subject – not in comparison of operating systems. If we created an article about config databases I would agree to move much of the data in the section there and have a short section in Windows Registry which links to "Software configuration database" (or whatever). I have reintroduced the section under a new name so it does not get lost in history during this discussion. Jeltz talk 20:29, 24 January 2008 (UTC)

I don't know what you're disagreeing with. What I am saying is that this article is about the /Windows/ Registry, so there should not be a section about other registries. Other articles do not list non-notable alternatives, so I don't see why we should change the rule for this one article. And if they are notable, they should get their own article rather than being listed here. I'm not going to start a revert war, so I'd like other people to give input so we can resolve this. I like your idea of creating a software configuration database article though. Entbark (talk) 22:31, 24 January 2008 (UTC)

This does not change any rule since there are lots of articles that provide a context by briefling mentioning other similar things. The section should be kept short though untill we get a general file for configuration files. Jeltz talk 23:39, 26 January 2008 (UTC) (Ajay Kumar Jha)

I would point people at [[3]]. It is not clear that the windows registry is a full Configuration Management Database, or at least it lacks some common features of many other products. A key one is auditing and rollback: who changed the registry, can we undo it? The registry encodes the state of a windows OS, but does not remember how it got there. We should not be comparing the registry directly with other operating systems, but with other Configuration Management technologies. SteveLoughran (talk) 22:27, 22 May 2008 (UTC)

"Richer datatypes" and "Separation of machine configuration from user configuration."

These entries in the Advantages section are both hogwash.

The separation of machine and user configurations have nothing to do with the use of the registry, they are properties of the filesystem. This functionality is no different than if test-based file configurations were stored in system32/config and in %USERPROFILE%.

"Richer datatypes" can be stored in the registry than can be stored in a text file? Try as I may I cannot find any documentation on measuring the "richness" of data. I am pretty sure that anything that can be stored in the registry can be stored in either xml or sql (thought the latter generally isn't used to store software configurations).

If there are no objections I would like to remove these.

142.179.217.154 (talk) 06:06, 29 April 2008 (UTC)

No objections. But please try to find some references for the advantages/disadvantages section if possible. : ) I think whoever added that point is trying to stress the advantages of registry over the particular Windows INI file format limitations (see here) -xpclient (talk) 07:29, 29 April 2008 (UTC)

The word "rich" as used to describe APIs or data types is pure marketing speak. It doesn't describe anything either from a pure capability-point of view or even from a comparative one. It should be avoided as much as possible. Instead the data types recognized natively by registry should be mentioned. Plus, the type system is hardly "rich". It just supports strings, ints and booleans. Compared to a programming language, or even Active Directory, the type system of the registry lies below poverty line. :-p --soum ^talk 10:22, 29 April 2008 (UTC)

The Registry is being compared, albeit implicitly, to the legacy INI files that it replaced. So rather than deleting, please clarify the comparison. Ini files were stored by default in the Windows directory (not a user location, hence the requirement for IniFileMappings to allow legacy apps to work on newer versions of Windows) The introduction of the user Registry hive also helped make developers start thinking about multi-user machines, i.e. separation of user vs machine data. Socrates2008 (Talk)

I would say that the rich data types should stay, perhaps being reworded. Text configuration files can contain... text. If the config file says that a particular parameter must be a number, you write the digits as text. (We'll come to binary files in a moment.) However, there's nothing in the file that specifies that the value is an int; about the closest you can come is something like an XML schema. If you are using an INI-style config (in syntax, not necessarily semantics) the program must do error checking on its own, in case the user says "size = 4zqrFB!". By contrast, in the registry, when you set a vale, you must specify the type, and when you get a value, you receive its type. This is a rather tighter binding than you get even in the XML case, which is already much stronger than most configuration files.

Over binary files some of these advantages apply; some do not. For instance, since every set of bits represents a valid integer, you no longer have to check for malformed input like my 4zqrFB! example (though you might have to check it is within a range). However, without writing explicitly into each application there is still no tag that says "the following four bytes constitute a 2's complement, big-endian integer". EvanED (talk) 21:18, 29 April 2008 (UTC)

I didn't say remove the mention of "rich"ness. I said, don't use the word rich, rather elaborate the concept of how is is "rich". --soum ^talk 21:51, 29 April 2008 (UTC)

If there is some formal definition of "rich" that involves type enforcement and avoiding parser errors then it should be cited. If the registry has advantages over parsers dealing with malformed text files then that is what should be stated (and cited). I removed the "richness" line as I am convinced it was meaningless. 142.179.217.154 (talk) 03:02, 30 April 2008 (UTC)

No rich isn't formally defined. Thats why I say, don't use something that is quantifiable. Rather directly list the what else the registry offers over .ini files or probably even a three-way comparison of reg, ini, and xml files (like Raymond Chen did). --soum ^talk 03:46, 30 April 2008 (UTC)

What is rich for the app (say a C/C++ struct saved as a binary string) is not always rich for the end user, as you now have some binary code that is unreadable, unwriteable and can only go wrong. Even ini files could store binary content in some form (base-64 encoding is common in XML formats), but its not always clear that they are a good idea. I would argue for saying "can store binary content" rather than rich, as rich implies better than poor SteveLoughran (talk) 22:23, 22 May 2008 (UTC)

"Rich" in this context is a comparison to the text-based INI files that preceeded the Registry, in which only textual data could be saved. Yes, you could store an integer, byte or float as a (text) number in an INI file, or even a binary blob by MIME-encoding it, but there was no type-checking around this to prevent the wrong data type being entered in a particular field. Maybe if XML schemas had been around in 1995, they would have gone that way instead to enforce type checking in the underlying text file (while maintaining human readability), but they weren't so it's moot. Socrates2008 (Talk) 07:19, 23 May 2008 (UTC)

.REG files are an advantage of the registry system? Surely the .REG file is just a way of being able to do with the registry what you can do with text based config files. Nothing equivalent to the .REG file is necessary in a text-config based environment. It exists purely to provide the convenient functionality in the registry environment. Thus it's not really an advantage of the system, rather it's a good way of overcoming one of the inherant disadvantages. —Preceding unsigned comment added by 82.5.180.44 (talk) 08:34, 5 September 2008 (UTC)

I agree. I would say that .REG files are an incredibly primitive implementation of "diff -Naur" and "patch". Were .REG files to have the functionality of sql then I would say that they would count as an advantage against .INF files (that IS what we are considering the advantage as being against, yes?). I *guess* that .REG files are an advantage against .INF files if one confines oneself to the limited text-processing capabilities of the win32 environment...but that is a pretty sad example of an "advantage". —Preceding unsigned comment added by 75.152.173.147 (talk) 07:11, 22 September 2008 (UTC)

Registry Filtering

One other feature of the registry is that you can write kernel-side drivers that get told when registry entries change. This is called Registry Filtering and is documented in MSDN [[4]]. This offers some interesting use cases

• Anti-spyware/virus apps can monitor bits of the registry to catch when they change, rejecting the change or warning the user.
• Device drivers can be driven by changes in the registry. A user-side GUI app can present the current settings and offer a way to change them, it then saves the changes to the registry which are picked up there and then.

To do something similiar with text files is much trickier. On windows you would need to write a file system filter driver or just poll the file regularly (very inefficient). On unix systems you'd add a new file in /dev that would be read/written; the driver would need to handle the writes. SteveLoughran (talk) 09:30, 23 May 2008 (UTC)

Or just use a file change notification. Socrates2008 (Talk) 10:56, 23 May 2008 (UTC)

Parsing?

In the pros/cons section, there's this line: "Since accessing the registry does not require parsing, it can be read from and written to more quickly than a text file can be." Depending on what is meant by "parsing", this statement makes no sense -- the Windows API has special functions to read and write legacy INI files, and those are on a technical level much simpler to use than the registry is. It would only be difficult if you wrote your own parser, and even that is not exactly a rocket science. --82.157.222.173 (talk) 20:36, 30 August 2008 (UTC)

If you're only storing strings it makes no sense. But for accessing other things, like numbers, or binary data, are easier in the registry. The registry can store arbitrary data -- not just text. Billyoneal (talk) 23:17, 20 August 2009 (UTC)

Degraded performance over time

The complexity of data structures contained in the registry ensures premature fragmentation and is a deliberate attempt by Microsoft do ensure predictable degradation of the performance of a computer, encouraging users to upgrade. Upon analysis of the design of Windows, starting from Windows 95, this is the only reasonable logical deduction which can be made. —Preceding unsigned comment added by 41.243.6.182 (talk) 22:14, 19 October 2008 (UTC)

A conspiricy theory there I feel, but arguably true. Consider though, that with the progressive improvement of computer hardware and periperals by manufacturers that Microsoft don't really have any need to push people to upgrade? Hardware and demand for increased performance does this automatically for them. Even if this wasn't the case, Microsoft has not marketed a new OS (to my knowledge) to be of "Greater Performance" than their previous OS offerings. Sales are based on useability improvements, new hardware support, new features etc.

It can been seen to be true that Windows can degrade in performance over time with use. However, it can equally be demonstrated that a properly configured / locked down system will perform consistantly. In other words, all performance degredation can be seen to be a property of change through usage. —Preceding unsigned comment added by DoggyDude96a (talk • contribs) 16:57, 19 March 2009 (UTC)

Even if that was the case, you still have not proven that it's due to a fault of the registry. Registry "Fragmentation" has more to do with on disk fragmentation -- the physical files can become fragmented. But that's not relevant to this article. I have removed the comment Billyoneal (talk) 23:16, 20 August 2009 (UTC)

Registry damage & booting

There are many different system files whose corruption can cause a system not to boot, which is why fingering one particular file (containing a registry hive) does not make sense here. However if you are refering to someone inexperienced or careless loading up Regedit and putting garbage into the Registry or deleting something important (i.e. bad data, not corruption of the underlying file on disk or internal file structure), then that's a different story. This is preceisely why every Microsoft KB article with a Registry workaround in it carries a warning. So maybe "damage" is the wrong word to use here as its too ambiguous. Socrates2008 (Talk) 20:55, 24 October 2008 (UTC)

I agree wholeheartedly about the file corruption issue, but the fact remains that it's easier to recover from say, a single damaged DLL file than to recover from a damaged registry hive like NTUSER.DAT. I wasn't referring to corruption from bad entries in the registry, I was thinking about the actual binaries becoming corrupted. Admittedly that's a rare occurrence nowadays, but it does happen sometimes. I suppose the idea that the person who originally put that in was trying to convey is that it's difficult to deal with a binary file gone bad, while on *nix for example, they're all simple text files that can be edited easily. As well as the registry does work 99.999% of the time, that's a definite weakness inherent in the design. Maybe we should try to convey that "feeling"? I'm not sure. §FreeRangeFrog 21:22, 24 October 2008 (UTC)

Without getting too picky, ntuser.dat is a user-specific file, so will never prevent booting. The SYSTEM, SOFTWARE and SECURITY hives on the other hand... System restore has improved the game since earlier versions of Windows, but yes, it's more complicated than *nix. Socrates2008 (Talk) 09:55, 25 October 2008 (UTC)

Agreed. I've been thinking about how to better express it without much luck. It either comes out as apologism or "lol ms sux"... :( The reality is that it's nowhere near the problem that most anti-Windows people make it out to be, especially since NT4 (which by god, was 1996). Fell free to nuke it, I'd rather it was just omitted rather than leaving it half baked in there. §FreeRangeFrog 01:50, 26 October 2008 (UTC)

I've added an explanation and toned down the comment. Billyoneal (talk) 17:09, 12 October 2009 (UTC)

"Equivalent" section

I'm concerned that the section on "equivalents" to the Windows registry misstates and encourages misunderstanding of the primary principles behind the registry. Namely, the section pretty much implies that the *nix etc directory is the "*nix equivalent" of the registry. This cannot be further from the truth. Yes, /etc is the traditional location of config files (and ~/.foobar is traditional for single-user app configs), but this is not a registry, strictly speaking. The prime distinguishing factor of the Windows registry is that it is a big binary blob of config keys. This is conceptually different from a text-based system of (tending) to stick plain-text config files in a designated directory. gconf is the closest thing to a Windows-like binary "registry" that exists on *nix, but even that is a stretch to call a registry. —Preceding unsigned comment added by 66.188.100.22 (talk) 23:37, 19 May 2009 (UTC)

Agree the comparison of the underlying technology (database vs flat files) does not match up, however their purpose is the same, isn't it (storing configuration data)? Also, it's worth remembering that the Registry on Windows evolved because of limitations of .INI files, which are very similar to *nix. Lastly, the new model for .Net applications is an XML configuration file, not the Registry. Socrates2008 (Talk) 07:51, 20 May 2009 (UTC)

Another fact is that many of the advantages listed in the "advantages and disadvantages" section also apply to *nix way of using files for storing settings. I suggest that maybe these sections are merged or something to make this clear, and to compare windows registry vs ini files vs *nix conf files. —Preceding unsigned comment added by 78.91.52.167 (talk) 12:53, 20 May 2009 (UTC)

First unsigned comment was me. Just made an account. I was a bit unclear agove. The two systems (registry style and /etc style) are similar in intent but different in design principle. As for merging the "equivalents" section and "advantages/disadvantages" section, that crossed my mind but it might be a tough job. Seems that there are two separate but related issues with regard to advantages vs. disadvantages: Windows registry configuration (binary database) vs. use of .ini files in Windows, and Windows registry configuration vs. system-wide use of plaintext configuration in other systems. They seem to be separate issues more because in *nix systems, the entire system uses plaintext files not only to configure individual apps, services, and daemons, but indeed init scripts in /etc are needed to boostrap the system itself (admittedly the bootstrapping function of scripts in /etc is a different matter entirely compared to the configuration function of files in /etc). HobgoblinOfLittleMinds (talk) 22:51, 20 May 2009 (UTC)

GUIDs

GUIDs have nothing to do with the registry. While the registry does often contain these (particularly under HKEY_CLASSES_ROOT\CLSID), they are placed in there by the Component Object Model, and are not inherently part of the registry. COM just chooses to dump it's data in there that way. Thus, this disadvantage lies with COM, not the registry itself. I have removed this claim from the article that GUIDs are a disadvantage. Billyoneal (talk) 04:38, 16 September 2009 (UTC)

I have once again been forced to remove a reference to GUIDs. Billyoneal (talk) 00:06, 3 February 2010 (UTC)

Comments

I was surprised that the word 'comment' does not occur once in the article. After a lucky google query, according to short article, and according to my own tests, it is possible to write comments inside reg files. The special character is a semicolon (;), it may be placed absolutely anywhere after the initial version definition, and affects the rest of the line. Someone might want to include this piece of useful information in the article (the ".REG files" section perhaps?). Theultramage (talk) 12:08, 16 September 2009 (UTC)

That's because WP is not a manual. Socrates2008 (Talk) 21:38, 16 September 2009 (UTC)

Plagiarism

http://www.error-repair-pro.com/faq.html

Look at the "What is Windows Registry?" question —Preceding unsigned comment added by 117.201.112.206 (talk) 15:06, 18 November 2009 (UTC)

It's not clear who has copied whom, but we could reword here anyway to improve the description. Socrates2008 (Talk) 20:24, 18 November 2009 (UTC)

Additional links

The follow link contains an alphanumerical list of known registry class ids. This link might be worth adding to the lisk of links.

http://markhobley.yi.org/mswin/registry/keys.html —Preceding unsigned comment added by 92.232.150.252 (talk) 01:14, 4 January 2010 (UTC)

Additional link (article development info maybe? - needs verification)

I was searching for data on Windows Registry file format and, while the information is scarce, this location seems to shed some light on the topic with data (claimed to be) gathered - still needs verification, because I am not an expert in the field. However, if it turns out to be correct, I think it would be appropriate to include it at least in the links section.

http://www.sentinelchicken.com/data/TheWindowsNTRegistryFileFormat.pdf

IrekReklama (talk) 00:53, 22 January 2010 (UTC)

"registry" or "Registry"?

Even if the use of Registry/registry would be different when used as a noun and as an adjective this article is inconsistent wrt. use of Registry or registry.

What is the correct case?

Is it different when used as a noun and as an adjective?

--Mortense (talk) 02:56, 13 February 2010 (UTC)

Classes used in roaming profile

In section 1.2.1, "HKEY_CLASSES_ROOT (HKCR)", I think the last sentence is wrong; it currently reads: "The user-specific classes hive, unlike the HKCU hive, does not form part of a roaming user profile." I believe HKCU contains the user-specific classes hive; specifically, I believe the user-specific classes hive is HKCU\Software\Classes. Perhaps this sentence is supposed to say, "The machine-specific classes hive, unlike the HKCU hive, ..."? 64.175.137.69 (talk) 19:19, 2 March 2010 (UTC)John Schroeder

Nope, the article is correct (look under HKEY_USERS for the two hives loaded for every user, or scan a user profile for Ntuser.dat and UsrClass.dat) Socrates2008 (Talk) 09:58, 3 March 2010 (UTC)

Reorganize Advantages and Disadvantages section into a Rationale Section (up front) and a Criticisms section (at the end)

The "Advantages and Disadvantages" section was tagged with the suggestion that its content be integrated into the article. I've integrated the "Pro" points into a new Rationale section that explains the evolution of the registry from the simple .INI files that preceded it. Please contribute to this new section. One point from the Pros list didn't seem to fit:

• Portions of settings like any subset of an application configuration can be saved in a text-based .REG file, which can be edited with any text editor later. .REG files can easily be merged back into the registry both by unattended batch file or by the user just double-clicking on the file without harming any setting that is not explicitly stated in the .REG file. This is very useful for administrators and support personnel who want to pre-set or pre-configure only a few options like approving the EULA of a certain application.

I've integrated the "Cons" into a new Criticism section. Please contribute to this section, as the current material needs a broader, more coherent view. Ross Fraser (talk) 05:22, 19 June 2010 (UTC)

Readability

This article is very hard, or at least intimidating, to read. Can there be a better explanation of the registry for the average computer user (worried about their system's speed), rather than for programmers or whatever you guys are? Maybe put a new first section saying "Basic Description" or something to that effect.--68.193.135.139 (talk) 00:23, 9 November 2010 (UTC)

If someone is worried about their system's performance, then contrary to what all those dodgy websites are suggesting, the Registry is probably the last thing that's wrong with it. Are you suggesting that we add section talking about myths and scareware like Registry cleaners? Socrates2008 (Talk) 07:52, 9 November 2010 (UTC)

Should I mention

That many "registry cleaners" are scams, and that when you search up "windows registry" every single ad on the left is a scam? 69.136.72.16 (talk) 22:09, 13 December 2010 (UTC)