My recent reinstall reacquainted me with the delightfully varied places in which Windows programs keep their configuration settings.
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.
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.)