oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Targeting Windows (too) for Your REALbasic Apps
Pages: 1, 2

Best Practices for Windows Applications

What are best practices for Windows software? Well, the best way to see what Microsoft considers a best practice for anything is to go to MSDN online ( and search for "best practices." You'll get plenty of information as you comb through the results of that search. In addition, here's a list of "under the hood" and some common cosmetic things that you might want to keep in mind (in no particular order).

  • Don't take over file type associations for public media without user intervention. For example, don't register your application to handle the .txt extension. On the Mac, there are file extensions, but there are also creator and type codes to help identify which application should open up what file. On Windows, there's only the extension; and only one application may be registered for an extension at a time. So taking over a public media extension is not acceptable unless you ask the user in advance, because you could be hijacking it from another application.

  • Be sure to register private file type extensions with your application. If your application is the only one that can read a particular file type, then you should associate your application with that extension. For example, if you write a piece of software to manipulate data files that only your application can read, then you should pick an extension that is not already being used (check or the MIME extensions on a newer Windows machine) and associate your application with that extension. Try not use an extension that's already being used.

  • Try to stay away from preferences files, and instead use the Registry. Flat-file preferences are a pain in multi-user settings, since you need a place to store each user's preferences file. But the Registry handles this automatically for you by giving you access to a specific location to store data for the current user, also known as the CURRENT_USER hive. If you need to store data for all users of a machine, you can store those preferences in another special registry location called the LOCAL_MACHINE hive.

  • Try to avoid Multiple Document Interface (or MDI) applications as much as possible. Obviously, there are very good reasons to use an MDI interface, such as applications which display multiple related pieces of information in separate windows (like a graphics editor). But if you find yourself wanting one simply so that you can have a global menu bar that all of the windows have access to, then chances are you're using MDI for the wrong reasons. Most Windows users dislike MDI applications because they take up too much screen real estate, they don't work well with multiple monitors, and they can be unsightly. Even if you think a MDI application might make sense, try to redesign your user interface to avoid using one; MDI should only be used as a last resort.

  • Be wary of permissions issues. If your application is meant to be used in a non-administrative way, then develop and test your application on a user account with limited privileges. This ensures that your application will run for all Windows users, regardless of whether they have limited permissions or not. You can always enable (or disable) features based on user privileges at runtime. Try to avoid forcing users to run your application as an admin, if at all possible.

  • Play well with other applications. If you find yourself thinking of different hacks to steal focus or other non-standard ideas, please reconsider. There's almost never a good reason to mess with another application that is running. Aside from it being very difficult to tell whether the other application is running, the code will always be fragile and will most likely be annoying or confusing to the end user.

  • On Windows, the OK button is on the left, and the Cancel button is on the right. This is opposite of the way the Mac does things. In the case of a three-button dialog box (such as the standard OK/Cancel/Apply), the third button always goes on the right (after Cancel). An example of the button ordering can be seen in these print dialogs from both operating systems, as shown below.

    Figure 1

    Figure 2

  • Make sure your menu names and shortcuts are correct. For example, use Exit on Windows, not Quit. Also, most menu items have mnemonic accelerators (the single character that's underlined), as well as specific shortcut keys. Some common ones are listed on the Windows User Experience web page. Be certain to have keyboard mnemonics for every menu item, and always try to use the standard keyboard shortcut and mnemonics whenever possible. Watch out for conflicting mnemonics and keyboard shortcuts.

  • Do not place files in the user's System directory or the Windows directory unless you're doing so from an installer. Aside from the permissions issues that you will run into, this is something that's considered bad form and can lead to damaging the user's computer. For example, if you were to overwrite User32.dll on a Windows XP machine with the User32.dll from a Windows 95 machine, bad things will happen.

  • Do not "call home" via the network to do things like serial-number checks without making it very explicit with what you're doing (unless your application is networked). Unexpected network traffic may display alerts on the user's system if the user has a software firewall, or may cause their computer to dial up unexpectedly.

  • Be sure to make use of the multiple menu bar support that Windows allows you. On the Mac, you only have one global menu bar, but on Windows, each window in your application can have its own menu bar. You can use this to help you stay away from MDI applications in some instances, and will generally provide for a better user experience when implemented properly.

  • Windows users are accustomed to having lots of functions available via contextual menus. They should be contextual (meaning that if you're over a button, you get a menu for the button, but if you're over an EditField, you should get a menu for the EditField). Most commands that are accessible via a contextual menu should also be accessible via the menu bar. Notice the contextual menu used by Windows Explorer:

    Figure 3

  • Make sure your control order is correct. The control order determines the tab order between controls. Tab ordering should flow from the top of the page downward, and from left to right. If the tab order skips all over the place, this breaks the flow of people's work. Control order is even more important on Windows because more controls can get the focus than can do so on the Mac (PushButtons, for example). Windows users tend to depend on the keyboard more than Mac users, so double-check your control/tab order when testing your application on Windows.

Final Thoughts

Like most other computers users, the first thing Windows users will do is check out your website to download your product. So make sure you have a professional looking website with Windows screenshots and terminology to instill confidence in the user.

Next, they'll download your product and try to unzip it. They expect it to be in a .zip format (not .sit, .sitx, .tar.gz, etc.) and will probably think twice if it's just a regular executable file. They'll expect to extract an installer from the .zip file that they can just double-click to run, or download the installer directly. Try to use a standard installer when possible, since it will comfort the user (since they'll have seen the installer before). After all that, they'll launch your application, and assuming it has a proper Windows look and feel as well as doing whatever it's designed to do, you will have gone a long way towards developing trust with Windows users.

Finally, here's a list of resources you may be interested in checking out for more information.

Windows Resources


  • InstallShield is one of the most widely used installers for Windows. You can find more information at
  • Another common installer is Inno Setup, which has the added benefit of being free. You can download it here:

Software Sites

  • is one of the most widely accepted places to post your software for download software in the Windows world.
  • Another common site is, though it is frequented less than

Your feedback is welcome. Please email me at:

Aaron Ballman is a software engineer at REAL Software, makers of REALbasic (a cross-platform programming language).

Return to