This article is part of Bad Things Programmers Do, a laundry list of common mistakes that catch even the best developers.
One of the most annoying things I’ve come across while developing Project Nelson is the dreadful support for App Paths in other applications. Now, for most devs it would probably be only slightly annoying, but it’s especially aggravating for me seeing as Project Nelson is dependant on them being there to work (efficiently).
What are app paths anyway?
Short answer: The term “App Paths” refers to the registry key located at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\App Paths.
Long answer: Since Windows lets people install software where-ever they please (and good-neighbour apps should never assume they know where an app lives), App Paths provides a central lookup for the locations of any given app. Think of it as an application address book.
What’s the big deal?
While most of the big/popular/old programs register their paths, some of the newer/smaller/unpopular apps don’t. I find this happens most among independent developers (for example, IRC clients and RSS readers are dominated by these people) and open source apps or Linux-ports.
But even big, powerful, closed source companies can do this – for example, Safari (yes, the web browser) doesn’t do it, despite the fact that iTunes does. Whisky Tango Foxtrot.
Why should I use App Paths?
Say I wanted to launch Firefox. I could assume that I’d find it at C:\Program Files\Mozilla Firefox\firefox.exe, and for 90% of the English-speaking world that’d be alright. However, then my program would break for:
- People who installed Windows on a drive other than C:.
- People who moved their Program Files directory to a drive other than C:.
- People who installed Firefox in a directory other than the default.
- People who don’t speak English.
Nice going, you just angered an 30-year-old Brazilian who installs his software to a network drive and has his Windows directory on D:\. Pray he’s not a mobster with contacts in your town.
Long story short, if you expect other developers to run your program, you’ve got to tell them where it is first. :D
How do I use App Paths?
Look up the default value in the key HKLM\Software\Microsoft\Windows\App Paths\%filename%, where %filename% represents the filename of the executable (e.g.firefox.exe).
- You should also look up the “Path” value (in the same key) so you know what CurrentDirectory you should run it under; if none exits, simply use the parent directory.
- Some apps (for some odd reason) use HKEY_CURRENT_USER instead of HKLM. It’s best to check both places, just to be sure, but you won’t be missing much by only using HKLM.
- If you're developing an app, never store your app path under HKCU unless you know your app will only be used by one user on each computer or you install in the users’ AppData directory (*cough*Google Chrome*cough*). The reason for this is because you then have to set it for each user (e.g. at first start), and when you uninstall the app, the old references will still linger.
Setting up shop
You should register yourself in App Paths as part of your installation script.
Register the following values under the key HKLM\Software\Microsoft\Windows\App Paths\%filename%:
|(Default)||String value (REG_SZ)||The path to the executable (e.g. “C:\Program Files\Mozilla Firefox\firefox.exe” for firefox.exe|
|Path||String value (REG_SZ)||The CurrentDirectory you want to open the executable under (optional)|
What about Linux/Mac OS X?
- Mac OS X uses fat binaries, so all you need to do is look in /Applications.
- Linux will store the program in either /bin, /sbin, /usr/bin or /usr/sbin (most likely in /usr/bin), so search those directories and you should find it.
Either way, these locations should be in your $PATH, so you shouldn’t have much trouble finding programs, and programs shouldn’t have any trouble finding you.