Windows directories: this is a land of confusion... let's try to make this a place worth installing in

January 10, 2012 12:04 PM

I have questions about how to use the new directory structures we now have under Windows 7 and Vista.

Five main questions:

1. What are the pitfalls of just making up my own directory under c:\, such as c:\mysoftware\ and reading/writing stuff from there? Both from the perspective of a software installer creating and using that folder, and from an end user who creates and uses it. What problems might this cause on a multiple-user machine? I do it this way for tons of little command-line utilities and shareware tools I like to use, and never seem to have a problem with it.

2. A few software programs I have put all their data in a folder at \Users\[user]\ instead of under \Users\[user]\AppData\Local or Roaming. Is this bad form? For instance, my Kindle Viewer puts data in \Users\[user]\.kindle.

3. Some programs in those Local and Roaming directories start with a dot (for example, .minecraft and .ffmpeg), while others don't use this (Adobe, TightVNC, etc). Is one way correct, and not the other way?

4. Do applications have to be installed and executed out of the Program Files hierarchy, or is there leeway for executables in other directories elsewhere? Unless I'm rusty on this, Program Files requires privilege escalation, and I've always heard users shouldn't need Administrator privileges to be running their computers (maybe an exception with software installs is implied?)

5. I'd like a crash course on good practices for where installer programs should be placing their content on W7/Vista systems. A good, succinct reference somewhere is fine... this seems to be hard for me to Google without finding a ton of MCSE and sysadmin type material.

Many thanks in advance!

posted by crapmatic to computers & internet (3 answers total)

So, these answers won't be perfect, but hopefully it'll give a good start for other people to build on.

1. The pitfalls are Windows Search, and permissions / staying within the design of the filesystem. If you are the user and are just dropping the files there, there isn't a huge downside, except that typing the program name in the search box is unlikely to return useful results. If you are creating an installer to distribute out, and putting software there, it is fundamentally against the design of the Windows filesystem.

The design of the Windows filesystem (at least as of Vista and 7) is that executables go in %ProgramFiles% (Usually C:\Program Files), user-specific data and settings should go in %UserProfile% (Usually C:\Users\{username}\), and non-user specific data should go in %AllUsersProfile% (Usually C:\Users\All Users\). That said, there are many software packages that don't follow this paradigm correctly. Those programs that say they need to run as administrator, or need escalation, are often written incorrectly (Exceptions do exist).

2. Best practice is to put it under AppData. There's an environment variable for it that they're supposed to use (%APPDATA%). Same as I mentioned in the point above, though, many packages don't do this correctly.

3. This is a holdover from UNIX filesystems. You often see it with open source, or cross platform. In UNIX, starting a filename with a dot hides it, unless the user looks for it specifically or asks the directory listing to show hidden files. Windows does not hide files that start with a dot.

4. Programs do not HAVE to be installed in %ProgramFiles%, but again, it's the right way. The convention that I've been taught is to put programs in "C:\Program Files\{Company Name}\{Software Package Name}\" If you're dealing with only your local computer, there's not a huge downside to putting them elsewhere. If you are writing software to distribute, you should follow the conventions under #1. You are right about the escalation and administrator privileges - escalation is typically called for when a program tries to WRITE to a location outside %UserProfile% (C:\Users\{current user name}) or %AllUsersProfile% (C:\Users\All Users), or read restricted system data, or another user's data.

5. I can't really point to a reference document that I have on hand, I remember I once googled WAY down into this (and it was tough to find), and I'm drawing on that, plus a bit of training and experience to answer these for you.
posted by frwagon at 12:20 PM on January 10, 2012

Of course, I type all that out, preview, check it, and then have a final idea after I hit submit. The stuff I typed in percent signs is valid system variables on most systems. If you hit run, and then type %UserProfile%, it will open a folder to your profile. Same with the others, and their targets, if you want to see where those variables go on your system.
posted by frwagon at 12:22 PM on January 10, 2012

Instead of environment variables you should probably use the known folder API (pass CSIDL_PROGRAM_FILES in to SHGetFolderPath)

MSDN has a list of all these places. They're not all available on all versions of Windows. The stuff that says version 6 is vista and up.

The idea is that administrators should install your program to CSIDL_PROGRAM_FILES (which can be set to a drive other than C! maybe there is no C drive or it's full! installers shouldn't just use the system setting). After that nobody writes to the installation, thus protecting them from being tampered with by malicious non-Administrator programs. Because you can't write to Program Files anymore, you can't keep your settings there - plus you have multiple users anyway, so that's another reason. Write settings to CSIDL_APPDATA or CSIDL_LOCAL_APPDATA. Write system-wide settings to CSIDL_COMMON_APPDATA.

This has the additional benefit of keeping customization data separate from software installations, which makes it easier to make and maintain good backups, or migrate to another computer or whatever.
posted by aubilenon at 12:35 PM on January 10, 2012