Monday, August 10, 2009

App Paths? What App Paths?

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%:

Value name Type Value
(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.

Saturday, July 11, 2009

Operating Conventions Part II (How To Fix What Shouldn’t Be Broken)

This is part two of Operating Conventions, which is itself part of Bad Things Programmers Do. You can read Part 1, but you don’t really have to.

Method 1: Just Fix It

Seriously. Redirect your file open dialogs to the proper My Documents (or better yet, remember the last location.) Use Windows Contacts. Use the favourites folder. Do it the right way, and it won’t be a problem anymore.

Method 2: But compatibility!

If you really must, because some program written years ago by a developer you don’t even know is still alive depends on it, then keep a compatibility struct synced to the OS’s APIs. Make it plain that other developers are not to use the old way anymore, as it may disappear off the face of the earth at any time (this is called deprecation.)

Method 3: But my way is better!

If you truly believe your way is better, then its’ still up to you to keep the OS up-to-date. Use proprietary extensions that other programs will ignore. At the very least, do it your way completely, but keep the OS version synced to any changes.

Remember, above all, if you do it right the first time, you don’t have to worry about compatibility later down the road. Your users will be happy, you’ll be happy, and other developers will be happy too.

Next time on Bad Things Programmers Do, we’ll talk about HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths, otherwise known as the bane of my existence (because programs don’t register themselves there.)



Wednesday, January 14, 2009

Operating System Conventions

Operating systems have a way of doing things. They provide APIs for developers to hook into and use, and default locations for users to put stuff into.

For example, most operating systems now provide a Documents folder as a default location to put their stuff in, a Bookmarks or Favourites folder to store website links, and music, picture and video folders for various media types. Vista also provides a common Feeds API, and a common contacts framework.

However, many programs are not updated to support, or worse, completely ignore these conventions. While this is not always a big deal to the developers and power users, it is a big deal when Ma switches from one app to another and can’t find her stuff. (They may not be using your software, but you’ve just completely alienated them from trying it out again, or recommending it to others.)

Non-Deliberate Examples

Operating systems often replace functionality that has traditionally been handled by programs. For example, before Microsoft introduced the My Documents folder in Windows 98, most word processors saved their documents to C:\Documents, C:\My Documents, C:\Docs, or variations thereof. At least by 2002, one (admittedly minor) word processor was still doing this, saving to C:\Documents\<insert program name here> Docs.

The same thing happened with the Downloads folder in Windows Vista – even today, many popular download managers and *ahem* file sharing apps don’t download their files to the Vista Downloads folder.

And, of course, we must not forget how every single game seems intent on putting <Program Name> Saved Games in my Documents folder, rather than App Data where it belongs, or the user’s Saved Games folder in Vista.

(I myself am not immune – File Manager “Nemo”’s fav folders idea was formed before I knew Vista would have a similar feature, and developed before I had a working build of Vista to play with, for example.)

And Then There’s…

Some programs deliberately ignore conventions altogether – whether it’s to create a “walled garden” to keep users in, because it’s out of spite or contempt, or simply because it’s the way they’ve always done it.

Browsers are a rather egregious example – apart from Internet Explorer, the default browser in Windows, none of the major browsers use Windows’ Favourites folder for their favourites/bookmarks, and none of them use each other’s bookmark database (although many use the same system.) This one stands out particularly well, seeing as Windows has had a bookmark folder since Microsoft started shipping an internet browser with Windows - Windows 98 with IE4 in 1998, just over a decade ago. They aren’t even stored in some proprietary format – they use plain text, and Windows even provides an API, just in case you don’t want to do the heavy lifting yourself.

The common Feeds API is another example – Apart from Microsoft’s own Internet Explorer and Windows Live Mail, no other program that has anything remotely to do with RSS/Atom feeds uses it.

A particularly annoying one is how email programs’ contact/address books – heck, anything with some kind of contact system – seems to use their own system of doing things. Although Outlook Express/Windows Live Mail have generally been good with this, even Microsoft Outlook doesn’t use the default OS contacts database of their own operating system. (Windows Live Messenger doesn’t do it either. Hmm…)

Next time, I’ll discuss how to fix these problems without breaking your apps. ‘Till then!