Comments on: They seek config here, they seek config there...

by: Daniel Rutter

Wed, 09 Jan 2008 14:01:46 +0000

Jeff Atwood just put up a post peripherally relevant to this issue: Don't Pollute User Space

by: HitScan

Fri, 24 Aug 2007 06:55:23 +0100

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.

by: Nogami

Thu, 23 Aug 2007 20:27:06 +0100

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!

by: emrikol

Wed, 22 Aug 2007 00:02:50 +0100

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.

by: emrikol

Wed, 22 Aug 2007 00:00:03 +0100

What's the password?

"Ken Sent Me"

Lemme get at that hooker!

by: Rask

Tue, 21 Aug 2007 09:34:47 +0100

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.

by: Jonadab

Sat, 18 Aug 2007 19:26:42 +0100

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.

by: reyalp

Sat, 18 Aug 2007 18:53:48 +0100

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.