I routinely deal with what I consider bad design in programs and devices intended to run on Microsoft Windows. My most common complaint is the app/device/whatever doesn't run as a limited user or restricted user without considerable TLC, or worse, requires administrator access just to work.
Here is a practical guide to what the field administrator, such as myself, wants to see in a Windows application or device.
Note to fellow noders: Additional write-ups and comments are strongly encouraged.
How to Design for the Windows OS Today (2004)
Or, How to Fix Your Product That XP Broke.
reference: http://www.microsoft.com/winlogo/
Microsoft's requirements are best read before you write your first line of code. But for the most of us who forgot this, here are some real-world quick fixes.
This experience comes from my working with id Software's Quake II to demonstrate how to fix an existing Windows application. Visit http://www.pan-am.ca/testing.html for a modified Quake II and source code.
- Test fast user switching.
Any Windows program can support this transparently, unless the program requires exclusive access to some resource. The common exception to this is Systray applets, the little icons that show up by the clock in the Taskbar, because their designers assume only one desktop can run at a time. Wrong.
Printer monitors are an egregious example. The best way to make these things work is to redesign your applet as a Service, so it runs as a background process, and create a smaller program to communicate with it, through named pipes, DCOM RPC or something, that shows itself in the Systray.
Some things, like games using DirectX or OpenGL, just won't behave. The simple fix is to look for a second instance of your game running, and display some error dialog box explaining that the game won't work because another user's currently running it.
- Make a nice installer.
Take advantage of Windows Installer included with XP, and available for every version of Windows starting from Windows 95. There are a lot of good installer-creators available that create Windows Installer files, or MSI files. I prefer Advanced Installer by Caphyon to create the installer, then Microsoft's "orca" application to edit it. Both are free for basic installers.
Speaking of installers, install to whatever "Program Files" points to by default, so Windows has a chance to protect your installation from idiots deleting the files. This directory is read-only by default to non-Administrators.
- Test with a Limited User account!
I can't rant enough about this! The Limited User account is the security consultant's last and best defense against viruses, spyware, lusers and honest mistakes. It also transparently supports roving profiles, where the user can use any computer on the network and have their documents and settings follow them.
Any code that writes to files or makes Registry changes MUST use the current user's Profile Directory or Home Directory, and the Registry key HKEY_CURRENT_USER. These are guaranteed to have read/write access for the limited user. Only very few exceptions, such as Windows Services, can break this rule.
Even if you don't use the Registry or Windows API calls in your application, you can use environment variables to determine where to write stuff, such as the %userprofile% and %allusersprofile% variables. Be warned that the environment variables only work in Windows NT 4.0, Windows 2000 and XP, but the Windows API SHGetFolderPath() works for all Windows versions starting from Win95.
Removable devices (like USB devices) work just fine as a limited user, if an administrator installs the driver first.
And if your app runs into some kind of access denied error, please provide some useful feedback, like "Unable to modify 'c:\somefile.exe'," so consultants like myself can try to work around it.
- Don't touch the root of Drive C.
You have a Program Files directory for your code and unchanging files, a User Profile directory for your changing files, and a System directory (\windows\system32), should you need it, for Services and device drivers. These all have a default set of permissions that protect against mistakes, notably when the mistakes happen by a limited user. Take advantage of them.
- Test long filenames with spaces and everything.
It's my file and I'll call it what I want. Make sure your application understand this, notably in the face of "Documents and Settings/somelongusername.somelongdomainname/My Documents". Windows 95 had a maximum filename path size, defined as MAX_PATH, of 250 characters (or was it 260?), and this works fine for XP filename buffers for fixing an application right now. For the next project, use Unicode and the Unicode versions of the file APIs to support even longer filenames and paths.
- Don't worry about signing code.
Microsoft requires applications, device drivers etc have digital signatures to qualify for their Logo. In the real world, it doesn't matter whether or not your application is blessed with XP Holy Water, as long as you've tested it. And tested it again. And again. If you have the time, do consider getting signing certificates and sign your code, especially device driver code. But if you're just fixing an existing project it's not as important as the testing.
Test, test, and test some more. If you have an old installation of Windows 95 or Windows 98 kicking around, test on that, too, if you need to support that. Designing for XP doesn't mean you have to abandon older versions of Windows.
Do these things and you will make network admins and security consultants much happier.