Why are INI files deprecated in favor of the registry?


Welcome, Slashdot readers. Remember, this Web site is for entertainment purposes only.

Why are INI files deprecated in favor of the registry? There were many problems with INI files.

  • INI files don't support Unicode. Even though there are Unicode functions of the private profile functions, they end up just writing ANSI text to the INI file. (There is a wacked out way you can create a Unicode INI file, but you have to step outside the API in order to do it.) This wasn't an issue in 16-bit Windows since 16-bit Windows didn't support Unicode either!
  • INI file security is not granular enough. Since it's just a file, any permissions you set are at the file level, not the key level. You can't say, "Anybody can modify this section, but that section can be modified only by administrators." This wasn't an issue in 16-bit Windows since 16-bit Windows didn't do security.
  • Multiple writers to an INI file can result in data loss. Consider two threads that are trying to update an INI file. If they are running simultaneously, you can get this:
    Thread 1 Thread 2
    Read INI file
    Read INI file
    Write INI file + X
    Write INI file + Y

    Notice that thread 2's update to the INI file accidentally deleted the change made by thread 1. This wasn't a problem in 16-bit Windows since 16-bit Windows was co-operatively multi-tasked. As long as you didn't yield the CPU between the read and the write, you were safe because nobody else could run until you yielded.

  • INI files can suffer a denial of service. A program can open an INI file in exclusive mode and lock out everybody else. This is bad if the INI file was being used to hold security information, since it prevents anybody from seeing what those security settings are. This was also a problem in 16-bit Windows, but since there was no security in 16-bit Windows, a program that wanted to launch a denial of service attack on an INI file could just delete it!
  • INI files contain only strings. If you wanted to store binary data, you had to encode it somehow as a string.
  • Parsing an INI file is comparatively slow. Each time you read or write a value in an INI file, the file has to be loaded into memory and parsed. If you write three strings to an INI file, that INI file got loaded and parsed three times and got written out to disk three times. In 16-bit Windows, three consecutive INI file operations would result in only one parse and one write, because the operating system was co-operatively multi-tasked. When you accessed an INI file, it was parsed into memory and cached. The cache was flushed when you finally yielded CPU to another process.
  • Many programs open INI files and read them directly. This means that the INI file format is locked and cannot be extended. Even if you wanted to add security to INI files, you can't. What's more, many programs that parsed INI files were buggy, so in practice you couldn't store a string longer than about 70 characters in an INI file or you'd cause some other program to crash.
  • INI files are limited to 32KB in size.
  • The default location for INI files was the Windows directory! This definitely was bad for Windows NT since only administrators have write permission there.
  • INI files contain only two levels of structure. An INI file consists of sections, and each section consists of strings. You can't put sections inside other sections.
  • [Added 9am] Central administration of INI files is difficult. Since they can be anywhere in the system, a network administrator can't write a script that asks, "Is everybody using the latest version of Firefox?" They also can't deploy scripts that say "Set everybody's Firefox settings to XYZ and deny write access so they can't change them."

The registry tried to address these concerns. You might argue whether these were valid concerns to begin with, but the Windows NT folks sure thought they were.

Commenter TC notes that the pendulum has swung back to text configuration files, but this time, they're XML. This reopens many of the problems that INI files had, but you have the major advantage that nobody writes to XML configuration files; they only read from them. XML configuration files are not used to store user settings; they just contain information about the program itself. Let's look at those issues again.

  • XML files support Unicode.
  • XML file security is not granular enough. But since the XML configuration file is read-only, the primary objection is sidestepped. (But if you want only administrators to have permission to read specific parts of the XML, then you're in trouble.)
  • Since XML configuration files are read-only, you don't have to worry about multiple writers.
  • XML configuration files files can suffer a denial of service. You can still open them exclusively and lock out other processes.
  • XML files contain only strings. If you want to store binary data, you have to encode it somehow.
  • Parsing an XML file is comparatively slow. But since they're read-only, you can safely cache the parsed result, so you only need to parse once.
  • Programs parse XML files manually, but the XML format is already locked, so you couldn't extend it anyway even if you wanted to. Hopefully, those programs use a standard-conforming XML parser instead of rolling their own, but I wouldn't be surprised if people wrote their own custom XML parser that chokes on, say, processing instructions or strings longer than 70 characters.
  • XML files do not have a size limit.
  • XML files do not have a default location.
  • XML files have complex structure. Elements can contain other elements.

XML manages to sidestep many of the problems that INI files have, but only if you promise only to read from them (and only if everybody agrees to use a standard-conforming parser), and if you don't require security granularity beyond the file level. Once you write to them, then a lot of the INI file problems return.

Comments (139)
  1. BryanK says:

    The granularity "issue" is sidestepped in a lot of cases by allowing XML files to refer to (or include) other files.  XInclude is a decent way to do this, but there are other ways as well (e.g. .net’s .config files let you include other files using custom attributes on several elements).  If you refer to a different file, that different file can have a different ACL on it.

    Now, this is obviously bad if you want fourteen layers of XML elements with different ACLs at each layer.  But that seems to be rare, at least; the most common usages seem to be where you have to store database connection strings and the like.

    (Another solution is to encrypt sections of the file, e.g. with some of the XML security extensions.  Make sure you’ll be able to decrypt them, though, and make sure you don’t use a hardcoded key.  Using the current user’s (preferred) or the machine’s (less preferred, but the only option if you run as localsystem) crypto key is usually a much better idea.)

    On a different point: Even if you did have to worry about multiple writers, can’t you just lock the file while doing the read-modify-write cycle?  Yes, it’s worse for efficiency, but the registry has to do something similar anyway, I think, since hives are stored in files.  Plus the registry code is in advapi32, which gets loaded into each process independently, so you don’t have a central service (or whatever) to arbitrate access.

  2. Anonymous says:

    @BryanK: there is a central registry "service"; advapi32 is just an interface to the kernel registry functions.  How would the security work otherwise?

  3. Anonymous says:

    Isn’t another advantage of the registry is the ability to track changes and roll them back?

  4. Anonymous says:

    I still really hate the registry and for two main reasons – abuse and cleanup.  Applications fill it with too much data and applications leave too much behind when uninstalled.

    I haven’t considered upgrading from XP and I likely won’t for years (if ever) because I don’t like ANY of the changes in Vista.  Suppose however, Microsoft would announce an upgrade to Vista that tracks which applications touched what registry entries and could strip unneeded ones on an app uninstall (or at least make it convenient for me to do so)…

    I’d ditch XP and upgrade to Vista for that reason alone – damn any other complaints I might have.   The registry has been that big of a bug crawling around in my shorts since its inception.

  5. Anonymous says:

    Bob,

    Programs leave registry data behind for the same reason they left behind .ini files back in the Windows 3.1 days: so that if you re-install the application, your preferences from before are remembered.

    Some uninstallers are nice and actually ask you if you want to delete settings along with the rest of the app, but I’d be angry if they assumed you always wanted to delete settings. Especially with flakey apps like Apple’s iTunes (on Windows; it’s fine on OS X) that need to be reinstalled often.

  6. Anonymous says:

    The registry is a superior solution compared to text or XML files, agreed. And it is the best solution for storing information in a central, well formed manner, like for the COM classes and the Plug and play hardware enumeration stuff.

    But I’ll trade all the disadvantages with text/XML files (as compared to the registry) for one important thing: the possibility to migrate 100% of an application and all of its settings (e.g. registration) intact, from one Windows PC to another Windows PC.

    Because once an application has written its particular set of data in the registry, it is not always clear how to retrieve all of it. Unless you happen to be the application developer, the registry will seem like a giant bit bucket in this case.

    If the NT designers had designed writing to registry so, that the information given by GetModuleFileName() were written along with the data keys, then the Export function in Regedit could have been so much more powerful. I.e. if I could specify a file path, like C:Program FilesMy CompanyMy app, and tell Regedit to export all of the data tagged with this path, then it would be possible to copy 100% of an app to another PC as easily as this is done today with text/XML config files.

    Rgrds /Henry

    [Your proposal falls apart once once program A modifies program B’s settings. -Raymond]
  7. Anonymous says:

    James,

    There’s a reason I uninstall most applications – they are garbage.  I don’t want my preferences remembered when I’m chucking the software.  I would say those programs think too highly of themselves, but I doubt seriously that the programs are leaving the registry data behind for me and re-installs.  I bet 99% do it only because of the time, money, effort involved in coding the total removal.

    Also I’ll note that most of the applications with nice uninstallers tend to forget anywhere from a few to a lot of keys.  They usually get all the ones placed in the registry on program install but miss most if not all keys created during the program’s operation.

    Of course the entries that that peeve me most are all the objects, clsids, and the like – things that can’t be trimmed by removing one big program branch.  Unfortunately these are the very kinds of entries that continue to wreak havoc on computer operation.

  8. Anonymous says:

    @Henry: I don’t think that that’s such a good idea. Unless NT would make sure that files aren’t really stored in directories and can be "tracked" properly. IMHO Windows should make it easier to move programs around, just like on a Mac where it doesn’t matter where you put an app and if you rearrange them, they’ll still work.

    Programs written for POSIX systems are in this regard an even bigger "mess", since they use a /bin, /etc, /lib, etc. This is all fine in any *nix OS and I’m glad they work the way they do, but in a desktop system this doesn’t help much, and could be done better.

  9. Anonymous says:

    Bob:  Abuse and cleanup are each program’s fault, not the structure’s fault or Microsoft’s fault.  

    To people who want to get rid of the registry completely:  What would you replace it with?  INI files?

    Henry:  In the old, old days, you could usually migrate an application by copying the (one) EXE file and its INI file (assuming you were properly licensed, which some people ignored).  

    Today, you need to reinstall the application anyway, since most applications of any complexity will register DLLs and so on, so you need to use the installer.  Copying the application’s program files folder isn’t enough.  A well-behaved application will let you export and import its settings.  If the applicaiton doesn’t provide this, it’s not the fault of the designers of the registry.

    When you say that you want to migrate an application’s "registration", what do you mean?  Registration generally means licensing and so on, and you SHOULD have to go through registration again on a new computer.

    Otherwise, you have created the ability to buy one copy of a program and install it on 1000 computers.  It’s possible to violate a license agreement, but it shouldn’t be made trivial to do.

    Being able to copy 100% of an app to another PC is not something that needs to be optimized.

  10. Anonymous says:

    David: I think "registration" was referring to things like COM registrations. Licensing is tangential. I agree, though, that app migration is nightmarish under the current Windows development model. COM probably thwarted more would-be pirates than WGA ever did.

  11. Anonymous says:

    What’s really needed is the ability to audit registry changes based on program, which I suspect is not possible with built-in Windows functionality.  On the surface, this might seem reasonable; however, things would get tricky if audited-program-A asks trusted, non-audited-program-B to make a change to the registry.  I’m not sure if this actually happens, or if programs directly always directly access the registry.  I am fairly sure that one would have to be fairly restrictive in what is audited, to avoid performance and log size issues.

    Note that one can monitor registry access with SysInternals’ Process Monitor: http://www.microsoft.com/technet/sysinternals/utilities/processmonitor.mspx .  I once saw a quasi-auditing-program that somehow monitored software installs in order to track all changes to the system.  I don’t know whether said program stayed active and monitored all of the [registry] operations performed by the installed software or not.  I also don’t know what kind of performance penalty said auditing program incurred.

    [Um, security audits already record the program name. -Raymond]
  12. Anonymous says:

    @fini: While it is true that POSIX system tend to clutter the system in multiple locations, the Unix world developed a way to deal with that problem, namely packages. You have a standard way of installing and uninstalling applications that you don’t have to explicitely code for. As opposed to, say, .MSI installers, where you have to explicitely write the cleanup code, specially when the Registry is involved(or, god forbid, COM objects). Plus, you know where the configuration files are: either in /etc (usually for daemons and other system-wide applications) or in the user’s home directory (or, in some cases, both, with the /etc being general system configuration or a configuration template). But you do know where to look for the data, and what to back up.

    The issues raised here are interesting. I suppose applications can run in some or even all of those issues when dealing with configuration files. System configuration information is more likely to run into the mentioned issues. It is a matter of courtesy that Microsoft allowed, or even recommended, that applications can use the Registry machinery to store their configurations, alongside vital OS data.

    The registry would be better if it had a clearer separation between "System" data and "Application" data. Anything added to the Registry should be recorded by application name and also be removed by application. Any changes to system configurations should also be recorded by application, and able to be rolled back by application.

    There is absolutely no need for an application such as "SimCity 2000" to record the "Mayor Name" in the registry. Even if there were, this and all related information should be easily migrated to another PC, or removed entirely if required.

  13. Anonymous says:

    Hope this doesn’t sound like a "GOTCHA!" response here, but since .Net 2.0, you can load AND save the XML application settings.

    <projectname>.Properties.Settings.Default.Save();

    This is for my Winforms app — I honestly did feel hobbled in .Net 1.1 where I could load config files, but not save them.   It’s like… "errr… so why don’t I just go use the registry then?"

  14. Anonymous says:

    I have found the registry to be unreliable due to corruption.  Users with older machines often have a good portion of the registry corrupted.  This issue was particularly prevelant on WinME.  So much so that it forced us back to using a file that we could create a primary and backup of.

    At the time I found that reading and writing from the Registry repeatedly would eventually fail.

  15. Anonymous says:

    One thing that is harder to do with .INI files is to allow sharing of configuration informations between a number of applications. And I think this should be the goal of the registry. I usualy put everything that has not to be shared in config files and the rest in Registry.

  16. Anonymous says:

    @Steven

    Although you are correct that .Net 2.0 does have a Save statement. It will not overwrite your XML config file. All of your changes are stored as essentially a diff file in the users local app settings directory. So in essence the application config file is still never written to.

  17. Anonymous says:

    @Raymond: When I said “audit registry changes based on program”, I meant use the program as a criterion for whether auditing happens.  I thought this would be clear by the sentence “I am fairly sure that one would have to be fairly restrictive in what is audited, to avoid performance and log size issues.”  What I left out is that I’m not sure one could accomplish this “restrictiveness” by just choosing certain keys, unless by default, a program can only touch a small range of keys.  Does this make sense?

    [Mind you, you have the same problem with INI files, so it’s a wash. -Raymond]
  18. Anonymous says:

    As someone who works full time in the area of Configuration Management, how you configure things matters dearly to me.

    -ini files can’t/didnt handle complex dependency trees or cross references.

    -the registry can handle complex trees, but not xrefs

    -random XML file formats do often work, but it depends on the parser, especially with corner cases like xml namespaces, illegal ascii chars, duplicate child elements, etc.

    In unix, every app has its own config syntax. Xorg.conf has cross refs hacked in in one way, samba.conf does it another. Neither format can be easily ‘evaluated’ outside the context of the specific resolution engine built into each tool.

    In windows, the registry added some things (central COM objects, admin+domain control) and took away others (ease of configure-by-file copy). To make matters worse, although most .msi installers could hand off registry config to the OS, declaring what they did, the standard installation tools tend to do their own work procedurally. this makes uninstalling harder, as the OS doesn’t really know happened. This is why SystemRestore and app uninstalls are so unpredictable: nothing really knows what state change operations on the registry where intentional, which werent.

    So: all formats are flawed, each differently. Once we’ve all got tired of XML formats with home rolled include/xref mechanisms, maybe we can move to using RDF triples and have argumentes about vocabularies and ontologies instead…

  19. Anonymous says:

    egh: In a word: No.

  20. Anonymous says:

    There’s nothing really stopping you from writing your app however you want — you don’t have to use registry keys (if you want it to run from a USB key or something).  Registry entries are just the newest and most supported way of doing things.  INI files are a mess and you shouldn’t use them, but don’t think that you can’t use them anymore.  I don’t understand how people get their hackles up over the registry when the alternatives still exist (but are much, much worse).

  21. Anonymous says:

    My problem is not with the idea of a configuration database like the registry (per se), but rather the following (most of which are implementation details):

    . Added transactional operations, but removed the opportunity to interact with the objects in any other way.  This ends up manifesting itself most notably as the "no easy way to migrate an application’s settings between machines" problem.

    . No sane user-visible tool for manipulating registry entries (unless Vista has come up with one).  That is — manipulating the registry is foremost a programming interface.  Regedit is not even 1/10 of what is needed for even a knowledgeable person to make edits easily (ie I know what I want to change, let me do so without feeling like I’m using Win3.x)

    . The registry is not self-documenting.  While .ini files are all kinds of nasty, at least one could add comments in place to document what was going on.  Note that I’m not asking for every item to have help text, just an easy way to accomplish something similar to

    [section]

    ; If foo is 1 it means thus

    ; If foo is 2 it means the other thing..

    foo=1

    (Maybe this would not have been appropriate in the early days, but certainly size and access speed are not the primary problems with the registry today)

    Note all of these are my impressions as an end-user, sysadmin, and software QA guy.  It’s possible that I’m missing some of the finer point of the registry.  I will say that in general, registry issues are some of the most annoying in my experience with Microsoft operating systems and applications..

    Note also that I’m not suggesting that .ini files are a good solution either — but there are systems that have solutions that are better (if not themselves perfect).  (I’m thinking of OS X on the desktop and Debian on the server).

  22. Anonymous says:

    Oh come on people.

    You write a buggy app that maybe remembers its window position and the last couple of files that were open.

    Put it in the registry.

    To the guy who mentioned using INI files in a nested directory structure… yeah let’s clog the filesystem like there’s no tomorrow!  What’s a little extra thrashing to fetch that window position?

    I like the registry, primarily because of its efficiency both in disk usage and speed.  The problem, I think, is that there is a lot of interdependent stuff that can get buggy.  I don’t see that as a registry problem though.

  23. Anonymous says:

    (addendum to the third point in the comment I wrote above, regarding “self documenting”):

    I’m not suggesting that all configuration files should be, in any way, self-documenting — just that it’s natural and nice to be able to do so.  Even if machines are the primary consumers of the data, it doesn’t mean that system and application designers can’t make it easier for humans to interact with as well.  (Especially given that so many fixes and tuning parameters seem to involve changing the registry).

    [Isn’t that what documentation is for? A single-line comment sounds like you’re just giving the users enough rope to hang themselves. At least the users who can read English. If you want to put documentation in the registry, then go ahead and add a ValueName_Description:REG_SZ:”0 means use method X, 1 means use method Y” to all your registry values. -Raymond]
  24. Anonymous says:

    Since when were the xml files read only?  It seems like .net can leave your ~/Local Settings/Application Data/{appname}/ folders riddled with xml .config files that are written and rewritten by the app.

  25. Anonymous says:

    Re: Raymond’s comments “Yes, there’s a denial of service attack, tough. You didn’t care about central administration anyway.” -Raymond]”

    Does the registry allow you to do transactions on a series of updates?  That is, can I say:

    read key K -> i

    i++;

    write i -> K

    And have this work reliably?  (And of course for larger sequences of reads and writes).

    [Don’t be helpless. Use a search engine. -Raymond]
  26. Anonymous says:

    “XML file security is not granular enough.”

    Why do you insist on keeping user and system-wide settings in the same configuration file. The user-config lives in an XML file in the users home directory, and the admin setting live in the system-wide configuration directory (/etc on unix).

    [Even if you split them that way – How would an administrator lock a user setting? -Raymond]

    “But since the XML configuration file is read-only, the primary objection is sidestepped.”

    I see no reason why it should be read-only, it’s quite easy to read an XML file, modify it and write it back.

    [And then you reintroduce the race condition. -Raymond]

    ” (But if you want only administrators to have permission to read specific parts of the XML, then you’re in trouble.)”

    Split it in 2 files, they shouldn’t be combined anyway. What if the user is roaming around the network, in the Unix-style system this is no problem, user specific settings are in the users home directory, if this is on a shared filesystem/fileserver then the user has his personal settings and preferences everywhere he logs in on the network. His home directory contains only his personal settings, system-wide settings e.g. configuration of the network or hardware, live in the local system configuration and is not shared.

    How would you do this when the configuration file shares both kinds of information ?

    “Since XML configuration files are read-only, you don’t have to worry about multiple writers.”

    Again, why should they be read-only ?

    “XML configuration files files can suffer a denial of service. You can still open them exclusively and lock out other processes.”

    Not if they live in a protected directory.  The users config is only accessible by that user (and why would he DoS himself) and the system’s config is only accessible by the system (and why would the admin DoS his own system).

    [A normal user can open the file for deny-write and prevent the administrator from changing settings. -Raymond]

    “XML files contain only strings. If you want to store binary data, you have to encode it somehow.”

    Just include the path to the binary data file in the XML. Why does everything have to live in 1 file ? That’s why we have a filesystem in the first place. If you wanted one big file, you could just treat the whole drive as 1 file.

    “Parsing an XML file is comparatively slow. But since they’re read-only, you can safely cache the parsed result, so you only need to parse once.”

    The operative word being ‘relatively’ .

    “Programs parse XML files manually, but the XML format is already locked, so you couldn’t extend it anyway even if you wanted to. “

    Of course you could, and why shouldn’t you ? And most programs use an off-the-shelf XML parser library that can parse the file for you. Why invent the wheel twice ?

    Your entire article misses the point completely. The only difference between XML (or INI files) and the registry is the on-disk storage. The big advantage of XML is that it is human-readable, which can be a real lifesaver in case of say a fatal system error.

    The problem with multiple processes accessing an XML or INI file is not caused by the on-disk format, that could just af well happen with a binary file. In both cases the problem is solved by controlling the point of access to that file. The registry API functions as a single point of access to the actual binary blob on disk that is the registry. If you’d change the registry to one or more XML files on disk that were human readable, you would be able to do so without breaking a single program, the registry API hides the actual on-disk format from the applications. You’d have the same advantages as the current registry, and the advantages of a human-readable format.

    The big advantage of the registry is that is provides a single point of access to the settings, but this does not depend on the on-disk format.

    [If it’s a text file programs can open directly, then you have created multiple points of access again. -Raymond]
  27. Anonymous says:

    "To the guy who mentioned using INI files in a nested directory structure… yeah let’s clog the filesystem like there’s no tomorrow!"

    That is what the filesystem is for. Open regedit, doesn’t it kinda look like .. a directory structure ? With keys (file) which contain values (data). Yeah, let’s put a different kind of filesystem inside a file in another filesystem!

  28. Anonymous says:

    "If you’d change the registry to one or more XML files on disk that were human readable, you would be able to do so without breaking a single program, the registry API hides the actual on-disk format from the applications."

    You then introduce the possibility of people (or programs) introducing things into the xml file that the OS parser doesn’t understand.

    I find some of WinNT’s system registry keys very readable.  The main problem I see is at the UI config level (e.g. the complexity of the CLSID keys), something which is independent of format, I think.

    I am not against text configuration files, but I just think that a lot of apps don’t really store important information to merit it, and therefore it should go into the registry.  Even according to MS, if you have more than 2kb of data to store, it should be put elsewhere.

  29. Anonymous says:

    Aaargh!:

    You should try hacking registry files to see what their structure is.  Just because it looks like a filesystem in regedit doesn’t make it as complex as, say NTFS.  The registry doesn’t have to worry about complex cluster management.  The registry allows simpler and more efficient caching.  Do you really want the Windows file cache using a 4KB page for each INI file?

    Why do you think the Send To menu isn’t as responsive as the main context menu for a file?

    There is a reason why databases exist in this world instead of little files scattered in a directory structure.

  30. Anonymous says:

    “[Even if you split them that way – How would an administrator lock a user setting? -Raymond]”

    He could make the file containing that setting read only for the user, but that would also mean the user can’t edit other settings in the same file.

    But really, he shouldn’t, it’s a user setting and the administrator has no business meddling with users settings.

    [System administrators feel otherwise. -Raymond]

    “[And then you reintroduce the race condition. -Raymond]”

    Not if there is a single point of access, say a configuration daemon.

    [In that case, who cares what the file format is? -Raymond]

    “[A normal user can open the file for deny-write and prevent the administrator from changing settings. -Raymond]”

    Only on windows, and only by design. flock() on Unix is advisory only.  If you’re only reading a file and nobody is supposed to have a lock on it anyway (as with most configuration files), there is no reason to do an flock and block on that.

    [Oh, I’m sorry. I thought we were discussing Windows, not Unix. -Raymond]

    “[If it’s a text file programs can open directly, then you have created multiple points of access again. -Raymond]”

    There is always access rights, but really, why is the format of the file important ? Any file could potentially be edited directly by programs.

    [Exactly. It’s all about the access point. The registry is an access point; you can’t open the .DAT file directly. So I guess we agree. -Raymond]

    “You then introduce the possibility of people (or programs) introducing things into the xml file that the OS parser doesn’t understand.”

    The same thing can be said for editing the registry with a hex editor.  You use a proper XML parser/DOM to edit the XML.

    “Just because it looks like a filesystem in regedit doesn’t make it as complex as, say NTFS.”

    Let’s all switch back to FAT16, it was so nice and simple.

    “The registry doesn’t have to worry about complex cluster management.”

    No, it let’s the filesystem do that for it. Just like when you store it directly in a file

    “The registry allows simpler and more efficient caching.  Do you really want the Windows file cache using a 4KB page for each INI file?”

    So the registry exists because the Windows file cache is inefficient ? Maybe they should have put all that effort in fixing the windows file cache then.

  31. Anonymous says:

    "Boot Windows off a CD (use WinPE) and then run regedit from the CD. -Raymond"

    Does that contain a tool to fix any structural damage to the registry ? Like fsck or scandisk for filesystems ? Damaged .conf files can be repaired easily, worst case you could rewrite the whole file from scratch with the help of a man page. How do you fix a mutilated registry file ?

  32. Anonymous says:

    [Said clue was caught years ago. Boot Windows off a CD (use WinPE) and then run regedit from the CD. -Raymond]

    I’m sure that’s just ducky if you’re in a corporate environment and have access to a Volume License that includes WinPE.  So what do you have to tell those of us who are asked to repair aunt Sally’s desktop PC while we’re visiting her on vacation, and the only resource we have is our working laptop and her Windows XP installation CD?  (Or cousin Joe.  Or grandma Mabel.  Or the neighbors down the street.  Or that guy your father golfs with every other Tuesday.  Or…)

    Actually, okay, WinPE 2.0 is available to the public now (though MSFT seems loathe to admit it’s available), but prior to THIS YEAR, you really did have to have a corporate Volume License to get anywhere near it:  Hence the lingering existence of a number of third-party solutions, each more hacky than the next.  I wouldn’t exactly call that a viable solution "years ago."

    Would it really have killed you guys to include even a marginally-functional RegEdit on the Windows XP Install CD?

  33. Anonymous says:

    "the administrator has no business meddling with users settings"

    Come again?

  34. Anonymous says:

    @BrianK:

    "Of course the registry API has the same problem…"

    No it doesn’t. Read the article again, threads are changing different settings.

    All in all I have to say this topic seems very sensitive for many users… it certainly indicates that there is much frustration with the current system (registry)

  35. Anonymous says:

    Aaargh!:

    "Let’s all switch back to FAT16, it was so nice and simple."

    I prefer punch cards.  The data is in a form I can visually inspect. ;-)

    "No, it let’s the filesystem do that for it. Just like when you store it directly in a file"

    You miss the point.  The filesystem only has to worry about cluster management for a few reg hives, e.g. USER.DAT.  When you delete and create keys and data, it quite likely that the .DAT file doesn’t have to change much in size, so the file system drive doesn’t need to do much work.  If you start having lots of INI files, then the file system needs to manage every one of them.

    "So the registry exists because the Windows file cache is inefficient ? Maybe they should have put all that effort in fixing the windows file cache then."

    There is nothing wrong with the Windows cache.    The registry hives are just memory-mapped.  Need a particular integer?  Just get it.  Nothing to parse.

    The point I’m trying to make is that e.g. the Start Menu and the Send To menu are not as responsive as registry-backed UI elements; for commonly used data by the system, it should be in the most efficient format, both speed wise and disk usage wise.

    It is simply a waste of resources storing data in a human readable format that is primarily used by a computer program.

  36. Anonymous says:

    In reply to Bob: "There’s a reason I uninstall most applications – they are garbage.  I don’t want my preferences remembered when I’m chucking the software.  I would say those programs think too highly of themselves, but I doubt seriously that the programs are leaving the registry data behind for me and re-installs.  I bet 99% do it only because of the time, money, effort involved in coding the total removal."

    Programs cannot and should not delete user settings when uninstalled. Per-user and per-computer data are isolated. The program only has (proper) access to the data in the account it is being uninstalled under, and the latest copy of the profile of the primary user of the application may not even be located on that machine, if it is a roaming profile.

  37. Anonymous says:

    “If you start having lots of INI files, then the file system needs to manage every one of them.”

    Yes, I realize that, it’s kind of the function of the filesystem to do that, it’s supposed to be good at it. So if the filesystem can’t handle it, maybe you should improve the filesystem, that doesn’t only benefit the ‘registry’, but also all other operations with lots of small files.

    “It is simply a waste of resources storing data in a human readable format that is primarily used by a computer program.”

    Apple has an elegant solution, .plist files are basically XML files but can also be in a binary format, there is a command-line utility called ‘plutil’ that can convert them from binary to human readable and vice versa (there is also a GUI editor). Applications using these plist files (through the appropriate API’s) can use both types transparently. If you want to tweak something, just convert it to human readable, and when done tweaking return it to binary if you prefer.

    “Come again?”

    the administrator has no business meddling with users settings, that’s why they are called user settings.

    [The administrator can control what the employees run on the computer. That’s why it’s called the administrator. I think that’s the fundamental disagreement. This INI vs registry thing is just a cover. -Raymond]
  38. Anonymous says:

    While we are all sharing the love with respect to the registry and INI files, one thing I find funny in regedit is that it as a "Favorites" menu.  Now, it makes sense to me to call it that, since "Favorites" has become a standard word for MS, but I just find it funny to call oft-used bookmarks to system configuration data "Favorites".  Like as if going to HKLMSOFTWAREMicrosoftWindowsCurrentVersion or something gives me a warm fuzzy feeling or going to HKLMSYSTEMCurrentControlSet feels like a big warm hug.

  39. Anonymous says:

    Around the Win95 release, Dr. Dobbs or some other magazine published an article "Why I hate the registry." I think three of the reasons listed were "It’s one file." I shudder at the implication that somewhere in the world an application is accessing the registry through direct file I/O.

  40. Anonymous says:

    Hi,

    I’d like to warn you that XML files are NOT read-only. Many applications store their configuration settings in XML files and allow their UI to modify them.

    As examples, the FileZilla FTP client, the matching FTP server…

  41. Anonymous says:

    [Not if there is a single point of access, say a configuration daemon.]

    Great idea! We could even store all the config files in one place. Each program could have a it’s own config file that the daemon allows you to read from and write to.  Hmm, sounds kind of familiar. Oh, that’s right, it sounds like the registry.

    [So the registry exists because the Windows file cache is inefficient? Maybe they should have put all that effort in fixing the windows file cache then.]

    You’re right. Software like MSSQL and MySQL are obviously just making up for crappy filesystems. Database software is a waste of time, we should just optimize filesystems and use flat files.

    [I’m sure that’s just ducky if you’re in a corporate environment and have access to a Volume License that includes WinPE.]

    BartPE.

    [If you want to put documentation in the registry, then go ahead and add a ValueName_Description:REG_SZ:"0 means use method X, 1 means use method Y" to all your registry values.]

    Good idea! Now just to update MSDN: "KB6523907 Storing Documentation About Values in the Registry" ;)

  42. Anonymous says:

    “Programs cannot and should not delete user settings when uninstalled. Per-user and per-computer data are isolated.”

    The problem with Windows application installation is (and always has been) a lack of API.  Everything is done by convention: copy files here, add registry keys there, overwrite this system DLL but not this one, etc.

    The problem with doing things by convention is you’re stuck with it.  

    What should have happened is that the Program Files directory and all the system directories should not be writable directly.  Installers should be forced through an API and then everything they do can be tracked, undone, repeated, and even remapped entirely if security rules change or Microsoft wants to rename all the directories again.  The same is true for the registry.  And when you uninstall, the operating system takes care of cleaning up the mess.  

    There’s nothing wrong with registry except that it’s basically just another big dumb file system.  

    [Where were you in 1983 when Windows was being designed? You could’ve helped us add ACLs to MS-DOS 2.0. -Raymond]
  43. Anonymous says:

    To answer my question regarding registry transactions, it seems the answer is:

    “yes, in Vista”

    (would it have been so hard to write those three words?  Granted, you’re allowed to be snarky in your own blog. ;-)

    [Teach a man to fish… -Raymond]
  44. Anonymous says:

    Whatever happened to Registry cleaning tools?  Microsoft formerly made available one, but… a few years back this appeared to have been revoked (i.e no longer publicly available).  I understand that Microsoft shipping a registry cleaning/repairing tool opens new can(s) of worms, but many third party tools do this.  So, my question: Why can’t Microsoft make available (i.e. include) an improved regclean tool?  This tool could be used to clean up after piggy/bad programs  I wouldn’t expect this tool to be perfect, but it would be nice to not install third party tools to clean up after other third party tools (and the circle continues).

  45. Anonymous says:

    Aaargh!:

    “…that doesn’t only benefit the ‘registry’, but also all other operations with lots of small files.”

    Let me put it to you this way.  Does your federal government organise garbage collection in your city, or the local council?

    I don’t believe in run-time optimisation.  If you know you have lots of small chucks of data, put them together and use a more efficient system to access them.  Something that is good for working with small files probably won’t be good with large files.

    The binary plist thing you mentioned seems like an interesting idea.  I personally thought once it would be good if there was a standard binary format that can be edited by anything.

    I still don’t have a problem with the registry (and I prefer it for most things), but pfiles seem okay (particularly for applications, if there is just one pfile per app).  For something like file association data and system configuration, I still prefer one big binary file.

    [As long as there’s a way to find all those small chunks of data and centrally administer them. -Raymond]
  46. Anonymous says:

    Paul said: “The Registry, like COM and .doc files, is a really, really bad solution to a problem that never actually existed. It’s telling that no other OS has it.”

    OS X has the similar idea of “defaults” that are stored in some random opaque location.  X11 has properties (which are stored in something vaguely like the registry in-memory).

    I don’t think the basic idea is bad: providing a well-defined (and now transactional), access-controlled mechanism for coordinated system configuration.  I still think that the Windows registry has a lot of cruft built in and pisses a lot of people off for reasons that could be fixed. (how hard would it be to provide a friendly registry editor?  Saying “a complete solution is impossible” isn’t an excuse.  I just want something that doesn’t feel like it was coded in 15 minutes as a sample program.)

    [Okay, next time somebody complains that Windows does an incomplete job, I can tell them that you said it was okay. (Besides, end users shouldn’t be mucking about in the registry any more than they should be using hex editors to edit binary files.) -Raymond]
  47. Anonymous says:

    Nick: "Database software is a waste of time, we should just optimize filesystems and use flat files."

    It is a waste of time.  MS should just follow the popular trend and store system data in an Excel spreadsheet. ;)

  48. Anonymous says:

    “Where were you in 1983 when Windows was being designed?”

    The Program Files directory was added in NT correct?  Windows 3.1 programs didn’t go there.  Seems like a perfect time and place to restrict it.  Same with keeping stuff out of the Windows directory…  leave a place for old programs to mess with much but constrain new programs.

    I didn’t have to be there in 1983..  perhaps 1993.

    I still don’t really understand why programs (with the right permissions) can walk all over any critical file in the system.  Yes, sometimes you have to install a new system DLL — but why isn’t there gated access?  You can’t rely on installers to not overwrite previous versions but an API could make those sort of determinations.

    [If you waited until then, you would’ve been to late. All the old Windows programs that installed into, say, C:MYPROG, would have stopped working. Or if you want to have two sets of rules, then everybody will say, “Well screw the new rules. I’ll just use the old rules. They didn’t try to stop me from replacing file XYZ.” -Raymond]
  49. Anonymous says:

    AlmostAlive, what do you think the Windows Installer API is?

    As of Windows XP, the standard method of installing a global library does require you to go through the Windows Installer API. But the old methods still have to be supported for a while, for compatibility.

    You also seem to be complaining that nothing in Windows saves you from having to specify what needs to be installed. Well, it’s an operating system, not magic.

  50. Anonymous says:

    [Okay, next time somebody complains that Windows does an incomplete job, I can tell them that you said it was okay. […]

    Hurray!  Do I get stock options for this contribution??

    [(Besides, end users shouldn’t be mucking about in the registry any more than they should be using hex editors to edit binary files.) -Raymond]

    I hope (really, really hope) that there is a hidden smiley-face in there somewhere.  

    Given the number of registry edits I’ve had to apply to systems (as directed by MSDN articles, product manuals, or Microsoft technical support representatives), either

    1) I’m not an end user or

    2) there are a whole lot people who don’t agree with you who work for Microsoft.

    PS, I’m trying really hard to stay on-topic here.

  51. Anonymous says:

    Paul: "The Registry, like COM and .doc files, is a really, really bad solution to a problem that never actually existed. It’s telling that no other OS has it."

    I LOL’d at that.  Lumping the registry, COM and .doc files together like that.  Particularly the mention of .doc files.  So what problem did .doc files try to solve that never actually existed?  And the "no other OS has it."  LOL!  

    That’s all I’m saying about that.  You owe me a  new keyboard.

  52. Anonymous says:

    “All the old Windows programs that installed into, say, C:MYPROG, would have stopped working.”

    Huh?  Why would that have stopped working?  You’ve got a whole Windows 3.1 API stuffed into XP.  Lets 16bit applications screw with 16bit DLL’s just like they always had and make 32bit applications play by a better set of rules.  Eventually, you phase out compatibility with the old applications (like you have with 64bit Windows).

    “Or if you want to have two sets of rules”

    You already have two sets of rules, Win16 and Win32.  I don’t get the argument that you have to play by the same rules as 1983 when you’ve had lots of opportunities to change them.  

    “AlmostAlive, what do you think the Windows Installer API is?”

    Gazpacho: Actually, I was going to bring up MSI.  And yes, it does about half of what I mentioned well but you still can uninstall all the setting from all the users when you remove an application.  It doesn’t dig deep enough.  And it still allows apps to trample all over the file system and the registry.  And Raymond has a point, now that the gates are open you can’t have two sets of rules.  It’s too late for MSI to be truly effective.

    “You also seem to be complaining that nothing in Windows saves you from having to specify what needs to be installed.”

    Actually, what I’m saying is nothing in Windows forced you to specify what is being installed.  It’s just a random bunch of files and registry keys.  An API would have allowed Windows to understand what is being done to alter it, undo it, maybe even replicate it.

    [Okay, if you are change the rules for Win32, then you have to go back to Windows NT 3.1, which predated the “Program Files” directory. Oh, and Windows NT 3.1 supported a FAT root partition, so file system security is going to be kind of tricky. Have fun writing a virtualization layer in 8MB of memory. -Raymond]
  53. Anonymous says:

    I have a kind of love-hate relationship to the registry. In some ways it works quite well, mostly at the presenting a uniform and safe interface to configuration data, but my main problem is still the identifying and perhaps migrating data for a specific application.

    One possible solution (which might even be possible to implement without breaking the existing API) would be to support a kind of overlays stored in separate files. For example, an application calls an API to get a token for its overlay. The overlay data are visible to all applications, and changing any data in the overlaid data changes it in the specific file that stores the overlay, but newly created keys would belong to a specific overlay, or the regular (current) registry.

    One way the overlay tokens could perhaps be implemented was through a new API for creating HKEY tokens.

    An overlay could then (somehow) be unloaded from the system and perhaps be moved somewhere else.

    An overlay would then be either machine specific or user specific. (Machine specific ones would probably go in the All Users homedir.)

  54. Dean Harding says:

    "The administrator has no business meddling with users settings"

    Maybe if we say it often enough, it’ll become true…

  55. Dean Harding says:

    "You’ve got a whole Windows 3.1 API stuffed into XP.  Lets 16bit applications screw with 16bit DLL’s just like they always had and make 32bit applications play by a better set of rules.  Eventually, you phase out compatibility with the old applications"

    If you did that, nobody would have written 32-bit programs and then you wouldn’t be ABLE to phase anything out…

  56. Anonymous says:

    Dean you’re saying that nobody would haved developed for a new API?  I guess Microsoft should never have created .NET — doomed to failure.  

    Developers like well designed and useful APIs and languages and they’ll go out of there way to use them — sometimes when it isn’t even practical.

    [It’s all about the value proposition. “Hey, here’s a new API. The new one is more restrictive. You can’t do as much with the new API as the old one.” That’s not going to win over many people. -Raymond]
  57. Anonymous says:

    As has been opined by many in these comments, every storage implementation has it’s pros and cons.

    The problem was that INI’s were declared persona non grata and The Registry feted as the solution to all the problems associated with INI files.

    Which was fine as far as that went….  and as long as you are happy to embrace the problems that THE REGISTRY brought to the party.

    If The Registry had been presented as just one new option IN ADDITION to INI files then developers could have chosen the mechanism most appropriate to their needs (often perhaps varying even within a single application) and even if not everyone was happy, I guess a lot more people would have been.

    Of course, nobody was ever FORCED to stop using INI files, but their official deprecation was effectively a public tar and feathering for any application so outmoded as tobe seen to continue using them.

    XML files took the stigma off of INI files by giving them a sexy NEW name and a "modern" look and feel. (i.e. bloated, cluttered, verbose and with just a bit of a whiff of HTML – that sexy new web tech so it must be "cool")

    It was possible, with very little effort, to get just as much structure in an INI file as is present in many XML files and often with far more clarity.

    Had the INI API been maintained and extended, who knows what we might have today.

  58. Anonymous says:

    I have to admit that I prefer INI to registry most of the time. Many of the apps I work on don’t need to share config data, or special security measures, or concurrency checks – in other words they just need a SimpleConfiguration API. Yes, I know this sounds very much like INI files API. I like the ease of migration (xcopy) that comes w/ some .net apps but unfortunately it’s easy to ref an assembly or DLL that requires COM and now the Simple API can’t be used. In the end this just means more job security so I guess I can’t complain too much…

  59. Anonymous says:

    “It’s all about the value proposition. ‘Hey, here’s a new API. The new one is more restrictive. You can’t do as much with the new API as the old one.’ That’s not going to win over many people.”

    I disagree.  The old way is not really to have an API at all.  Just copy files around and add registry keys.  An API would be easier to use and safer.  That’s the value proposition.

    And I suspect many developers would choose a slightly more restrictive API over DLL hell and registry bloat.

    [I guess that explains why nobody uses custom installers any more and everybody deploys MSI packages. -Raymond]
  60. Anonymous says:

    The registry doesn’t have enough segregation. Any program can party on (most) any part of it, including other programs settings. So when you want to do something to ONE program and ONE alone, it becomes a wild goose hunt to find all of that programs settings. That is my opinion, and judging from the comments it seems many people share it.

  61. Anonymous says:

    [XML files took the stigma off of INI files by giving them a sexy NEW name and a "modern" look and feel. (i.e. bloated, cluttered, verbose and with just a bit of a whiff of HTML – that sexy new web tech so it must be "cool")]

    So what you’re saying that XML files are "INI 2.0".  Brillant! :)

  62. Anonymous says:

    [I disagree.  The old way is not really to have an API at all.  Just copy files around and add registry keys.  An API would be easier to use and safer.  That’s the value proposition.

    And I suspect many developers would choose a slightly more restrictive API over DLL hell and registry bloat.]

    Ah! So you live in a parallel universe where applications like <non-Microsoft web media player developed in Seattle> didn’t stomp all over every user setting you can think of and violate every rule of "good software" there is? I wish I lived in the same universe you do.

    Unfortunately, Microsoft learned long ago that you can’t trust developers to do the right thing. Guess how long it took <IBM-owned email client that competes with Outlook> to properly support multiple users? I’ll give you a hint: It wasn’t NT4, and it wasn’t Windows 2000, and it was at least a decade later than it should have been.

  63. Anonymous says:

    I love the fact that there’s the Registry and it’s somewhat popular, though I never use it.

    Because it’s one more feature I can list for my applications: "Does not use Windows registry"…

  64. Anonymous says:

    Sure, XML files are *supposed* to be read only, but we know developers always follow the rules.  Right?

    …and then there are the people that just can’t let go:

    http://msmvps.com/blogs/martinzugec/archive/2006/03/01/85113.aspx

  65. Anonymous says:

    Well, ini files (meaning .ini, .xml, etc.) obviously have disadvantages. But they also have advantages.

    You can easily fit all program + configuration into a single directory, which allows

    – “an application on a memory stick”,

    – “an application without installer”,

    – “an application with very limited rights” (write and write only one directory, no registry access allowed),

    –  multiple versions to exist peacefully without any clever thoughts along the lines: “gee, what else did I forget that gets silently overwritten by the installer.”,

    – modify a config file by hand, quick and dirty style.

    – config files can be defragmented on disk easily :o

    As for the disadvantages – these are curable with some effort (well: effort is a disadvantage in itself ;-)):

    – read / write race conditions can be handled in a variety of ways:

     + lock the file

     + use Mutexes

     + allow only one instance at a time

     + work on a temp. copy.

    – denial of service:

     + Kind of an “other side of an airtight hatch” problem. Basically any program that can lock an arbitrary file will be able to do a DOS-attack.

    – security granularity:

    partitioning of the “one big inifiles” into several small ones with different ACLs allows to circumvent this.

    – parsing is slow:

    There’s no cure against access being O(N), other than making sure N is small. So split them up. smaller files -> faster parsing.

    – INI files contain only two levels of structure.

    again, split them up into several files, if necessary use a directory hierarchy

    – .ini files are 32kB max:

    call them .conf files and use your own parser

    – The default location for INI files was the Windows directory!

    And 640 kB used to be enough for everybody (This is no sarcasm. Back then it *really* was). But that’s a sin from the past, ini-files went through rehab and don’t do this anymore (well … it’s hard to stay clean for some ;-)

    – ini files contain only strings:

    ini-files are definitely not meant to contain large quantities of binary data. ASCII-encoding is good enough for small quantities though.

    – no UNICODE support:

    unless you insist on using the windows API for handling inilike-files, I don’t see the problem?

    – handwritten parsers are flaky:

    Yes. On the other hand, the ini-file format is simple enough to write your own little API and test it adequately. And using std::getline and std::string, I haven’t yet seen any buffer overruns.

    So IMVHO the only real disadvantage of ini-files & co. is that it’s more effort to implement compared to using the registry.

    Oh, and it’s much harder to hide information from the user (Time limited test versions anyone?). Though, XML files can be at least as good at obfuscation as is the registry ;-)

    As a user, I *like* config/ini – files.

    Felix

    [I like argument through assertion. “You won’t have any buggy INI file parsers if you don’t write buggy INI file parsers.” And argument through blame-shifting: “You can avoid the race conditions by introducing a denial of service attack.” And then argument through discount: “Yes, there’s a denial of service attack, tough. You didn’t care about central administration anyway.” -Raymond]
  66. Anonymous says:

    The main reason I like INI files is they are portable.  For instance, if I want to move my installation of Forte Agent to another machine, all I need do is move the program folder containing the INI file.  No messy reinstalling or configuring.

    If programs that use the registry would be consistent in where they store settings, one could just export that bit from the registry.  But they aren’t.

  67. "The Registry, like COM and .doc files, is a really, really bad solution to a problem that never actually existed. It’s telling that no other OS has it."

    And OSX has COM (or a set of constructs that are sufficiently close to COM that Apple refers to COM in their documentation).  And Firefox has a plugin model that is essentially identical to COM.

    So there are many examples of places where OS and application vendors have implemented mechanisms that are very similar to COM.

  68. Anonymous says:

    [Teach a man to fish… -Raymond]

    Light a fire for a man, and he’s warm for a day.  Light a man on fire, and he’s warm for the rest of his life.

    "Because it’s one more feature I can list for my applications: "Does not use Windows registry"…"

    I’m sure Grandma will read that on your product marketing and care so much.  Of course, all my non-Windows apps I’ve written can say this, but that is just semantics.

    "Any program can party on (most) any part of it, including other programs settings."

    This isn’t necessarily a problem.  If I have a suite of programs, like Office, one application ought to be able to manage the others (or a server config app separate from the server, whatever).  Don’t forget, the application is running with the exact same privs as the user himself.  Even if you tried to do some sort of OS enforced rule here, there are going to be all sorts of holes you can poke into it.

    Again, a lot of people are missing that if you’re a smart programmer you can write the application to run regardless of the registry.  Sysinternals tools come to mind — they don’t require any setup and typically just run (even without a INI file).  Sure, they write some things out but you can always copy the executible to a new machine and it will still work.  (heck, the things are pretty genius in how they work as it is)

  69. Anonymous says:

    The registry doesn’t have enough segregation. Any program can party on (most) any part of it, including other programs settings.

    What stops programs from partying on other programs’ INI files?

  70. Anonymous says:

    * You can get around the Unicode issue by reading/writing UTF-8 data into the INI file.

    * Get/WritePrivateProfileString locks the file between access requests.  Take a look in filemon to see what I mean.  There is an Lock, Open, Read (or Write), Unlock around every call.  There should be no multithreading issues, although obviously this is a bit slow.

    * Your application can (and should) cache the contents at startup time.  Just the same as you wouldn’t re-parse an XML file or re-read from the registry every time you need to check whether or not some option is enabled.

    * GetPrivateProfileSection is an effective way to speed up reading of an entire INI file at once, assuming you don’t have a lot of ‘dead’ keys.

  71. Anonymous says:

    That in itself might not be a problem.

    Having programs able to party all over the registry isn’t the same as having programs configure each other.

    How is this any different?

    "Configuring" and "trampling" are both "modifying".  It’s like "fermentation" and "rotting".  They’re both a form of "biodegration", just the difference between whether something is constructive or destructive.  You can’t expect the computer to know the difference (and wouldn’t want it to, anyway).  All you can expect is for the computer to either allow or disallow, based on permissions, which the registry gives finer control over (at the key level, rather than grouped by file).

    that’s just the way Windows works.

    there are certainly OS’s out there where programs are not run at the privilege of the user.

    Isn’t this done by creating a user just for running said program?  Then you can "give the program" any set of privileges as you want.  That way that program won’t be able to mess with any program or settings it doesn’t have permission to mess with.

    This holds true regardless of whether settings are held in INI files, text config files, or the registry.

  72. Anonymous says:

    "Configuring" and "trampling" are both "modifying".  It’s like "fermentation" and "rotting".  They’re both a form of "biodegration", just the difference between whether something is constructive or destructive.

    It’s not the configuring part. It’s the all over the registry part. The program could put its settings in any part of the registry, or create a hundred keys and stick them all under there. When you want to move or delete the program, finding all its settings (Including extension handlers, COM objects, CLSIDs, and all the other registry databases) becomes next to impossible.

    Isn’t this done by creating a user just for running said program?  Then you can "give the program" any set of privileges as you want.

    You’re thinking of UNIX. That’s not what I meant. But since it’s offtopic and I have a tendancy to go overboard on that particular subject I’m not saying any more about it.

  73. Anonymous says:

    Off-topic but why am I getting something like 10,000 registry reads a minute when the only program running is regmon?

    How many drowned Bangladeshis are there going to be as a result of the global warming caused by all these extra cycle?

  74. Igor Levicki says:

    >INI files don’t support Unicode.

    You could have encoded Unicode characters in hex and keep ANSI characters as straight text.

    >INI file security is not granular enough.

    True but you can have two or more INI files, one for keeping the admin settings and others for keeping per user settings.

    [And what if you want to secure one of the per-user settings but not another? Or will we have a separate INI file for each setting? -Raymond]

    >Multiple writers to an INI file can result in data loss.

    Per user settings should not be a problem here, since each user could have its own INI file. Only the admin INI part could be a problem if you have two admins which is a bad idea to begin with.

    [Are you saying that one should never run two copies of the same program at the same time? -Raymond]

    >INI files can suffer a denial of service.

    Registry can too. With administrator privilege you can just write directly to physical disk sector and kill the whole OS by zeroing out the registry.

    [Now you’re being disingenuous. -Raymond]

    >INI files contain only strings.

    I don’t see this as such a big problem. If you needed to store blobs you could always store those in separate files and reference them in INI file.

    >Parsing an INI file is comparatively slow.

    This is actually the most problematic part with any text file including XML. Solution to speed up string processing is to use counted strings instead of zero terminated strings.

    >Many programs open INI files and read them directly.

    This could have been prevented if you stored them in a dedicated location and prevented direct access. Yes, I know that sounds too similar to the registry.

    >INI files are limited to 32KB in size.

    That limit was arbitrary and even the registry has one.

    >INI files contain only two levels of structure.

    Should not be a problem. Deep nesting should be avoided anyway, it just creates confusion.

    >Central administration of INI files is difficult.

    If they were standardized it wouldn’t be any more difficult than the current solution.

    [I like how in one branch of the comments, people are saying “You should enforce restrictions on how programs should install; don’t give them a choice” and on another branch people are saying “You should let programs do it however they like and leave it up to them to follow standards voluntarily.” -Raymond]
  75. Anonymous says:

    "Only the admin INI part could be a problem if you have two admins which is a bad idea to begin with."

    I think you’re coming from a standalone PC mindset here.  A lot of Windows PCs do operate in environments where there is more than one Administrator.

  76. Dean Harding says:

    "The program could put its settings in any part of the registry"

    I don’t understand how INI files solve that problem, though. Programs can put their settings in any part of the filesystem, too.

  77. BryanK says:

    benski: Yes, the Get/WritePrivateProfileString functions lock *while they run*.  But that still leaves the race condition that Raymond described: one thread calls Get…, the second calls Get…, then both threads modify their local string and call WritePrivateProfileString back.  Now one thread’s change was lost.  You need locking around the entire read-modify-write, not just each individual read and write.

    Of course the registry API has the same problem…

  78. Anonymous says:

    UNIX uses a file for configuration and not the registry. This makes software maintenance much easier and system upgrades become seamless. Migrating a user’s preferences is as simple as copying his or her home directory to the new system.

    The Registry has security, but if the default user has admin privileges, then what’s the point?

    [What if a program modifies your .emacsrc (to add a handler for its private file type) and your fvwm2rc (to add a context menu for the file type) and your .cshrc (to add itself to your path)? Now its settings are stored in eight lines in three separate files. Good luck migrating that. -Raymond]
  79. Anonymous says:

    Lord Chen,

    [I like how in one branch of the comments, people are saying "You should enforce restrictions on how programs should install; don’t give them a choice" and on another branch people are saying "You should let programs do it however they like and leave it up to them to follow standards voluntarily." -Raymond]

    That’s because the majority of people you are dealing with here are n00bs.  The information they are going from regarding the Windows registry is grossly out of date or just plain inaccurate.  

    The Windows Registry has only had two real problems:

    1.  In the Win9x and NT days it was placed on a FAT partition.  This is where the majority of corruption of a system registry came from.  My registry corruption days ENDED when Windows 2000 came out (and even then I have only had three systems die on me because of the registry).
    2.  Bad uninstallers that didn’t clean up after themselves and left their settings behind.  This problem really started going away again with Windows 2000 and MSI came out.

    I am over-simplifying a bit, but the point is clear enough.

    For those of you making pot shots because you dug yourselves out of the lowest intestines of slashdot just to bitch about Windows again, despite how off your information is, you can imagine what someone like me who is only concerned about really learning this stuff and really makes a living thanks to MS thinks about you right about now.

    JamesNT

  80. Anonymous says:

    [UNIX uses a file for configuration and not the registry. This makes software maintenance much easier and system upgrades become seamless.]

    And the use of files versus the registry makes a difference how?  When you update software on Windows (or Windows itself) it can read from the registry as easily as from files.  

    [Migrating a user’s preferences is as simple as copying his or her home directory to the new system.]

    Sometimes, and calling it "easy" is being awful generous. An active user’s home directory will quickly accumulate a LOT of hidden configuration directories for nearly every application installed.  Figuring out what to copy and what not is no simpler than figuring our which registry keys to export. Sure, you can just copy everything, but you can also just copy the entire user hive too.

  81. Anonymous says:

    I’ve often been frustrated with the Windows Registry, but it’s for a different reason than most of those listed above:  The Registry is, for all its other benefits, a proprietary solution — a very large, well-known, and well-publicized solution, but a proprietary solution nonetheless.  And by that, I mean that there’s a fairly short, finite list of tools that can work with it, and pretty much all of them depend on the Windows kernel.

    Why is this bad?  Maybe if you’ve never had to fix a broken Windows box, you wouldn’t know.  When you have a Windows box that is currently unbootable because some random program ate the Registry, your main option, in most cases, is to reformat the machine and start over, not because of the lack of logs, not because of the lack of audits, but because there’s no way to get into the system, manually fix the damage in the Registry, and continue life normally.

    Contrast this with Un*x’s .conf files, where you can boot off a CD or even via a network and use any of ten thousand different text editors to edit the .conf files until the system is functional again.

    I’ve used both solutions, and I can say hands-down that I’d rather repair a broken Un*x configuration than a broken Windows configuration any day of the week.  Or, more accurately, with Un*x, I at least *can* fix things — sometimes with Windows, you really don’t have any choice but to reformat, and a lot of the blame there can be put on the inaccessibility of the piles of data in the Registry.

    That said, I haven’t used Vista’s repair console yet — so did anyone at Microsoft catch a clue and include a RegEdit equivalent that works off a boot CD, or is there still only an automatic repair system that rarely repairs anything and a command line that knows almost no useful commands?

    [Said clue was caught years ago. Boot Windows off a CD (use WinPE) and then run regedit from the CD. -Raymond]
  82. Anonymous says:

    I still have one question:

    I think the INI files for storing user settings goes to %APPDATA% folder like what Fxxbar does (the .cfg file is not an INI file, but they’re similar). So unless you have the same user login more than once concurrently, there’s little chance of race condition.

    But if you have more than 1 user login at the same time, is it fair to say you’ll face race condition one time or another? (Say the first user reads stringA and modify it, not aware that the second user also attempts to read and modify the same string value, it seems no matter it’s from INI file or regsitry, you’d still have problem.)

    While some may argue that registry is better because it protects your from case that modification is on different line, may I suggest that most of the program I seen write “user settings” to registry at once – touches every keys/values regardless of whether it’s value has been changed or not. In that case if there’s sufficient gap between “read” and “write” (this especially true when program reads settings only when the program is launching, then writes the “modified values” directly from memory without reloading / comparing values first), the scenario is not that different.

    [Yes, you still have race conditions, but at least the race won’t result in the configuration file being corrupted because two programs are writing to it simultaneously. -Raymond]
  83. Anonymous says:

    The Registry, like COM and .doc files, is a really, really bad solution to a problem that never actually existed. It’s telling that no other OS has it.

    Most of the objections read like "Rain is bad, because you catch cold if you stand around in it all day." Admittedly, built in INI support isn’t great, but a lot can still be done with it and writing one’s own (we have Unicode, nested objects, fast and easy read/write, and encryption/digital signing for security) is more fun than wrestling with the real thing or recovering an unbootable system (especially a customer’s) when *anything* goes wrong.

  84. Anonymous says:

    nobody writes to XML configuration files

    8,000 code monkeys all over the world are currently hard at work to remedy this.  Stand by…

    (I was going to create a joke suggestion-box item "Hey Raymond, how do I write to an XML config file?  My project manager has told me we need to do this for our product and I can’t find the API to do this" to point this out, but I thought I’d make it explicit here :-).

  85. Anonymous says:

    "I guess that explains why nobody uses custom installers any more and everybody deploys MSI packages."

    More like MSI (or the version you’re using) may not be deployed on every OS that the program is targeting, or that MSI has (at least early versions) produced hair-pulling situations for end users or that an MSI install loves to sit around "Gathering Required Information" for ages while a custom installer would have completed already.

  86. Anonymous says:

    While I did not create the registry, I was instrumental in causing its existence. There is some talk about this in my Behind the Code talk, which can be found at http://channel9.msdn.com/ShowPost.aspx?PostID=224935 at around 39:15.

    Humorous anecdote: the initial (win16) registry implementation (before shipment) atomized both key names and values strings into a single atom table. When keys were made case-insensitive, the effect was that any initial value inserted would map subsequent inserted values to the case of the initial value (Open ->OPEN etc.). Since values showed up in menus and dialogs, this mattered.  There ensued a lengthy email exchange of views about whether to fix this "bug".

    Finally my manager (a long time senior employee) sent an email saying "if you think it will take an act of God to change this, I will speak to him". I was persona non grata with the Windows team for some time after that.

  87. Anonymous says:

    "The registry is not self-documenting.  While .ini files are all kinds of nasty, at least one could add comments in place to document what was going on."

    That’s a good thing.  It forces documentation (if it exists at all, which is by no means guaranteed either way) to exist elsewhere — such as on a website that can be updated if it turns out there’s a mistake or misleading wording.

    "A normal user can open the file for deny-write and prevent the administrator from changing settings. -Raymond"

    But administrators can break the lock and modify the file anyway, if they really want to.  Admittedly I don’t think Windows provides an easy mechanism out of the box to do this, but I’m sure it’s possible.

    "Actually, okay, WinPE 2.0 is available to the public now"

    It is?  Hey, it is!  Cool, I’ve been wanting to get my hands on that for a while now.  Even if it is only for Vista.

    "It’s all about the value proposition. "Hey, here’s a new API. The new one is more restrictive. You can’t do as much with the new API as the old one." That’s not going to win over many people. -Raymond"

    I’ve seen this exact effect with some of Vista’s changes, actually (mostly UAC, with apps running LUA by default).  I hang around in a forum for software installers, and it seems like every few days someone starts a thread along the lines of "how do I detect Vista so I can make it install into My Documents (or similar) instead of Program Files, since that doesn’t work".  Then it takes several days of explaining that they shouldn’t be doing that, and in the end it’s hard to tell whether they finally got the right idea or whether they’re just stumbling ahead anyway.  Sigh.

    I’m not entirely sure how I feel about the Registry one way or the other, and I tend to use both registry settings and XML config files (which *are* writable by the app!).  The files are more useful when targetting an app-on-USB-drive scenario, and they’re more accessible for user tweaking (although only slightly, since if they’re not actually on the USB drive then they’re off in a hidden folder in the user profile, which isn’t as useful).  And I’ve never been comfortable with having all the settings in one place where it can get munched by a rogue program or bad sector.  But it does provide a nice and fairly uniform way to find things (such as locating where an app is installed in the first place), and as Raymond said it’s better with multi-app crosstalk.

  88. Anonymous says:

    "But administrators can break the lock and modify the file anyway, if they really want to.  Admittedly I don’t think Windows provides an easy mechanism out of the box to do this, but I’m sure it’s possible."

    A superuser can close any file handle, or a user can close their own; I have no idea if it’s possible to change a handle’s flags, but I’m sure there’s an evil undocumented way out there. ;) The best way to close manually is probably Unlocker or system explorer.

    "The Windows Registry has only had two real problems:"

    Three, the registry structure is pretty badly designed. If you stick to HKLMSoftware and HKCUSoftware it’s fine, but HKCR and the CU/LM keys that map to it is an unholy mess. I can understand how it got that way (strict limitations on the first implementation, not a terribly high priority then, can’t do anything about it now) but it’s still difficult to work with programmatically, let alone manually, and more prone to things breaking when bad software hijacks it than other areas.

    I still prefer it to configuration files in random places with random formats; but real APIs are best of all where I can get them. =p

  89. Anonymous says:

    I think the problem with registry is that its widely used by everyone.

    No way in hell 99% of applications needs to write data to registry, and no way in hell they need to use msi installers and bloat like that.

    XCOPY + INI solves 99% of the problems.

    1)Application failure -> XCOPY (whole app or ini only)

    2)Uninstall -> DELETE

    3)Backup -> COPY *.ini d:myappbackup, zip it if needed.

    Instead we have registry, MSI, COM and other nuclear devices to kill flies.

    I so miss the good old dos days where things were simple and most applications weren’t messing your OS structures and configuration.

    What you get now, is that every dev thinks that it’s cool to write ‘gold’ to registry on every users machine and leave that ‘gold’ behind. Every dev tries to use COM’s to kill flies. And don’t let me start on MSI. I think the fact that VS2005SP1 ~300MB (by Microsoft) cannot be installed with 5GB of free space on HDD and ruins the whole system when out of space tells everything. I really do have ‘warm’ feeling for this technology.

  90. Anonymous says:

    > This isn’t necessarily a problem.  If I have a suite of programs, like Office, one application ought to be able to manage the others (or a server config app separate from the server, whatever).

    That in itself might not be a problem. Having programs able to party all over the registry isn’t the same as having programs configure eachother.

    > Don’t forget, the application is running with the exact same privs as the user himself.  Even if you tried to do some sort of OS enforced rule here, there are going to be all sorts of holes you can poke into it.

    Well, that’s just the way Windows works. Granted, it’ll probably never change because of backwards compatibility, but there are certainly OS’s out there where programs are not run at the privilege of the user.

    > Sure, they write some things out but you can always copy the executible to a new machine and it will still work.  (heck, the things are pretty genius in how they work as it is)

    Now *that* sounds like an idea: Have all the settings embedded into the binary itself :)

  91. Anonymous says:

    System administrators like to be able to modify user settings for a number of reasons.  To prevent a certain class of user from messing with their machine, breaking things, and wasting everybody’s time in fixing it is one.  To prevent certain applications from being installed is another.  To comply with company policy and legal requirements is a third.  And that’s only scratching the surface.  Anyone who questions this has obviously never been an admin and seriously shouldn’t be making statements on it.

    If you’re on a corporate network, your PC and the network resources you access are *NOT* your own private playground.  Corporate networks are all about *SHARED* services.  That’s why there are admins.

    Now, the Registry.  It’s a good thing because it’s a single central place where *ALL* user settings can be stored.  Far better than having to hunt through the filesystem to locate an INI file (especially when doing it remotely), and far easier for roaming profiles as there’s only a single file that needs to be mirrored.

    Surely it’s a no-brainer?

  92. Anonymous says:

    > It’s not the configuring part. It’s the all over the registry part. The program could put its settings in any part of the registry, or create a hundred keys and stick them all under there.

    Not to pick on you personally or anything, just wanted to make sure we understand each other.

    The convention is to install programs under C:Program Files (or wherever "programs" is configured on the particular system), and to put settings in C:Documents and Settings (or wherever that’s configured).  Under there, you can put user settings in the profile directory, and per-machine settings in "All Users" or whatever.

    However, a program can write settings (or anything) anywhere in the file system that it has permission to write to.  I’m sure you’ve seen badly-designed programs that install in a directory off the drive root, or store their config settings in their own directory, the root directory, or even places like C:WINDOWSSYSTEM32.

    Just the same, the convention is to write user-settings under HKCUSoftwareCompany NameApplication Name, and per-machine settings under HKLMSoftwareCompany NameApplication Name.

    Programs that do otherwise are just not following the guidelines.  This is a design flaw of *that program*, and not Windows or the registry.  Things can get equally out of hand using INI files.

  93. Anonymous says:

    [Teach a man to fish… -Raymond]

    …and he will spend all day drunk by the local river.

  94. Anonymous says:

    I just don’t like how the registry is organized….

    A better Idea would have been not to have HKLM, HKLU, …etc.

    Maybe something like having a registry that contains something like this:

    AdobePhotoshopWindowsFiletypes.psdDefaultAction

    AdobePhotoshopWindowsFiletypes.psdIcon

    AdobePhotoshopWindowsApplicationPath

    AdobePhotoshopUsersAllUsers..

    AdobePhotoshopUsersDefaultUser..

    AdobePhotoshopUsersUser1..

    AdobePhotoshopUsersUser2..

    To backup and move Photoshop, move the c:program filesadobephotoshop, as well as the registry starting from AdobePhotoshop…

    To Delete all Photoshop settings, you can delete the tree from there…

  95. Anonymous says:

    It seems to me that you can deal with the problem of administrator overrides with multiple sets of settings:

    1. Default settings

    2. User settings

    3. Locked settings

    Thus if a setting is present as a locked setting then that value is used, otherwise if it is present as a user setting then that value is used. (How default values work is up to the programmer – some applications provide overridable administrative defaults, and fail-safe values in case the administrator gets things wrong.)

    Applications are already capable of implementing this scheme, but apparently only as a separate layer over the registry or some other API. Ironically a native multi-INI API appears to be easier to implement.

    [And yet no program uses this scheme. (And does the user have access to his own locked settings? Sometimes I lock my own settings to prevent other programs from modifying them.) And how is the administrator’s script supposed to find these INI files anyway? They could be anywhere! -Raymond]

    [In 16-bit Windows, three consecutive INI file operations would result in only one parse and one write, because the operating system was co-operatively multi-tasked. When you accessed an INI file, it was parsed into memory and cached. The cache was flushed when you finally yielded CPU to another process.]

    According to Undocumented Windows, INT 21 called Dos3Call which called WriteOutProfiles which called NoHookDosCall. (All those functions are exported by KRNL386.EXE but other than that I’m not claiming any particular accuracy for that statement.)

  96. Anonymous says:

    Well you see I use CCleaner, and I have enabled the option to store all the setting to an INI file rather than the registry. Because I don’t want things like in there, since some programs don’t remove them when they are unistalled.

  97. Anonymous says:

    sherriman wrote: "Users with older machines often have a good portion of the registry corrupted.  This issue was particularly prevelant on WinME."

    Uhm… What is your point? Those users probably had a good portion of their filesystem in complete tatters.

    NT users who used FAT also experienced "interesting" issues. (albeit not nearly as often as Win9x/ME users)

    Let us refer to them as ‘idiots’. NTFS arrived in 1993, lets just all use it, OK?

    <sigh>

    I can’t recall ever having had a corrupted registry with Windows NT (been a user since 3.1 launched). Except one time (seven years ago) when a faulty Epox motherboard corrupted a lot of memory accesses so much of the information stored on disk was garbled. I can’t really blame the design of the registry for that though.

    Rune

  98. Anonymous says:

    Well, I think the registry is certainly one of the best ways to store user settings.

    Granted, it is not perfect, but a lot of its cons are, as many other times, due to the abuse of some programmers who don’t read documentation or simply don’t care.

    Regarding the settings migration, I think it is common knowledge that user settings should end up in HKCU and machine/global settings that  are only to be set up and changed in HKLM.

    Unfortunately, a lot of software writers do not follow this rule and do as they please.

    I regularly work on software deployements and one of the funny aspects of it is to find where the corporate registration key is stored to include it in the unattended software package that we will push to workstations (we don’t want the users to put it by themselves and many times, it doesn’t get asked by the installer or can’t be integrated in the answer file).

    Several softwares try to hide them from the spots were logic people would look for them at first (probably in a naive hope to prevent easy piracy) : I found one rather popular software storing its registration data to HKEY_CLASSES_ROOT under the name LastGoodKnown, specifically chosen to fool the admin into mistaking it was something used by the "Last Good Known Configuration" boot option of the OS.

    I guess these people were those who would have written their important settings to a MORICONSS.DLL file in the Windows directory back in the Win16 days : the registry is just a container and it is up to people to not put trash in it. They would put trash no matter what the container was anyway.

    Setting migrations if the rules are followed can be nice and easy.

    MS provides export and import function (these .REG files really are great, even though they don’t migrate the ACL along due to them being plain text files) and they can be fully scriptable through command-line tools like the REG.EXE tool.

    That said, many people want/need to have portable version of their software (I would have prefered the term "mobile" as portable doesn’t really mean this to me, but I wasn’t really asked).

    Writing the settings into registry, exporting them and then deleting them when the application is closed is kind of dirty… and for those, the cleaner way is probably to use local files.

    I assume it is why people started to use XML, a format that I don’t really like much when it comes to storing user settings because it isn’t scriptable with any standard tool, the file architecture (I don’t mean the format, I mean the hiearchy of the file) is always different from one application to the other, so when you want to change just one setting inside the file properly and securely, you have to write your own program using a XML parser, which understands that particular XML file logic !

    Changing a single setting on the registry is much easier and can be done in a lot of easy ways : Functions from the API, WSH, command-line tools, reg files, etc…

    I think the only real "issue" with the registry is that it doesn’t provide a solution for those "portable software" that many people, including me, like using from time to time.

    I would like if there could be a way to tell them to use a locally stored .REG file rather than the real registry , although I understand it would make all the INI issues come back but at least, the format would be the same and be importable inside the registry again at anytime and the other way around. At least, the logical structure of the data wouldn’t change. Only the format would (reg file or local registry) and they could be easy interchangeable.

    On another matter, Raymond, you answered this to commenter AlmostAlive several posts earlier  :

    "Or if you want to have two sets of rules, then everybody will say, "Well screw the new rules. I’ll just use the old rules. They didn’t try to stop me from replacing file XYZ." -Raymond"

    And it made me wonder of something : in your opinion, what made programmers start using the registry vs the old INI files, especially after the launch of Win95 ?

    I mean, due to backwards compatibility, it wasn’t like they couldn’t have kept using INI files as they used to do so far and most programs didn’t really need increased security to store their user settings, especially back then.

    However, the Registry very quickly became popular (at least, from my perspective), from the small freeware writer up to the big companies. Considering how changing minds can be time consuming (like having users not requiring admin-rights to run some apps), I would be interested to hear your opinion on what made the registry adoption so successful, especially since the previous solution (INI files) was still available for backwards compatibility reasons.

    Thanks,

    JC.

  99. Anonymous says:

    Madman:  I think your perspective on Installers demonstrates a fundamental lack of understanding you believe things should work versus how they do actually work.

    If you took a few minutes to familiarize yourself with Windows Installer, I think you’d find that it can do pretty much whatever you want to do with it.  Windows Installer supports rollbacks in the case of failed installs.  I shouldn’t need to remind you how "wonderful" it is when you’re installing something and it fails halfway through and now you have a broken app.  It doesn’t matter whether it used INI files or Registery or what, that app is pooched.  Happens on *nix machines and Windows machines too.

    Also, back in the "good old dos days" many applications wantonly messed with your system, OS configuration, memeory layout, and even directly stepped on and took over OS functionality to suit their own desires.

  100. Anonymous says:

    OK, which Slashdot article actually links to this page? I was actually reading /. yesterday and the closest thing I saw was “Microsoft building data center in Siberia.”

    [It was pre-emptive. (And it worked. The article didn’t show up on Slashdot.) -Raymond]
  101. Anonymous says:

    "I’m sure you’ve seen badly-designed programs that install in a directory off the drive root, or store their config settings in their own directory, "

    …or badly-designed users that have been using the program since it was a DOS program and insist on this behavior, and complain loudly and persistently when we try to follow Windows norms such as installing in Program Files and putting data files in My Documents or Application Data… welcome to my world.

  102. Anonymous says:

    [The administrator can control what the employees run on the computer. That’s why it’s called the administrator. I think that’s the fundamental disagreement. This INI vs registry thing is just a cover. -Raymond]

    Exactly: The function of the registry is to exchange the roles of User and Tool.

  103. Anonymous says:

    The big thing as a administrator of both Un*x and windows systems that I miss wiht the registry is being able

    to add comments to a config file referring to the change a, who made it and the helpdesk ticket which made the change required.

    I can add these as a comment to the files themselves on Un*x or even add the files as a whole to a SCM system so all the chanegs are dynamically tracked.

    AT the system level the is really powerful – most unix apps don’t write back to their system config (in /etc) they do have write back to the system state (in /var) so the locking issue which Raymond rightly points out is moot here. And the trackability and undoability which you just cant easily get with he registry (How many system restore points would you need? And how do you comment them) is invaluble.

  104. Anonymous says:

    “XML configuration files are read-only”

    Strange statement. I suppose this is true if you use only provided framework code. After all, if Microsoft didn’t write it and include it in the framework, it can’t possibly be done.

    I’m so tired of that attitude from all the new plug the pieces together programmers.

    [You need to read that quoted sentence in context. I may have to bring back the nitpicker’s corner; people are getting nitpicky again. -Raymond]
  105. Anonymous says:

    @JamesNT: “The Windows Registry has only had two real problems”

    I *do* think the migration problems are real. If I want to back up my program settings and reinstall, I know how to do that on Unix for the most part. Backing up /home/evan does most of the trick, and backing up /etc does pretty much all of the rest.

    After reinstallation, or migration to a different system, restoring is comparatively easy. Restoring user-specific settings is just a matter of restoring /home/evan. Restoring /etc settings is a bit more problematic, because you may have to merge changes, but this too can be done.

    Contrast this against the registry. What do I need to back up? HKCU/Software and HKLM/Software? Will that get too much? Not enough? Is it safe? If something breaks after I do that, what do I need to change to fix it? On Unix, I could just delete my old config files for the program that doesn’t work. Sure I lose the settings, but everything else works.

    As a desktop user, this is the major issue I have with the registry. Many of the benefits of the registry (e.g. fine-grained permission controls) more or less vanish in this environment, so I’m not a big fan.

    [HKCU backs up your user, HKLM backs up your system. Restoring it is a big more problematic, because you have to merge changes, but this too can be done. -Raymond]
  106. Anonymous says:

    I thought there was a big agreement in this issue. Now I see I was wrong.

    My big reason comes from the slogan of a company i worked for: ‘don’t put all the eggs in the same basket’

    Anytime I read an article to change some settings in the registry I see a legend saying ‘do it at your own risk’.

  107. Anonymous says:

    [And yet no program uses this scheme. (And does the user have access to his own locked settings? Sometimes I lock my own settings to prevent other programs from modifying them.) And how is the administrator’s script supposed to find these INI files anyway? They could be anywhere! -Raymond]

    Opera on Linux (and possibly other *nixes) does this. It has 2 configuration files in /etc, one is the default (which can be overriden by user), and one that overrides user’s settings.

    [That’s two out of three (or four, if you also want to count user-locked settings, or more if you want to admit multiple administrators, like say a group administrator and a network administrator). -Raymond]
  108. Anonymous says:

    I do find it funny that Linux configuration managemenet is held up as an example of goodness, because its pretty hard to work with.

    one problem linux has is that the main installer frameworks: RPM and DEB only act (declaratively)on the granularity of a file. So the RPM DB remembers the MD5 sum of every file, and who it belongs to, which is great for files that are never changed (you mark them as conf files in the .spec). When you uninstall files,. changed conf files are retained. When you upgrade RPMs, the manager compares MD5 checksums and if they havent changed (or if they have changed to that of the upgraded file) , it does the upgrade (which may change permissions)

    Where this all falls down is if a file needs to be changed. Want to add a new device to /etc/X11/xorg.conf? Manually insert it then patch the RPM database afterwards to pretend its always been that way. Want to add a new user? Try using the commands built in to some distros, fall back to patching /etc/password and the shadow accounts if not.

    No, linux should not be held up as an ideal, merely a best in class. Where linux works is that you can always bring up the system in text mode and edit xorg.conf with vi until it works -indeed vi has a special xorg.conf mode, that is such a common use case.

    Modern thinking is tools like puppet and SmartFrog that don’t just change a file, they change the state of machine and keep checking to make sure that change is there. So you don’t apply a one off operation to a file, you declare what changes you want to be made to the system, the runtime remembers it (possibly in its own db) and then pushes the system into that state. Where these tools work is they can keep thousands of boxes in the required state -you just have a runtime on each one.

    That is the future. things like transacted filesystems and declarative formats for installation files help. RPM and DEB are half way houses.

  109. Igor Levicki says:

    >And what if you want to secure one of the per-user settings but not another?

    Do you mean a password? If each user had its own INI file in his folder hierarchy which can’t be accessed by other users save administrator all of his per-user settings would be secured which surely wouldn’t hurt, or would it?

    [I mean I want to lock some per-user settings so other programs (which run as me) can’t modify them. -Raymond]

    >Are you saying that one should never run two copies of the same program at the same time?

    Yes if they can have MDI interface.

    No if they are Calc.exe — in that case “Settings cannot be changed while you have multiple instances of Calc.exe open” dialog box would suffice.

    [I can’t tell if you’re being serious or not. -Raymond]

    >Now you’re being disingenuous

    No, I am just applying your own security reasoning to the problem at hand.

    >I like how in one branch of the comments…

    I know. But if something is standardized it automatically means it is not voluntarily. That is what standards are for — to make people comply to them. I never heard anyone complain about standardizing food labeling for example. If you don’t want to deal with substandard products when it comes to food, I don’t see why you would want to tolerate substandard software?

  110. Dean Harding says:

    "I don’t see why you would want to tolerate substandard software?"

    You’ve obviously never bought Windows from an OEM.

  111. Anonymous says:

    [I know. But if something is _standardized_ it automatically means it is _not_ voluntarily. That is what standards are for — to make people comply to them. I never heard anyone complain about standardizing food labeling for example. If you don’t want to deal with substandard products when it comes to food, I don’t see why you would want to tolerate substandard software?]

    Oh, come on, now you’re being ridiculous.

    The ONLY reason companies adhere to standards like food labels is because it is a MANDATORY standard, not a RECOMENDED one. If a company refuses the governmental agency that issued the standard (the FDA for example) will impose fines, restrictions, and whatever other pain and suffering it can come up with to force the rouge company into line.

    When Moron Software Inc decides to update SuperFoobar, and in doing so violates all sorts of Windows standards, what is Microsoft going to do?  Call them? Send them an email? Send in a hit squad?  I’ll give you a hint: they will do nothing because Microsoft has no *authority*.  Any standards put forth by Microsoft for Windows development are nothing more than SUGGESTIONS and best practice RECOMMENDATIONS. They carry no weight.

    Given your other comments I don’t think there’s any way you’re serious so I’ll stop now. Shoo troll.

  112. Anonymous says:

    [And yet no program uses this scheme.]

    Well, Netscape 7.2 (for instance) stores preferences in multiple locations; if an optional administrative preference file exists any values it contains take precedence otherwise any values in user.js take precedence at startup otherwise any values in prefs.js are used otherwise any values in the default preference files are used otherwise the preference system returns an error which the calling code often deals with by using a hardcoded default value.

    [And how is the administrator’s script supposed to find these INI files anyway?]

    I’m assuming that the application looks for the administrator’s optional overrides in a well-known location such as Group Policy.

    [I mean I want to lock some per-user settings so other programs (which run as me) can’t modify them. -Raymond]

    I’m sure it was you who pointed out in an earlier entry that programs which run as you can unlock and modify any settings that you (as you) can lock.

    [They can, but in my experience, programs respect the lock, so the trick is effective. -Raymond]
  113. Anonymous says:

    Raymond you mentioned that self documenting config files is enough rope to hang yourself.  And you are correct when are referring to the why. For example "Why would I change this value from x to y" should be given enough info and detail and this should be in documentation.  But where the benefit comes from having the documentation in the config file is when there is finite values for a config option. It’s good to have the enumerated values listed there.  For example in the ASP.NET web.config files sessionstate values.  It’s good if you know I want it to be stored on the SQL server but you can’t remember what the exact synatx needs to be.  Also good to know min and max values and so on.  But you’re right documentation should be in the documentation, but having some help handy is really nice.  

  114. Anonymous says:

    One other problem with INI files (or config files in general) is that they don’t play nice with Group Policy.  You could always write a login script to dump loads of text files on a PC, but that inelegant and it doesn’t work with periodic background GP refresh.

    I’m of the opinion that if a company is serious about having their software used on a corporate network, then they should (a) provide an MSI for installation, (b) provide a customisation tool for that MSI so that an admin can select which components users get, and (c) provide an ADM file so that settings can be centrally set.

    But that’s wandering a bit off topic.  The ADM file is the relevant part here.  Group Policy will use that to write app settings to the registry, and hence save the poor beleaguered admin from having to go around thousands (or tens of thousands) of PCs every time a trivial setting change is required.

    And you don’t get that with config files.

  115. Anonymous says:

    I think people are just being harsh about it because they don’t like the concept of a binary file. However, binary files are indeed faster. Although I think I may have to defrag the registry every now and then.

    It sucks when people spam the registry, agreed. And it can be hell to manually install a program (which I have had to do in the past). But one of the only alternatives to match it would be to use the file system and folders (which would be slower; I’ve programmed a(n incomplete) FAT driver before)

    Right now, I’m having a look into the (Windows 95) registry to see what’s there. Although I opened it up in EDIT.COM as a binary file and found this…

    (garbage)*The Microsoft Windows 95 Product Team!.{869DADA0-42A0-1069-A2E7-08002B30309D}*THEMIC~1.{86*(garbage)

    (* = null character)

    Yes, I activated that easter-egg. But I think that’s a bit off-topic.

  116. Anonymous says:

    An app’s registry settings are not easily portable and are hard to edit. XML is hard to edit too. For this reason I will use INI files in nearly all of my apps, along with XML and reg settings.

    I use INI files for config settings read-in when the app starts. A user can easily change  an INI file in notepad to reset a default path, a scale factor, or something trivial. If there wasn’t GetPrivateProfileString() I’d write it myself (and I have).

  117. Anonymous says:

    “What if a program modifies your .emacsrc (to add a handler for its private file type) and your fvwm2rc (to add a context menu for the file type) and your .cshrc (to add itself to your path)? Now its settings are stored in eight lines in three separate files. Good luck migrating that. -Raymond”

    Let me stay a bit off topic to explain it.

    1) While installing a program should not write anything to user home directory. (Note. while installing, the program has no clue where the user home directory is)

    Instead it should add something to the system-wide settings stored in /etc. Then user will have them automatically (application settings I mean, not the aliases in .*rc files).

    1a) After the first launch by the user the program should ask if it should modify his settings (namely .emacsrc and .fvwm2rc). Also it may create directory for keeping the override of the global settings (say ~/.program_name).

    2) Instead of writing the path it should place its binary in say /usr/local/bin

    3) lets suppose that happens and some ugly designed program did that. Now how would I migrate the user to other system? Exactly the same way I would do it in any other case:

    cp -r /home/user /mnt/other_system/home/

    That’s it, now I have the same settings at the other system.

    Nitpicker’s corner: no I was not speaking about the corporate install with some locked settings.

    [Copying the user profile also copies the registry, so it’s all a wash. (I find it interesting that the unix way is to install all programs into the same directory. Imagine if Windows did that…) -Raymond]
  118. Anonymous says:

    GAC = Registry2

    gac is currently not a generic storage area (which registry has become), but gac is atleast equivalent to the classes_root part of registry, which was the original intent of registry and the only part that existed i 16-bit windows.

  119. Anonymous says:

    [Copying the user profile also copies the registry, so it’s all a wash. (I find it interesting that the unix way is to install all programs into the same directory. Imagine if Windows did that…) -Raymond]

    That would indeed be a dumb way to do it for most programs on Windows. (I don’t like it on Unix either; more on that in a sec.) But the DOS/Windows way completely falls down in Unix, because it’s way more heavily command-line based.

    Imagine if %PATH% variable had 200 directories in it because it needed to say C:Program FilesGrep;C:Program FilesFind;C:Program FilesLess;C:Program FilesLs;C:Program FilesRm;C:Program FilesMv etc.

    (I’m exaggerating there, because probably all of the above would be more like c:Program Filescoreutils or something, but my point stands. Since way more stuff is CLI-based, you would need to have way more stuff in your path.)

    Personally, I think the best approach is somewhat of a hybrid. Programs should install into an isolated directory, as they do in Windows, but then put a symbolic link in a common location (/usr/bin on Linux), or otherwise "register" themselves so they are available on the command line.

  120. Anonymous says:

    Are you are proposing a registry for unix? ;)

  121. Anonymous says:

    Bryan:[Madman:  I think your perspective on Installers demonstrates a fundamental lack of understanding you believe things should work versus how they do actually work.

    If you took a few minutes to familiarize yourself with Windows Installer, I think you’d find that it can do pretty much whatever you want to do with it.  Windows Installer supports rollbacks in the case of failed installs.  I shouldn’t need to remind you how “wonderful” it is when you’re installing something and it fails halfway through and now you have a broken app.  It doesn’t matter whether it used INI files or Registery or what, that app is pooched.  Happens on *nix machines and Windows machines too.

    Also, back in the “good old dos days” many applications wantonly messed with your system, OS configuration, memeory layout, and even directly stepped on and took over OS functionality to suit their own desires.]

    Last time I did VS update, windows installer ruined the whole system, yea, not VS, but system. Including frameworks, redists and who knows what else. Rollback just got stuck for 5 hours, and progress bar didn’t even moved.

    In xcopy world, you can just copy the darn thing over if something fails. And that takes 2 minutes for 4GB or so. Try and beat that!

    [Xcopy is a great world if your program fits the model. Not all programs can. -Raymond]
  122. Anonymous says:

    [Xcopy is a great world if your program fits the model. Not all programs can. -Raymond]

    That’s true, unfortunately trend to make thing simple seems to diminish, or so it seems.

  123. Anonymous says:

    Madman:  Again, you fail to have any conception of how complicated that VS installation is.

    Don’t you think if they could have a self-extracting zip file that installed everything to the folder you wanted, they would?  The XCopy world left us a long time ago.  That’s why there’s a blog called "When Setup Isn’t just XCopy".

    Not even Linux runs on an XCopy world anymore.  That’s why the top distros all have centralized or distributed package management systems as their focal feature.

  124. Igor Levicki says:

    >I mean I want to lock some per-user settings so other programs (which run as me) can’t modify them.

    Ah you meant global settings, right?

    Because the way I see it Word should not change Excel’s INI files.

    You actually meant say Explorer or Windows INI settings which various “tweak” and “optimization” utilities like to fiddle with without asking the user?

    There must be a solution for that. Let me think…

    Aha, you could do something like this:

    sometype AppLockKey = CreateAppSpecificGlobalSettingsLockKey(); // this creates a key specific for your app

    SetPrivateProfileInt(“DontCacheThumbnails”, 0);

    LockPrivateProfileInt(“DontCacheThumbnails”, AppLockKey);

    Now only the program which passes correct key (the one who locked it) can change DontCacheThumbnails entry.

    To unlock:

    sometype AppLockKey = GetAppSpecificGlobalSettingsLockKey(); // this retrieves your app key created above

    UnLockPrivateProfileInt(“DontCacheThumbnails”, AppLockKey);

    SetPrivateProfileInt(“DontCacheThumbnails”, 1);

    Easy, right?

    [Woo-hoo, you’re reinventing the registry just with a different backing store. -Raymond]
  125. CmraLvr2 says:

    Amusing.  I particularly liked the "If MS had done X like they should have, then Y wouldn’t be a problem" stance.

  126. Anonymous says:

    Mike Fitzpatrick wrote:

    "An app’s registry settings are not easily portable and are hard to edit. XML is hard to edit too. For this reason I will use INI files in nearly all of my apps, along with XML and reg settings.

    I use INI files for config settings read-in when the app starts. A user can easily change  an INI file in notepad to reset a default path, a scale factor, or something trivial. If there wasn’t GetPrivateProfileString() I’d write it myself (and I have)."

    Thats for the heads-up.  Must make a mental note to never buy any of your apps for my network.

  127. Anonymous says:

    Personally, I think the best approach is somewhat of a hybrid. Programs should install into an isolated directory, as they do in Windows, but then put a symbolic link in a common location (/usr/bin on Linux), or otherwise "register" themselves so they are available on the command line.

    This is what some distros do with binary-only programs – they each get installed to /opt/program_name, then the symlinks (and in a few cases startup scripts) are placed in /opt/bin.

    Speaking of Windows Installer, fixing the problems it causes brings in a nice chunk of my income. It’s not just the VS installer, I’ve seen a ton of other problems, and most of the errors it gives out are pretty criptic (or it doesn’t show an error at all, but just rolls back). The idea is nice, but the implementation is severely lacking.

  128. Anonymous says:

    After the first few nostalgic "i like inis better" i came to prefer the registry.

    I think a lot of problems stem from the fact that programmers need to manually access the registry to install extension types and similar.

    There should be an API which will hide the registry accesses. I’m talking about things like registering a file extension. The developer has to look up the how-to in the MSDN (or worse, discover by trial and error). If there was a nice function like RegisterFileType which does all the dirty work a lot of registry errors might be prevented.

    It still does not force developers to use it though…

  129. Anonymous says:

    Surely all the problems you list for ini files are there because it got deprecated, and no-one at MS was allowed to fix any bugs are add features to it since Windows 3.1. I mean the 32K size limit would probably get fixed just by recompiling the library with a 32-bit C compiler rather than a 16-bit C compiler.

  130. Anonymous says:

    Múltkor írtam a registry matatásról , most ugyanonnan véve – több mint – ihletet, feltenném a kérdést

  131. Anonymous says:

    Múltkor írtam a registry matatásról , most ugyanonnan véve – több mint – ihletet, feltenném a kérdést

  132. Anonymous says:

    Quickie: Why did Windows ditch .ini files for the Registry

  133. Anonymous says:

    I&#39;m back from holiday with over 1000 feeds to read. I also got my new gigabit router today. Heard

Comments are closed.