programming and human factors
by Jeff Atwood
One of the hot new features introduced with Windows 95 was the Windows Registry. The Windows Registry offered a centralized database-like location to store application and system settings. No more plain text .INI files splattered all over your system. Instead, issue a few easy API calls and your application settings are safely nestled away deep inside the registry hive.
But after living with the Windows Registry for more than a decade, I'm starting to wonder if we were better off with those .INI files.
I understand the need to store truly system-wide settings in one place. Let the operating system store settings however it deems fit. The real problem with the registry is that it was exposed to the outside world. Instead of being a secure, central hive for only the most essential and global settings, over time the registry has slowly become a trash heap of miscellaneous junk settings for every rinky-dink application on the planet.
Woe to the poor computer user who naively attempts to manipulate the filesystem without first supplicating to the Registry Gods. Manipulating the filesystem is utterly obvious, completely intuitive, and unfortunately also the fastest way to break an application in Windows. You have to reconcile almost everything you do in the filesystem with that opaque, unforgiving binary blob of data known as the Windows Registry.
For instance, when I upgrade and reinstall Windows, most of the games I have installed on my secondary drive are instantly broken because they store cd-key and (redundant) path information in the registry. The game vendors' support teams will tell you to reinstall all your games and patches. Personally, I'd rather search forums and spelunk through the registry to manually recreate the two or three registry keys the game is looking for.
My life would be a heck of a lot easier if per-application settings were stored in a place I could easily see them, manipulate them, and back them up. Like, say... in INI files.
There is an alternative, though. If Windows applications weren't so busy mindlessly piling all their settings on the registry garbage dump with everyone else, they could elect to follow the new, much saner Windows Vista conventions for storing application-specific data:
/Users/Jeff/AppData/Local /Users/Jeff/AppData/LocalLow /Users/Jeff/AppData/Roaming
Local and LocalLow are for bits of application data that are truly machine-specific. Roaming is for non-machine specific settings that will follow the user. That's where the lion's share of the application settings will be. It's all explained in the Roaming User Data Deployment Guide (Word doc). However, these are still user-specific settings, obviously, as they're under the /Users folder. I can't find any new Windows filesystem convention for system level, non-user-specific settings. I suppose that's still Ye Olde Registry by default.
It is possible to write Windows applications that don't use the registry in any way. These are some of my favorite applications. But they're also the most rare and precious of all applications in the Windows software ecosystem.
Over time, it's fair to say that I've grown to hate the Windows Registry. How do I hate it? Let me count the ways:
What's depressing about all of this is how prescient the UNIX conventions are in retrospect. How many billions of man-hours could we have saved by now if some early Windows NT 3.0 or 3.5 developers had decided to turn off public access to the registry, and transparently redirected the public registry API calls so they followed simpler, UNIX-like filesystem storage conventions instead?
there's nothing wrong with the registry. A registry is better than having 10000000000000000 small files.
suc on August 29, 2007 12:48 PMJeff, I'll second the view that game installations intentionally break if you reinstall the OS or parts of it. Part of a brain-dead mentality of making the user keep the install disks, and better yet going out and buying a new set.
In reading all the comments, no one has had much problems with INI files. Wow. I can remember fielding calls from clients who directly edited the files (encouraged by support), and then wondering why the changes didn't work. Then you have to figure out if they deleted a line, put invalid characters in it, or as was often the case had multiple copies of the INI scattered around the file system. I was happy REGEDIT was so hard to use in cases like these.
It's faster for an install to look for specific keys in the registry than the whole filesystem (and possibly network mounts) for previous versions.
Your points are valid, but INIs and XML files have their own faults.
Tim on August 29, 2007 1:02 PMI agree. The registry is obsolete and should be completely replaced.
Orien on August 29, 2007 1:22 PMWell Duh, the registry sucks.
I love Mac OS X's system of plist domains [User, Computer, and the little-used Network] along with MAC-address-tied ByHost plists in each for truly machine-specific settings (Power and Networking, mainly).
Applications can be run from anywhere, but generally can't write to /Library (using ~/Library instead) unless they're in the Applications folder.
Fred on August 29, 2007 1:24 PMCouldn't agree more! In fact, all applications I write use INI-files and not the registry. This is in part because I don't want to clutter my own (or other peoples) registry with application-specific "junk", but also because this way I can copy my application to another computer and still keep all my settings. Couldn't be easier!
Still, I remember back in the good ol' days when I spent time "cleaning" my sys.ini and win.ini files. They weren't all that pretty either :-)
The question we should be asking ourselves is "as software developers, how can we change or fix this"?
Change it? Not until after I retire ;) That easily corruptible registry is job security for some of us.
Of course, I'm kidding.
david h on August 29, 2007 1:31 PMSince the registry API can be re-mapped to anything (e.g. a pile of discrete hives instead of one big clusterfsck), another possibility is to remap an access to HKLM/.../$APP_NAME into one that modifies /Program Files/$APP_NAME/Configuration/app_hive.dat. Admittedly this is a huge simplification (keying off $APP_NAME would require a fair bit of trickery to get right), but I think unbundling the registry would be the single biggest improvement you could make.
Dave on August 29, 2007 1:43 PMChalk me up as another one who agrees with you on this. As a matter of fact one of my first podcasts I did this was part of the subject (1:50). My point was that the mistake made was letting everyone and their brother have access to from what I understand was originally suppose to be the private playground of Windows alone.
http://www.winextra.com/2007/08/16/off-the-cuff-dont-always-blame-microsoft/
Steven Hodson on August 29, 2007 1:46 PMNot a single positive? Like the registry being hundreds of times faster? (This is mainly an issue with MFC apps that like to write out their full settings every time you change one; this leads to painful performance drops in apps like MPC with .ini writing on.) Or enabling hierarchical storage without custom parsing? (XML config files fulfill this need now, but they're tortuously slow for some applications. Not as big a deal as back in the NT 3 days.) And how do you implement organizational policy across random files in random formats, without a standard API, short of enforcing every single setting? Heck, I even use group policy for home use, as it's simpler and more resistant to reversion than direct editing.
Would you really expect more than a few badly-behaved apps to really be that much better with ini files? You can throw your settings anywhere on the system just as quickly as you can put them anywhere in the registry, and I've seen it done many times. Many applications totally mess up the local/roaming, and want to put settings in hidden folders right in your home file, if they even bother with anything but machine settings. Installers are total junk, strewing important files all over, and up until the MSI switch most were still 16-bit! (MSI is worse, since you can be boned trying to remove something by not having the original media available, regardless of registry locations.) Macs have the right idea, with their monolithic folders, but many third-party apps still put per-user settings right in the shared program folder.
The second most common problem with moving files - com servers - can be easily fixed by just reregistering everything in the folder after moving. (for %A in (*.dll;*.exe) do regsvr32 /s %A) You need to modify it a bit on 64-bit OSes though.
I'll grant binary and opaque, although there are ways to read it in *nix now. All performant databases are that way, though.
I would have liked to see the registry split into more files than the big 5 keys, such as one file per subkey of HK*/SOFTWARE, and of course the win9x registries could've been more bulletproof, but that's the only major issue I have with it.
Foxyshadis on August 29, 2007 1:49 PMI have to disagree with this article wholeheartedly. The general registry idea was a good idea, just not as it was designed. Here's how I would have designed it in retrospect:
1. Create logical packages of registry items. Every app creates its own logical area, which is orthogonal to where the keys physically exist in the tree. A package can be simply installed and uninstalled with a single API call, as well as automatically in Windows Installer.
2. Give keys an expiration date and force developers to think about how long they should last. This gives Windows the ability to more intelligently flush things out. Plus, it makes a lot of registry-based dev cases easier (such as timestamp keys).
Kevin on August 29, 2007 1:49 PM"I can't find any new Windows filesystem convention for system level, non-user-specific settings."
C:\ProgramData\Vendor\Application
(or CSIDL_COMMON_APPDATA)
"they could elect to follow the new, much saner Windows Vista conventions for storing application-specific data"
Weren't they Windows XP conventions already?
Joe Clark on August 29, 2007 1:54 PM"10 years... and I'm starting to wonder..." LOL!
Made my day, thanks!
osias on August 30, 2007 2:43 AMI'm not so sure I agree.
As many people have stated here the registry is just a tool which can be abused, but then again any configuration store could be abused. The abuse comes from the fact that many applications change settings that other applications are dependant on, but I would have to say that in many cases that is not something we can get away from.
If we wanted the settings to be one specific value forever then it would be hard coded and not in a config file. The whole idea of config files is that values can change depending on need. So this kind of makes this whole rant a bit obsolete.
Mladen Mihajlovic on August 30, 2007 3:13 AMThe main issue with the registry is that it makes your applications non-portable. As an old Mac user, I miss the days when you could have an app on an external hard drive, take it to a different machine, and run it there.
And the sad thing is, there's *nothing* gained by using the registry that makes up for this crippling loss of functionality. In fact, the registry will accumulate, over time, numerous errors that lead to the need to reformat windows every other year or so (or just resign yourself to the errors).
wkerney on August 30, 2007 3:34 AMI totally agree!
Alastair Revell on August 30, 2007 4:13 AMThe main purpose of the Windows registry wasn't to store application settings in general, it was to store OS settings and application information which can be shared whith the OS and potentially with other applications. This was supposed to be something helpful in order to allow the OS to be aware of the installed applications.
- The original goal makes sense: It allows to increase OS usability (centralized OS settings, uninstall points, known file extensions, etc.).
- However these usability improvements have been accompained with real big drawbacks: Portability of applications, difficulty solving installing/uninstalling/updating problems, reduced OS transparency, and the idea that we have some kind of 'tumour' within our machine which grows without control. However the registry cannot be blamed of all the vulnerability issues just because Windows home users work usually in root mode, this is a cultural problem.
- My point is that all these problems are not derived from the original idea of a 'registry', but from its implementation and use.
Ruben Tous on August 30, 2007 5:10 AMThree letters, XML.
Mac on August 30, 2007 6:21 AMThe Windows Registry was not introduced with Windows 95, it was introduced as part of Windows 3.1 and NT, though most applications (and most of Windows) at the time still used INI files to store configuration data. There were exceptions, which I recall from my early network administration days: Novell WordPerfect, for example, used the Registry previous to Windows 95.
As for whether the Registry was a "good idea," yes, actually it was. The alternative was a proliferation of INI files, which was a horrible idea, even then. Microsoft also had concerns about the integrity of plain text files. Obviously, the Registry got complicated and convoluted, and today it's a mess. But for the time, it made sense, just like floppy disks, CRT monitors, and other technology that seems quaint today. We should be using XML files for configuration data today, I suppose (i.e. proliferating text files). In 20 years, that too will seem silly.
--Paul
SuperSite for Windows
I would have to definately agree with you. Our company has moved off of using the registry to using the application data directories for storing settings in xml.
Tom Anderson on August 30, 2007 8:37 AMInteresting-- Paul Thurrott is right, the registry existed in some form as far back as Windows 3.1:
http://www.gaby.de/win3x/etips.htm#regedit
Oh yes. Let's all move our settings to XML configuration files. I don't believe config files are a better solution. We just exchange one set of problems for a different set of problems. Now instead of having my settings strewn throughout several different hives and keys in the registry, I get to try and find my settings in a series of files which may/may not be logically named and buried in one of several directories. For example: I want to copy my setting for MS OneNote 2007 to another machine. I have OneNote settings stored in AppDate/Local/Microsoft/Office, AppData/Local/Microsoft/OneNote, AppData\Local\Apps\2.0\Data\JJ81VLRM.H8Z\CLHYBMCG.2TG\onen..tion_f1fe1dc54fbb5b9b_0001.0000_87e1612fa5f8a27f\Data, AppData\Local\Apps\2.0\WJ7L7QJ0.11R. And this is just in the Local directory. I haven't even looked in LocalLow or Roaming, much less in the AllUsers or Default folders. I am no more certain that I will capture all settings using the configuration file method than I was certain I would find all the settings using the registry. Oh did I mention the fact that since I am forced to elevate priveleges to install any software, I might be lucky and also have some key settings stored in my administrator's folders. What a wonderful solution. This is SOOOO much better.
Joe Brinkman on August 30, 2007 9:45 AMI might choose a different screenshot.
Guybrush Threepwood on August 30, 2007 9:55 AMI think that there have been a number of good and bad points made. Sadly, they have been completely lost inside the myriad of "me too" type posts (e.g. "it's called XML", "use Linux").
I will attempt to summarize all of the points made here. Please excuse me if I miss anything out.
========================================
Positives about the registry:
* It's a single place for looking for most settings, rather than having numerous config files scattered in any number of locations.
* For applications which use the registry correctly, it's a convenient and consistent place to store information.
* Every key (folder) in the registry can be secured, providing fine-grained control over which items a user can see or modify.
* You don't have to worry about file system permissions when modifying global data.
* Having a binary storage in memory is more efficient than using lots of files on disk. For example, if you use an INI file, it gets rewritten every time you change even a single entry.
* It is automatically backed up by Windows, so you can revert to a "last good" state if needed.
* By being an opaque store of data, accessible only via APIs, it's harder to corrupt via manual editing. An XML file may be rendered useless by missing a single character.
* The HKEY_CURRENT_USER hive roams with the user's profile, making it portable.
========================================
Negatives about the registry:
* Being an opaque binary blob, it's a lot harder to make manual changes to should anything get corrupted.
* Because the registry is so widely used, any corruption will affect multiple programs, not just one.
* Because of its size, it's possible for applications to hide data just about anywhere. This makes some settings incredibly hard to find.
* There is no enforcement of structure. So long as a user has sufficient access rights, any program they run can write to anywhere in the registry.
* It's a lot harder to extract settings for a particular application from the registry.
========================================
Issues that will occur regardless of storage mechanism:
* There will always be cryptic or hard-to-find settings. Using Jeff's example of the DVD burner not working, the issue was with an incorrect configuration value, not the registry itself. If the data was stored outside of the registry, it would still require some kind of configuration file change.
* It's possible to stop an application from working by editing or removing configuration values.
* Configuration files and entries can be scattered in any number of locations, making them hard to back up or remove.
* If an application is removed, but doesn't clean up after itself properly, there will always be some usage of resource(e.g. disk space). In the case of the registry, it may also use up some memory.
========================================
In the end, it's up to developers to code appropriately for the situation. The registry is a good place to keep settings, so long as it's not abused. Other times, it's a better idea to keep configuration files on disk.
No matter how you look at it, the registry is just a storage tool for settings. It can be used, and it can be abused. Sadly, it's been far too abused, and this is the cause of all our pain.
Jamie on August 30, 2007 10:26 AMThe guy at Microsoft who accidentally created the Windows Registry agrees with you! Tony Williams. See his Code Behind interview where he is asked about it. http://www.researchchannel.org/prog/displayevent.aspx?rID=5212fID=1806
MikeD on August 30, 2007 10:28 AMJust a note to those who want some sort of control based on the application being run... Sadly, it's not that easy.
There are just too many ways to get an application to run whatever code you like:
* Modifying the application on disk (the same way viruses do).
* Inject a new thread into a running application. Any check of "which executable is running this code" will report that application.
* Locating a snippet of binary code that can cause execution to temporarily enter the third-party application, then back into yours. This would allow you to pass any checks of the call stack.
That's why operating systems tend to use user-level permissions rather than application-level permissions. It's much harder to spoof a user than an application.
Using a text only browser (damn your CAPTCHA!)
Qt, by Trolltech handles configuration files quite elegantly in a cross platform manner. It uses the native settings saving mechanism to handle any custom preferences. Thus, if Microsoft made a substantial change away from the registry, Qt based applications would not need editing!
Of course, knowing Jeff Atwood, chief architect of Microsoft cocksucking, he'll rather stick to inferior technologies.
For someone just beginning to question the registry, in a dry blog post, it's clear that sensible advice like "Use Qt" won't become apparent for another ($NOW - $INCEPTION_OF_REGISTRY) years.
Sean: "Talk about a total bastardization of xml. Shows a complete lack of understanding from the format creators. Plus it's a bitch to parse because you have to keep track of the previous sibling."
It isn't a bitch to parse because you simple look for a tag and then the following item is the object. Plus it's pretty easy to parse on OS X:
[NSDictionary dictionaryWithContentsOfFile:@"pathtofile"];
or
[NSArray arrayWithContentsOfFile:@"pathtofile"];
You've now got the whole file loaded into an array or a dictionary
Martin Pilkington on August 31, 2007 2:15 AMRegistry is not going away. If Symantec is not paying for this 'feature' such that it can't 'possibly be removed from windows' then they should. And the hackers, and the IT staffs...
Brian P. on August 31, 2007 2:53 AMNice posting, though we all know that the Registry was in fact one of the bricks in MS's great masterplan for obfuscating all other's code to such an extend that they could over time easily take over all the application vendor's revenue by supplying better solutions built on "local storage".... ;)
(JOKE...!!)
.t
Thomas Hansen on August 31, 2007 5:21 AM"How do you handle DLLs? Put a copy of every DLL that your app links with in the app directory? How about the DLLs that they link to? Oh, you want to have a common place to keep system DLLs so they don't have to be in every app dir? What do you do about apps that need different version of a system DLL? (It's called DLL Hell)."
Essentially, the problem is that the installer has to be used as a priviledged way of putting an application on a computer. If you reformat, or move to a different computer with the same share but different installed dlls, then things break.
I've long thought about a way of trapping all the changes an installer makes to disk and then packaging them so that the folder could be simply copied from one computer to another. Use a sort of secret directory which contains the registry keys and files installed to external directories. When taking it to a new machine, it would essentially look through the secret directory as a sort of $PATH for registry keys, and install them if they don't exist.
And yes, you could cache dlls in that directory (hard drive space is cheap) and when running for the first time on a new computer, go through the same process an installer does, examining the computer for dlls and copying the needed ones to the new machine.
Should be a relatively straightforward hack, especially if you can easily detect when an installer is running.
wkerney on August 31, 2007 8:33 AM How can we make this better?
We really have 3 different kinds of settings.
1. System settings
Store these in the existing registry for compatibility reasons or better yet, upgrade the registry to MSDE as suggested earlier.
2. Application settings
Store these in a centrally located location with a separate file for each application to make it easier to move application settings between folders and pc's. I don't buy the myth that this will slow down apps as the extra 200ms needed to read this file easily outways the performance hit for keeping a 500MB registry file in Ram (or a cache). Besides you can cache the file anyway.
3. User settings
User settings should be stored in a folder under "My Documents" and called something logical like "My Settings". This allows you to back them up, move them between machines and ideally, transfer them to a web service so you can access your settings anywhere on the planet.
Its an evolutionary process. The Registry was brought in to fix the problems caused by INI files and ended causing a whole different set of new problems. Think of how many attempts Microsoft needed to get ADO into the version they have now.
I agree with Jeff, at some point one has to stand back and take the 2,000 foot view and rethink things.
David E. on August 31, 2007 9:05 AMI think what we are going to see is virtualization of the registry and the equivalent of app-armor. Every app with run either in it's own virtual space or a protective shell. At least on windows. What I really wish is that linux/unix would move all it's config to xml. intead of me having to be some sorta voodoo shaman to know that 1 extra tab can spell doom, and what all the parameters means
christian bongiorno on August 31, 2007 9:17 AMThe Gassy One posted on His Blog:
Read This Now!
I am 100% on-board with this one, and am currently writing registry-free applications!
BTW, that reference comes from another favorite blog.
The Gassy One on August 31, 2007 10:27 AMJust an observation, but almost all of the posts talk about "moving an application" by copying the install folder somewhere else. This is fine for statically-linked stand-alone apps.
How do you handle DLLs? Put a copy of every DLL that your app links with in the app directory? How about the DLLs that they link to? Oh, you want to have a common place to keep system DLLs so they don't have to be in every app dir? What do you do about apps that need different version of a system DLL? (It's called DLL Hell).
How about newer apps that communicate with other apps (photoshop and a scanner control app)? How about all of those COM interfaces that let apps bind at run-time? How do I find RPC functions in a common place?
I think that if you go back and substitute a substantitive app, perhaps even a browser like FF, you either have a huge app directory filled with everything needed to implement modern componentized applications, or you have something like the registry that can be located by any app and queried for the location of common shared copies of things.
Do you really want to download 100 or 200 mb install packages that have all this stuff in them? As bad as the registry is, the world of .rc (er, .ini) files is as archaic as the isolated apps that used them.
Myself, I kinda like being able to drag-n-drop things in the GUI, mash up some COM components into a new app without rewriting everything from scratch, and have my Java call C++ functions from a DLL that is common to some functional domain.
Does anyone not use these kind of apps? If not, other than writing bash scripts or perl, how do you create extensible, versatile tools to solve your problems?
Perhaps the registry is like what people say about democracy == it sucks, but it's better than the other forms of government out there.
I just wanted to make sure your discussion covered a large surface of the apps available to run on modern OSes.
JS
Jerry on August 31, 2007 1:31 PMAs usual, the big problem comes from the complete lack of decent security in windows and the fact that that to get it to do anything you have to be running as an administrator, therefore the application/installer you happen to be running has full access to the registry. If you open up regedt32 instead of the normal registry editor you can see that security access via acls to keys in the registry is implemented, but the need to be admin to install apps means it is rendered useless.
The question is really, why should admin rights be required to install anything other than OS software. (As an aside, why should we have to keep installing OS level software in monthly updates?) Because the security was not thought out and the few attempts to implement it have been counter-productive to the point that now to do anything you get an ugly popup confirmation or ten, which then grants the application/installer full rights to do anything it wants, not just install or run itself. Rubbish.
Unix had the concept of user, group, other from the word go, and DOS came after Unix, and Windows in it's 'New Technology' variant came along time after that. If the originaly designers at Microsoft had even the slightest idea of what they were doing (or the people who MS bought MSDOS off), then things would be a way lot easier for us now. I personally would be about a year's worth of wasted man-hours ahead in my life.
MS give me that year back which I have lost due to your crappy design, implementation and marketing/greed-driven decisions I say!
Wakes on September 2, 2007 4:04 AMUltimately I believe the registry was a failure.
Why? Primarily because the state is accumulated through the application of scripts. This leads to a situation where it is very easy to corrupt the configuration.
The alternative? A synthetic view of configuration built dynamically from a set of application manifests. This would allow easier application removal and coexistence. It would also facilitate building security envelope around applications that would shutdown applications that attempt undeclared operations.
c.f. the metabase IIS7, Softgrid
Larry on September 2, 2007 4:23 AMIntelligent discussion about what is really wrong with the Registry seems to be scarce. This is a good start and there are some great comments here! I hope Microsoft is reading.
I've worked in some depth with the registry (on the roll-up-the-sleeves, mucking-it-out level) and here is my own list of problems I've noticed with it, some of them similar to stuff mentioned in the article and comments:
- The registry is "static." What I mean by that is that it typically has no provision for dynamic verification or re-registration of anything, because it depends on these babysitters called installers for its information (and makes the dangerous assumption that they are always right).
- The registry is "sedimentary." Thanks again to its reliance on installers firing off one-time additions of data that may or may not ever be re-examined, stuff "builds up over time," in layers as it were. To make matters worse, new layers can overwrite previous layers entirely. Meaning: the registry is un-journaled and un-versioned on a granular level, which, given the computing power available today and the long-established practices for doing these things in filesystems and databases, is nothing short of criminal.
- The registry stores data as "dumb de-contextualized." It lacks important metadata that it really ought to have if parties beyond the OS are going to be messing around in it, such as information about key creation and ownership, key history or version, dependencies, cross-references, validation constraints, comments, etc.
Many posters have alluded to the way OS X does things as an alternative possibility; here is some factual reading straight from the horse's mouth on how it does configuration and registration management:
http://developer.apple.com/documentation/Carbon/Conceptual/LaunchServicesConcepts/index.html
http://developer.apple.com/documentation/DeveloperTools/Conceptual/DynamicLibraries/index.html
Not saying these are the BEST way or the RIGHT way to do these things, but it's worth looking at for educational purposes.
What's with you weenies and liking XML?
It's inefficient! Use YAML.
And if you've installed the Developer tools (they come with the OS X Install disks) Though you may end up never using most of it, once they are installed, .plist files will open up with the Property List Editor application, giving you a very Macintosh way of editing and viewing your plists.
God of Biscuits on September 2, 2007 12:45 PMApple has a nice implementation with their preferences API.
I particularly like the PATH-like behaviour of preference lookups, so you can local overrides of system settings. E.g. first ~/Library/Preferences (per-user) is consulted, then /Library/Preferences (system).
I also like the namespacing of settings in a way that is a bit more human friendly than the Registry. My kingdom for less GUIDs, or what, eh?
You can use command-line tools to modify settings, or just edit the .plist file containing the settings directly (it's XML, or can be made to be pretty easily).
So the scope of the badness of a broken change is likely just one application, and not your whole system, which is a bonus :)
nexusprime on September 2, 2007 1:04 PMBanish the registry ! Put one application in one directory then you just delete it to get rid of it and all its stuff, without leaving debris and collateral damage in the registry. Have three different versions at once, each corralled in their own directory - no worries with no registry to confuse them with each other.
Single point of failure ? delete or corrupt the registry and you're screwed, trash an application directory, ini file or modern equivalent and you lose one application which you can copy back.
PhilT on September 3, 2007 3:09 AMHi,
Your article resonated with my opinions on Registry and XML-based config files. It was even more heartening to find a mention about Unix-way of doing things.
Well M$ has copied many wonderful ideas and "rebranded" them. My personal choice for Simple App Settings file would be the plain old INI file.
But a word of caution (from my experience) - when the whole world is following a particular norm, it is the best for us to follow that lest we are branded as lunatics.
So, even if I hate XML (for its overuse) and XML-based App Settings files, I better go the XML way if I am programming in .Net. Otherwise I am sure to be branded as "Dinosaur".
Srivathsan M on September 4, 2007 2:32 AMSQLite anyone?
Jimmy on September 4, 2007 11:49 AMI am not sure if the main issue is if the registry was a suitable replacement for ini files or not, but rather Microsoft's habit of forcing developers to implement any new type of innovations it introduces and putting their older technology into obsolesence. While ini files can still be used, there is a feeling of discouragement and at best "lip service" support with their use.
Unix-based systems on the other hand, do not push earlier (notice my change of wording from "older" to "earlier") technology away, but rather give developers the opportunity to implement new innovations if they so please, all the while keeping earlier technology afloat. For a vast majority of developers, the old adage of "if it ain't broke, don't fix it" applies. Software is buggy enough, so why give yourself more headaches than necessary?
Later,
Murdock
How do you resolve DLL Hell?
How about really versioning the DLL's? No, I mean, REALLY versioning. It won't matter that there are 3 different copies of COMCTL32.DLL because each version will be different, and apps should have been linked to the library and VERSION that was required. When installing the app, the libraries can go to live in the same user-library space ( "C:\Libraries", anyone?); installing an application with the same library name and version number does NOTHING because the versions are identical, hence, dynamically linked apps will select the right library and the right version on startup.
Oh, wait, I forgot... /lib already does that.
Subv3rsiv3 on September 5, 2007 12:23 PMWhile I tend to agree with you guys on the horrors of the registry system, I also have to sympathize at least a little with Microsoft. Think about the things you did 20 years ago. Hell, think about your website you made only a year ago. Did you have infinite knowledge of what would be the best way to future-proof your design?
In 20 years, you'll be looking back on the Linux we have now and reminiscing on the stupid things it does now, too... so let's move forward, help where we can to get this broken system fixed, and stop with the blame and the hate. It doesn't help anyone.
Marty on September 6, 2007 2:42 AMAhem - the registry first appeared in Win 3.11 !
Mike Kelly on September 6, 2007 8:22 AMAndy: "Aren't there Windows API calls that can manipulate .INI files in the same way one can manipulate registry keys?"
Yep. ReadProfileString()/WriteProfileString() work with Win.ini, and ReadPrivateProfileString()/WritePrivateProfileString() work with any .ini file.
KenW on September 6, 2007 8:36 AM"The registry is opaque and binary".
Are there non-binary alternatives to the registry? No. It's all binary, underneath.
Is it opaque? No more so than a lot of other formats.
1) Text-files are no more nor less human readable than the registry files. It is all just 0s and 1s. It is just that there are more visualisation / editing tools available for text files. But that is not the fault of the regisrty itself.
2) Yes, you can add comments to XML files and INI files. But you can document registry settings, too. By giving them meaningful names, or in external help files. In some ways this can be better - you can hyperlink a help file. You can't hyperlink comments in .INI files.
Personally, I don't see the registry as the problem - or the solution. IMHO, the whole file system should be more like a database. But that is a whole other discussion.
.ini files suck, and should have died with Windows 3.01. Just because coders dont use the Registry correctly/efficiently does not make the registry wrong. Several apps I write use very deep heirarchy settings, trying to parse that into an ini file would be torture, registry is a snap. Plus, most users are dumb enough to delete files as they are easily found, but know the Registry is off limits to newbies, so more secure.
Dave D on September 6, 2007 9:05 AMThe commercial GUI applications I have prepared use XML for all configuration. If the user blows the configuration file away, a default file is automatically prepared next time the application launches. Why mess with registry unless another process needs to find yours and interact with it? Come to think of it, sometimes that can be done using named pipes.
Kevin in MO on September 6, 2007 9:06 AMMicrosoft never took away the APIs for manipulating INI files. If the registry is so bad, it leaves one to wonder why developers didn't revert to using INI files. Perhaps that's because the registry, for all its warts, is still better than INI files.
Patbob on September 6, 2007 9:29 AMA note on .Net config files.
If you're lucky enough to use the monstrosity that is visual basic, accessing settings is fairly simple using the "My" namespace.
For those using a real language, such as C#, it's somewhat harder and the VS2005 help files aren't particularly useful.
AndyM103 on September 6, 2007 9:29 AMDefinitely agree. That's why when I write utility applications I don't use the registry - my programs write INI files.
If you're working with an application that runs on a network - an INI file on a network share makes a ton more sense than using registry entries. Wanna change a parameter and have it affect all associated workstations? Make a quick change to that INI an PRESTO ... all workstations have the change. With a registry - you must go to each workstation somehow to affect the change.
A central registry hive was, IMHO, a major mistake. It works, yeah, but it's a horrible throwback to monolithism in an age of modularity. Better to have established a hidden directory under \WINDOWS somewhere and have a bunch of INI files. Much easier to recover from system failures.
-MP
Max Peck on September 6, 2007 10:13 AMYou are correct. The registry (along with COM in general) is one of the most successful failures ever.
What a happier world this would be if in the NT3.51 days Microsoft would have decided to lock the registry down. :(
John on September 6, 2007 10:18 AMI'm happy to see that ALL the posts agree on the same fact: storing
everything in a single congested place is simply too stupid.
It's a dumb idea created by not too smart people, just thnking a little about the problem would have led them to find different solutions, even 20 years ago.
The registry is the reason why, in case of crash of my HD, I'll need more than a week to reinstall everything. And the reason why it takes about 10 minutes to boot win XP, the registry now being a horrible 50 MB monster full of nonsense.
Have you ever tried to cancel by hand the keys of some application? With separated installations and config files it would be a matter of deleting a directory, actually it's a nightmare of deleting keys one by one by hand, hoping not to miss a single one.
And have you ever seen the useless junk that most applications store in the registry? Maybe the initial idea was that only really valuable information was to be stored, but some apps, an application from Kodak comes to mind, actually insert thousands of keys for a set of applications that mostly I'll never use. Imagine installing a lot of programs ...
Moreover, as far as speed is concerned, I dont' think the registry is fast at all. It's a sort of database created with technologies of 20 years ago, so old and slow. Then ... how can you compare searching a 10 byte value in a 100 byte file instead of having to search through 50 MB of registry? And if it's all in memory (I doubt it), why is windows wasting 50 MB of precious memory when I only run my app which needs only a 100 byte configuration?
What I'd really like to find sooner or later is a tweak or driver or hacked DLL for windows that let the apps think they work with a single registry, but actually splits the information locally, the specific one in the same directory of each app. That would really be a useful upgrade of the OS ...
Daniele on September 6, 2007 10:41 AMHaving all configurations in one place (i.e. a registry) is convenient if you need to view/manage all settings as one entity.
Having each configuration in a local place (i.e. an INI file in an app or user folder) is more convenient if you want to view/manage its settings in isolation.
The problem with a hierarchical based system is that it can never serve both purposes simultaneously. In a way its not unlike the issue we might face when deciding how to structure our folders to store documents -- you may want to group documents by type (i.e. all your project schedule files) or by author, etc.
SQL-based storage solves many issues by avoiding the imposition of having a single hierarchical view. Perhaps, as others here have suggested, this could be the basis of solving some of the issues associated with the registry.
I still think that applications should be installed by simply copying a folder, but perhaps any related INI-type files would automatically be pulled into the SQL-based system (perhaps on the first execution of the application).
More thought would need to go into this (there are already many caveats I can think of but I think that decent solutions could be found for most issues), and I think having a relational view of configurations could go a long way to serving the best of both worlds.
Importantly, the SQL-based system would need to provide the user with a rich interface that is easy-to-use that allows the user to view/manage/copy any application settings or user settings, etc.
VariousArtist on September 6, 2007 11:14 AMJeff,
Well said! I have always been less than thrilled about the registry for all the reasons you list above. The Vista registry/filesystem extension is nice BUT, implementing this in an application would involve having two code paths: one for vista, and one for all other Windows OSs. I think a better direction is to migrate application settings into a local xml, or ini file contained next to the applications exe. This would result in one code path, and move a bunch of junk (which applications need to persist) out of the registry.
I think people put too much weight on the official direction provided by Microsoft. I did it ten years ago when I started persisting application settings in the registry.
-jared
This analysis is somewhat flawed.
Forgive my longer memory, the registry was introduced partly to remove the problems with .ini files. Prior to W95, applications put their settings in win.ini and system.ini, this caused lots of problems as applications edited them incorrectly and could cause the system not to be able to be loaded! Remember all those repair tools that backed up/repaired win.ini files?
If the only problem was to put application settings in one place in the registry then .ini style files are fine. This is very rarely the case. Many applications have settings that can and should be shared by all users of the computer and some that should not. Windows provides LOCAL_SYSTEM and CURRENT_USER branches (hives) of the registry and this is a good solution. I would need per user files and a shared file to implement this in the neolithic UNIX world.
In addition most applications need to sprinkle registry settings within the system's registry keys in order for it to be fully integrated into the system. So, as examples, some sort of control needs component registration, a new file extension needs registration and the uninstaller needs registration so it can be displayed as an Add/Remove program in the control panel. These are the obvious examples but a large product will often have many obscure registry changes it needs to make. I can't see an easy way to effect this with files, or is it proposed that the system has thousands of little .ini files that reflect the thousands of registry keys. Now what would you rather do today?
TEXTO
NAME on September 7, 2007 9:58 AMATEXTO/A
NAME on September 7, 2007 9:59 AMpah! window.. stupid registry ok it was gd to start with but they could do so much better vista was gonna ditch the registry but some old git said "no im to scared to change" idiots..... GO LINEX!!! :P
mouse on September 7, 2007 12:32 PMpah! window.. stupid registry ok it was gd to start with but they could do so much better vista was gonna ditch the registry but some old git said "no im to scared to change" idiots..... GO LINUX!!! :P
mouse on September 7, 2007 12:32 PM"Think!" this was one of the most intelligent motto in the IT industry.
Do you really think that Microsoft invented the registry as a technical solution? "Think!"... Microsoft is not a thechnical company, it is mainly a marketing think tank... Someone (and I completely agree) says that Microsoft does not innovate: this is not true from a marketing point of view. Think for example the way they invented teir way to approach technical people: they have really invented a new way to sell their pseudo-technology.
So, IMO, the real point is: Microsoft has discovered how to increase coupling. The registry is simply a marketing invention: the more people use it, the more they get coupled with Microsoft products.
Do not forget that Microsoft has invented the "injection of obsolescence" in their product names...
What if someone that worked at Microsoft tells you that the registry was really invented by the marketing team to increase coupling?
The registry IS a marketing weapon, maybe the most powerful marketing weapon ever invented. The registry is mainly a "coupling" techology.
fabio vitale on September 7, 2007 1:17 PM
Good post. The registry really sucks.
I'm happy to hear that Microsoft is breaking away from it.
The Windows registry strikes me as something that wasn't designed, it just happened to be implemented from an original concept without refinement. Not good engineering ethos, if you ask me. But then "on error resume next" seems to be staple with all the developers I meet nowadays. Sad.
Mike Peter Reed on September 9, 2007 4:38 AMOn behalf of the silent majority...
hmm, I wonder exactly how many applications (and installations of) are out there happily using the registry. I bet if typed '1' then started typing 0's the answer wouldn't fit in this rows="11" cols="70" TextArea.
Perhaps in a few years you'll all be damning config files... Nag nag nag nag, excuses excuses excuses.
Personally I have never had a problem with the registry. True I have not used it since, since, well a long time anyway. I think the single greatest advance, which is actually a throwback, is not having to register components, as with COM.
Get back to work slackers...
Maybe a private registry where the os manages itself....
hardware, os Apps, etc..
A public registry where the app developer can use or not
the Registry has its advantages for the operating system ...but all the junk the gets placed in there is just pure crazy..
i understand the need for localization, but come on the registry is probrably 50 percent junk inside....
DaveP
Dave on September 10, 2007 8:29 AMSure, anyone who's still got Petzold remembers when they first had an API so they could just manipulate text files in a psuedo-structured format like a .ini without having to roll their own, but realistically there was a search order imposed about where these API's would access the ini files from, and the reason why the apis where developed was because otherwise you could, feasibly, do some bad manipulations, or even just delete the system.ini from the windows home dir because there was no security on it at all if you knew how to flip the s bit.
I'm sure that there was a big buzz in the Windows dev community that the reg was going before NT4 was released, to be replaced with xml files or some such, much like MS keeps on harping about an OO Filesystem, but at the end of the day providing a decent heirarchical model to either with decent security just proved to hard.
They failed to separate the meta from the data, which was what Mac tried to do (not sure how it's going with OS-X or the gritty resource-fork details from before, but this PowerBook hasn't crashed since I bought it 2 months ago before a rapid-onset decamp from the heathen world, and still starts up in 5 seconds after a snooze).
As for DLL Hell, the concepts where being widely discussed at the time, somewhere along the names of Naming, Locating, Versioning, Persitance, Transaction Services etc. But you have to look at the mess that CORBA and the OMG, which was a supposedly open standards based, got into trying to implement all this infrastructure in a very short time. Despite the mess, MS saw this as a big threat to their naiscent distributed computing environment (MS from Server to Desktop which supported Bill's ... on every desk messianic beliefs), so went steaming ahead with their own sad attempts which were not well designed, or in any way enforced on an OS Level. Not even by gentlemans contract. There was no way you could say to MS, "hey, I fancy calling my DDL 'fred', do you already have a fred.dll?" They didn't care.
This means you could put an internal version in meta-data in a DLL, but the OS loader did not in any way enforce the loading of that version or otherwise distinguishing meta data at all over any other DLL hanging around by the same name.
On top of which, as a later attempt, targeted at security issues, they actually disabled the ability for an application to load a DLL in its own directory in preference to one in the system directories. This was a huge mistake (though I may be wrong), but it was one that many developers where relying on, and then got screwed over by.
Then comes the whole activex no sand box issue.
Then comes the COM threading fails issue.
Then. I dunno? Could there ever be a more innept bunch of fools in charge of the desktop computer world?
Wakes on September 12, 2007 2:39 AMHave you ever heard of Jaunt PE? It creates for apps portable launchers that hook and redirect registry changes into .ini files. It can be customized to only watch for specific registry calls and can redirect file dumps too. It's like shoveling up the sh*t behind a horse, but it's better than leaving the sh*t on the road. www.portablefreeware.com
Joshua Fan on September 16, 2007 10:17 AMWhat really stinks about the registry is moving your settings from one machine to another. You are forced to go exploring the registry just to find the list of preferred options!
Codewarrior solves this problem by giving user an "Export" and "Import" settings, but not every application does this. A local config file solves this problem in the minimalist way.
A point that no one has mentioned:
How do you store binary data in an .ini file without bloating the file when you encode the binary data in ASCII ala base-64?
The *nix custom of storing config files with a leading period '.' is simple, but it works. Thankfully *nix chose the prefix, instead of the suffix since Windows won't let you create a filename with a single trailing period.
Cheers
I don't see anyone providing a usable replacement to the registry.... but i hear a lot of noise...
I've yet to see an enterprise size LAN 'managed' by a unix box though agree many unix boxes are better as servers for other purposes...
Drivetheory on November 24, 2007 12:30 PMWhatever the solution is, I hope that some day I can install 200 random apps + bunc of devices and when the day comes when I wan to get rid of them that Windows provides nice UI for remove programs / program settings / devices. And when I click remove, I can trust that Windows takes care that no single leftover file or registry entry remains in my system.
Joakim on March 21, 2008 7:26 AMThis is fine and dandy reading about all the people who hate the reg but... When is MS going to listen?!?! MS should have an advice forum. =)
Jeff on March 31, 2008 12:12 PMDugg:
http://digg.com/microsoft/Why_the_Windows_Registry_fails
This thread started August 29, 2007
and April 5, 2008 people are still
saying it was a lousy idea. Me too!
On August 29, 2007 06:41 PM, Andrew wrote:
Maybe part of the problem is that since everything is stored in the registry, people blame the registry for everything.
It is the single most insightful comment in this thread. Jeff, I'm usually right with you in the things you say, but there are a lot of registry-bashers out there who are not seeing the whole chessboard. Registry pros outnumber registry cons by quite a bit.
What I'd like to see is for MS to start asking that apps and drivers which get logo-certified to have documentation of every registry key they write. MS also needs to field a more prominent, complete, and one-stop documentation of the registry keys *they* write.
One last thing: commenting your registry values is easy! Just write a REG_SZ (string) key as a comment.
If you guys are so smart, write software that doesn't use the registry to store hundreds of application specific settings. I get that you have to use it for some things, just add a config file for your other settings.
dean on October 15, 2008 10:26 AMWhy oh why oh why didn't I listen--I just fricked around with my registry.
I know better.
(I borrowed your image above--I should have it pasted to my forehead.)
Michael Doyle on December 25, 2008 10:37 AMMy idea of how to fix the registry problems:
Like David E. said there are basically three types of settings:
System
Application
User
System settings are what the registry should be used for.
Each app will include a file to regenerate its system settings.
To handle application settings:
There should be a folder (something like ProgramSettings) every application will get a folder inside of it (the only one they can read from in that folder). Inside that folder each app will get a database file (and there will be a standard api for using it) this will be faster than xml and average users won't know how to read it.
To handle user settings:
Every user will get a My Settings folder (like someone else said) they will get another database in here (once again programs can only access their own files)
Then to copy programs you would only need one (or two) folders, and applications could automatically generate new ones if you forgot one.
And because the registry is still there for system settings it would be fully compatible with current programs.
Just an idea
curt on January 18, 2009 5:04 AMfully agree
al on January 23, 2009 11:51 AMThe Windows registry is a very very bad idea!, it's full of garbage left there by the apps.
All apps should use configuration files (.ini) and use the registry only when there are no other options (for example, to assign file association).
The registry is like inheritance. There are ways that it can be used responsibly, but it's very design encourages misuse. If I recall, .ini files were the same way.
Eagan on January 30, 2009 1:58 AMI always have thought that the registry was (and still is) a bad idea.
Remember reading somewhere that this approach was taken because COM was not thread-safe at the time and it couldn't handle more than one instance of a dll in memory. The registry was a place to ensure that not to happen.
Alex on March 11, 2009 4:48 AMo melhor programa amador que ja vi
DJ THE BLACK on March 14, 2009 5:08 AMI have a suggestion. Get Microsoft to change the name from Registry to Library(ies) and creat a Librarian(s) to work the Library(ies). Programs submit there requests to the Librarian(s) and the Librarian(s) provides services like deciding were to put the data and retrieving the data to pass back to the program when needed. Then there is the DLLibrarian to take care of the DLLibrary(ies). The Librarian assigns Program/user ID's (ssn, tax ID, with PIN for security) and catalogs the data using an identification system (alphameric,Dewey, Library of Contress, Wal-Mart bar codes...?) and when the Program needs to move, one of the Librarians can gather All the data, package it in a box (zip file?) for shipping to another Peee Ceee.
Just an Idea!
DaddyKasz on April 5, 2009 9:00 AMLate addition to the thread (2 years late!):
Defenders of the Registry offer the common theme: The problem is not the Registry, it's poorly behaved apps adding junk to the Registry. But that's exactly the problem. By making one common place where applications are supposed to put all sorts of data, the Reigstry is inherently full of junk. One poorly-behaved app can trash it up. One poorly-behaved app that fails to clean up after itself when uninstalled can trash the Registry forever. And as it can be very difficult to figure out what app put what where and why, even a very knowledgable and experienced user can find it virtually impossible to clean up the registry.
Here's how I think it should have been done: Microsoft should have created one file where an application registers it's name and the path where it is located, and the list of file extensions that it supports. Period. Do not provide any way to express any other sort of configuration data. Require the application to store any other configuration data in its own directory. The system Uninstall function can then delete the application entry, the associated extension entries, and that directory. There is no need to even have such a thing as an uninstall program.
Then it doesn't matter if a poorly-behaved app creates a lot of junk. If you no longer need an app, uninstall it. Then it and all its associated data are gone.
If you wish you can provide tools to create a configuration file in a standard format, like an INI file. If an app uses this format and these tools, fine. If not, it doesn't bother anybody else. If an app has unusually complex configuration requirements, that's its own problem, and no one else's.
Comments that the Registry simplifies pushing common configuration data across an enterprise strike me as unconvincing. There's no way an organization can push common configuration data for unknown applications. All you can do is say that you'll push configuration data for specific, known applications. So fine. If each application has its own configuration file, then you just say, here's our standard configuration for MS Word and here's out standard configuration for Jim Bob 2000. You create those configuration files and you push them out to the appropriate directories. If an app splits its configuration across 200 files with indecipherable formats, okay, you'll have trouble pushing that. But if an app splits its configuration across 2000 Registry keys with indecipherable names and formats, how are you going to push that? Don't tell me you're pushing the entire Registry.
The Registry is fast? I don't see how that was true even in 1995. Loading an app means loading an .exe file and often many other files. Even a small app is probably a few hundred kB, big ones are often megabytes. To say that in addition you have to read a configuration file that is probably a couple of kB, surely makes little percentage difference to the total load time. Okay, a complex app might have a complex configuration, so now the load is 10k or 20k. But an app with a 20k config file surely has multi-megabytes of code, probably spread across numerous EXEs and DLLs and whatever, so it's still a small percentage difference.
So I agree: The Registry sucks. Throw it away.
jay on May 4, 2009 9:25 AMI think the registry is a good idea but only if not used extensively. I've been working a lot with Wordpress (a blog engine) which has a central regsitry database in MYSQL and that works very well because it's structured and able to deal with all the different things that can be done with it.
Windows Registry Cleaner on May 6, 2009 4:32 AMI can't see why people keep blaming MS for bad practice *people adopt*.
Who said you can't use ini files? In fact, anyone reading MS's WinAPI Bible would find a section which suggests when and which method a programmer should use to store information.
Secondly, for your information, MS published both INI and Registry writing APIs.
So next time you want to blame the registry chaos, rant about program's improper use of registry (such as Firefox's/Mozilla NPAPI deprecated/underused registry settings).
Kind regards.
Christian Sciberras on June 4, 2009 12:24 PMJust type "Windows Registry" in google...
All you find is registry cleaners, registry repair tools, demystifying the registry, registry tweaks and fixes, registry recovery, how to backup the registry...
Now come and tell me this is not a piece of junk!
Sylvain Halde on July 18, 2009 2:50 AMfiddling too much with the registry without the appropriate knowledge can mess up your PC big-time
mr dmc on July 29, 2009 3:53 AMfiddling too much with the registry without the appropriate knowledge can mess up your PC big-time
mr dmc on July 29, 2009 3:53 AMThe registry sucks big time. When Unix was created long time ago (with 5MB hard disc), they chose to store config files as text files. The reason is that over the years, only text files will still be readable. Binary config files sucks. In Unix you start up an editor and edit the config file. In Windows you need a reqistry repair, otherwise you are screwed. You have to reinstall Windows. In Unix, you never reinstall. You just fire up an editor and repair the problem.
Can you spot and correct the error in this text config file?
Xscreen 1600
Yscreen 120"#ยค%DS+
Bitmap 24
Mouse Yes
Or this error in this binary file?
0101110101110101101110111101010001010100110101
Which is more transparent, and more human intuitive? Binary formats need special editors. In 30 years, the binary format will be obsolete, but the text file will not.
Kebabbert on August 4, 2009 5:36 AM"Those who do not understand Unix are condemned to reinvent it, poorly."
-- Henry Spencer (http://en.wikiquote.org/wiki/Henry_Spencer)
Jason Lefkowitz on February 6, 2010 10:07 PMWe've just begun converting our programs back to INI files for most settings.
Things like window position, column widths, crap that the user can drag around or sticky settings while the application is running. That we store in the registry.
Important stuff, back into the INI files.
Clinton Pierce on February 6, 2010 10:07 PMI think the registry is good for precisely one thing: File Type Associations. Having a central place, where each extension is connected to one or more apps is loads better than the shebang method on *nix (although I think it would be best to support both). Configuration files are going to be a mess no matter what you do. Sticking everything in one spot is just idiotic. One place for all apps in your office suite? Sure. One for all apps in your system? No thanks.
Aaron Davis on February 6, 2010 10:07 PMNever could bring myself to touch the registry while I've coded. When I decided to store app settings somewhere, some nice folks on Channel9 helped me to see that I could export an AppSettings class as XML to the \All Users\AppData\My App\ folder. This has allowed basic users to tweak stuff if they made a change that went against the settings. (Which, if coded correctly, should never break your program.)
M Kenyon II on February 6, 2010 10:07 PMMicrosoft's main reason for introducing for the registry was not the stated ones. I believe it was intended to make applications dependent on a verified install process. I.e. to prevent simple copying of application directories as a means of installation - copy protection through obscurity.
Peter Wilson on February 6, 2010 10:07 PMI think the registry is better left for more complex application that require resources as such. I have an rather simple application that has been out for a while and I use the registry settings to store a few formatting options, like window size, what tabs were selected, etc. to give a more consistent user interface when the user comes back in.
So following the "standard" I put these settings in the registry. However, I started running into some problems during the beta cycle where people were closing a tab and the UI wasn't catching it, so their tab was "lost forever" since the app saved it's state to the registry upon closing. Trying to help people navigate through that is nasty.
I cleaned up the code and the registry settings remained into the production, and I made sure the installer removed the registry keys as well. However, now that I'm working on a 2.0 release, the thought occurred that my program is so lightweight that it would function quite nicely on a USB key and given the nature of the program (deck building program for a TCG), it would be perfect for a kid to bring their USB key with the app over to their buddies house, fire it up, and work on things from there. But with it looking/writing to the registry, this becomes an issue.
So my 2.0 release is going to leverage the app.config file to read/write most of these things. None of my settings can do nasty hacks, other than hide/show some tabs and make the window tiny and the advantages I get from it are great. Plus I like how most of your middle/light apps functioned in the old days, you put the EXE on a disk and ran it, no need to wait for things or pull in resources, you just ran it.
Sean Patterson on February 6, 2010 10:07 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |