Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Donate
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ The Windows registry vs. INI files

I've been asked a few times over the years why I use the Windows registry to store settings instead of INI files. The main answer is that it's a cleaner and easier to use interface for storing settings. The registry certainly has its faults, but it has a number of advantages as well:

IMO, the last one is the biggest advantage. One of the problems with using INI files is that you have conflicts on the INI file if multiple instances of the same program are run from the same location; this is made more difficult by inability to queue conflicting file opens or atomically commit partial updates into the file. Using the registry means that you can exchange data between multiple running instances. For instance, if a dialog commits last used values, the same dialog in another instance can pick up the same values as the defaults. I'm slowly moving toward trying to have more data stored and retrieved "just-in-time" in this manner; it reduces the cases where settings unexpectedly revert, either because the program died before it could save settings on exit, or one instance exited and committed all of its settings regardless of which ones changed.

As for arguments against the registry, one is that it stores settings in one big binary blob in the user profile that's hard to manage and backup. That's definitely true, and it's unfortunate that Microsoft didn't provide a good way to isolate a branch of the registry in a separate file. You can use RegLoadKey() to do this to some extent, but it's unfortunately a global operation instead of a process-local operation and requires backup/restore privileges. The second is that you can manually tweak an INI file in a text editor. I'm not sure I buy that argument as much, as it's difficult to programmatically commit settings back to an INI file in a way that keeps them readable, particularly if you're persisting data structures. It's a bit like XML used as a serialization format -- I wouldn't call it human readable so much as human parseable.

There is one more argument against the registry and for INI files: portable operation. This is where settings are stored in a file next to the executable so both can be moved together. This does hold plenty of water, I have to admit. As a test, I added some experimental code into an Altirra test release that allows registry operations to be shunted to a virtual registry, which is then loaded from and stored to an INI file. The INI file looks a bit funny, but the advantage of doing it this way is that the program can run both in registry and in portable INI file mode. This seems to be working out pretty well, so I'm planning on back-porting that code to VirtualDub.

Comments

Comments posted:


That's what I did in Zoom Player, but as an added bonus, I made it possible to specify the config file by command line, making it very easy to have multiple separate configuration profiles that don't interfere with each other (I also made it that if the config file is specified in command line then all data was saved in a separate registry tree, exported and then erased on exit)

Blight (link) - 04 07 10 - 10:01


I think, portable settings are best thought of as documents and handled similarly. Applications that want to handle settings portably often have additional options to save and open their databases.

Alexey - 04 07 10 - 13:02


Keeping the settings in a .ini also helps to reduce windows rot/registry bloat.

asf - 05 07 10 - 04:08


Registry rot/bloat hasn't been a problem since Win9x ceased to (practically) exist...

KaarlisK - 05 07 10 - 05:55


@KaarlisK are you crazy? First off, the registry is a memory mapped file or kernel paged pool (depending on windows version) so its size is going to have some sort of impact. Go take a look @ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components etc and tell me that is not bloat that really should be stored in a external file?

asf - 05 07 10 - 06:10


If you're going to take that stance, then by that argument nothing should go in the registry. Memory-mapping a 9MB file is not such a big deal, especially with many of the pages aren't touched. I have to side with KaarlisK on this one -- registry bloat hasn't been nearly as much of a problem as it was in the Win9x days, where the kernel had issues reclaiming space from deleted entries. Remember that if programs don't use the Registry they have to roll their own solution for concurrent, stable storage, and that introduces another form of bloat. Would you want Windows Installer to create a file per entry instead? That's what the Internet Explorer guys did for bookmarks....

Phaeron - 05 07 10 - 07:13


Well, yes, I'd rather they stuff that stuff as files in %windir%\installer\components or whatever, but since MSI is a database they already have some sort of database api and should use that and not single files (How often do you install/uninstall stuff?)

Vista+ has RegLoad/Save apis that non admins can use, but yes, windows really needs a config api that is just a mini registry in a file thingie

asf - 05 07 10 - 07:56


What about the defragment implications of always changing a 9Mb (says who?) file, even if the change is just one letter? IE's approach is why the Favorites are portable as well as editable externally.

lwc - 05 07 10 - 10:47


I'm not sure what you mean by defragmentation implications. Rewriting a file in place doesn't involve any disk space allocation and is ideal; extending a file has defrag implications, but it's no worse than creating new files. Generating lots of little files is AWFUL if you need to scan them -- it can take minutes to read all of the files. It does have the advantage of allowing the shell to manipulate the entries, though.

The 9MB figure is just the size of the SYSTEM.DAT hive on my computer.

Phaeron - 05 07 10 - 12:12


I'm sure mapping 100+ MB of registry bloat in Vista/7 surely does impact performance, especially on 32-bit systems. Running compcln.exe on Vista SP2, for example, improves system performance noticeably. I hope Win7 won't have such problems after several years, since registry APIs were improved there afaik.

Tihiy - 05 07 10 - 20:13


I wish you chose the INI model for being "Ghost" application (Portable).

Drazick - 06 07 10 - 21:16


There's one more advantage to registry - if I want to reset just one setting every time I start VirtualDub (Shutdown after jobs finish) I can do it using simple registry file instead of doing search/replace in an ini file which is not really supported by windows tools.
So I hope either this setting gets fixed or running VD without the ini file will still be an option in the future.

Kasuha - 08 07 10 - 22:06


I cannot count the amount of times I've had to load registry hives from old operating system installs just to transfer my program settings. Programs that use the registry to store settings are nothing but a hassle to me. I use portable programs any chance I get to avoid future complications.

In an ideal world, I would have all programs give the option of choosing the Registry or INI files to save settings, not force it upon the user.

DAOWAce (link) - 10 07 10 - 04:48


Why dont you use sql for data storing? LiteSQL perhabs? I would not use INI but SQL anytime.

Jeroi - 01 09 10 - 00:50


And tbh, aplication data folder these days serves as userprofile files. You can store setting file for each user in appdata folder or use main setting file on every user folder. This way works firefox and the rest main opensource programs. By default you check if no userfile on user folder then you generate default settings for that user. Then user defines his own settings. There is no need for windows registry anymore as appdata+SQL makes perfect pair.

Jeroi - 01 09 10 - 00:57


Hi, this is slightly O/T but one thing about VirtualDub that I find very annoying is we cant save capture settings into a config file the same way we can save render settings into a .vcf file. I use virtualdub to capture from various sources and I use settings specific to each source. i.e. my settings for an easycap are not the same as capture from desktop capture, also my eascap settings for xbox are no the same as my easycap settings for PS1 etc.

My current workaround is to write the capture settings I want to use into the registry and then launch the virtualdub executable, but it would be nice if we could have a command line to load capture settings from say a .vcs (VirtualDub capture settings) file.

Mark - 02 09 10 - 01:59


Registry settings can be dumped into *.reg file using something like "regedit /ea filename.reg HKEY_CURRENT_USER\Software\MySoftware\MySettings" and then restored back just by "executing" reg file. This helps backing up settings in some applications.

Vlad - 12 09 10 - 19:20


Vlad, or using regedit gui, browsing to HKEY_CURRENT_USER\Software\MySoftware\ and clicking on export selected branch.

brontosaurusrex - 30 12 10 - 00:45

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.