My recent reinstall reacquainted me with the delightfully varied places in which Windows programs keep their configuration settings.
In the olden days, you knew where the config files were. Old DOS programs didn't necessarily have config info; you just gave 'em parameters on the command line, as the Great Beards intended.
When there were enough persistent settings to require separate configuration storage, you'd just have a text file called progname.cfg or something in the program directory. Easy.
Some programs still do this, even today. Blessed be the name of those programs, for you can often just run 'em from their directory and have everything work, whether or not you've ever run an installer for that program on your current Windows install.
But there are so many other places where Windows programs, in this modern age, may keep settings.
Some of them make their own directory in Documents and Settings\username\Local Settings\Application Data\, for instance.
Others use Documents and Settings\username\Application Data, just to keep you on your toes.
(Documents and Settings\username\Local Settings\Application Data also contains the XP IconCache.db file, deleting which can cure some weird icon problems. Or at least change them.)
And some programs, of course, tuck their settings away in the registry. Typically in some branch that'll have a different name when you reinstall, so you're thwarted even if you get all clever and "Export" that branch from regedit.
(I was quite proud of myself when I successfully edited the exported .reg file to put the settings for that one awkward program in the new long-nonsense-named registry branch.)
Some programs even decide to strike a blow for individualism by putting config files in the parched wasteland of My Documents. Cunning!
(Yes, I am aware that Mac OS X has one place where all of this stuff Must Be Kept, and Often Is. I agree unreservedly that just switching to a lovely trouble-free Mac would make settings transfer a great deal easier, by relieving me of many of the programs whose settings I would otherwise have to transfer, not to mention a substantial amount of the employment that so tiresomely requires me to use said applications.)
The whole installation-transfer adventure did have some bright patches. Some applications that look as if they ought to be a mass of horrible encrypted untransferable setting info actually aren't at all. Valve's "Steam" game download system, for instance, can trivially easily be ported from one Windows installation to another. Just install Steam on the new computer, then copy the (huge) steamapps folder from your old install to the new one. Done.
I even successfully exported and then re-imported the security certificates for the Australian-Government-issue Goods and Services Tax software, which isn't as legendarily bad as you might think but still doesn't inspire confidence that such a feat will actually be possible.
Oh - I'm also sure I'm not the first to be annoyed by all of the software companies who insist on making their install directory not Program Files\ThisProgram, but Program Files\CompuGlobalHyperMegaNet\ThisProgram, apparently because they assume you're going to be so impressed with ThisProgram that you'll buy a whole suite of other Compu-Global-Hyper-Mega-Net software, which must be kept in one directory for, um, neatness. Or something.
Later on, if you're trying to find the ThisProgram install directory (or even its entry on the Start menu, which will of course also be a company-named subdirectory), your eye will slide right over the CompuGlobalHyperMegaNet directory, because nobody outside CompuGlobalHyperMegaNet has any idea what the company is called.
The most outstanding example I've seen of this approach is from one Juan M. Aguirregabiria, whose programs, that's right, want to install themselves in Program Files\Juan M. Aguirregabiria\...
(And then the program of his that I tried had some DLL error or other and didn't even freakin' run.)
18 August 2007 at 6:53 pm
There are standards for where well behaved windows programs are supposed to put things, set out by Microsoft. ISTR some of them include Company Name and others do not. It's been long enough since I was a Writer of Horrible Setup Programs that I don't recall the details (and they have changed anyway) but complying with them was required to obtain various spiffy Microsoft logos (which marketing insisted were Very Important). The irony of course was that Microsoft's own products rarely followed said standards, leading some of the more cynical folks to suggest that the whole Microsoft logo process was merely a means of inconveniencing their competitors.
I do however applaud Microsft from moving away from Extremely Verbose Directory Structures With Lots of Spaces in vista.
18 August 2007 at 7:26 pm
Be glad you don't still have a lot of software that was written for non-NT-derived versions of Windows. A lot of Windows 95 software insists on keeping settings in C:\Windows or various and sundry subdirectories thereof. Which, incidentally, creates interesting and fun problems when you want to run it from a Limited account.
The situation on Unix systems is simultaneously better and worse. On the one hand it's better, because config data is pretty much universally stored in two places: in /etc and in "hidden" files and directories (whose names start with a period) in the users' home directories. That's been the convention since the sixties, so all the software written in the last forty years is aware of it. Thus when backing up data from the old system you can grab /etc and /home (oh, yeah, and /var, and /usr/local/etc, and /opt/etc, and so forth) and expect you got most of what you needed.
On the other hand, the situation on Unix is worse because within the bounds of those conventions the config data is a real serious organizational mess. I don't mean file formats -- apps on every platform have weird file formats for their config data, that's not what I'm talking about. (Indeed, Windows apps sometimes have binary (non-text-editable) config files, which is just plain wrong.) No, I mean where things are put *within* /etc, and what the dotfiles (or dotdirectories more often these days) are called. Company-named directories are tame compared to things like what the application used to be called. Not to mention figuring out whether any given app was installed in /usr/local or /opt or straight into the main system directories -- which for any given app may vary depending on the distribution, the version of the distribution, or the whim of the former system administrator. Oh, yes, and don't forget the start/stop scripts in /etc/rc*/ and/or /etc/init.d/ or possibly /usr/local/etc/rc*/ and/or /usr/local/etc/init.d/ ... You generally don't have to copy those when you migrate to a new system (because the act of installing the software normally creates them), but on the other hand you do have to use them in day-to-day operation every time you want to start or stop a service.
21 August 2007 at 9:34 am
Things get better for applications developed on the .Net 2.0 framework or later. Applications written using the My.Settings API store their settings in an XML formatted file called something like applicationname.exe.config. Even better, this config file is once more stored in the same folder as the application itself.
22 August 2007 at 12:00 am
What's the password?
"Ken Sent Me"
Lemme get at that hooker!
22 August 2007 at 12:02 am
Well, ignore me. Stupid blog login-before-you-comment thing made me miss the copy and paste the rest of my comment about my other favorite Ken.
I'll go hide now.
23 August 2007 at 8:27 pm
There's a nice program out by Altiris called "SVS" (Software Virtualization Solution). There's a free version available on their webpage for home use:
http://juice.altiris.com/node/86
Basically it runs applications inside a virtualized windows environment on your machine - anything the program does to your system, registry writes, filesystem changes, etc. is "virtualized" into a file. To uninstall the application, and everything the application has done to your system, you just delete the virtualized container.
The developers note that there are ways for programs to intentionally break out of the virtualized system, so it's not ideal for testing programs that might contain viruses, or with programs that are heavily copy protected, but it works nicely for evaluating normal software that you're not sure if you want to keep in the longrun without polluting your system.
I think an upcoming release is fully virtualized so programs can't escape (much like a VirtualPC/VMS system).
It's a bit wierd to set up for the first time, but the essence is that you fire up the SVS control panel, create a new application, then from within SVS, run the installer for your application and it installs into the virtual machine.
Pretty handy!
24 August 2007 at 6:55 am
Rask: .Net 2.0 is better, provided you use something with a real installer. The publishing methods in the express versions is so crippled that it's impossible to have a normal shortcut that you can click on, and also use the program with command line arguments. The only way to handle that is "XCOPY" installations, which is "The Bad Old Way." :(
Not to mention that published apps can't be installed for all users, current only.
9 January 2008 at 2:01 pm
Jeff Atwood just put up a post peripherally relevant to this issue:
Don't Pollute User Space