gfecyk's Journal: Coding for Security, or "Testing Is Hard."

I read this a couple of days ago. The article it references suggests that IT administrators are petty dictators who don't let developers get their job done. or at least that's the impression I came away with.

Most of the comments posted by Slashdotters supported admins, and being a contracted admin myself I have to support them too. I routinely deal with developers who don't test for current versions of Microsoft Windows. Among my clients, the worst are travel reservation network developers who still provide software for 16-bit Windows. Coding for 16-bit Windows is bad enough, but even 16-bit Windows code can function in Win2K or XP as a restricted user, or even with mutliple users, with a little bit of tweaking.

*IX coders know how to program for multiple users and for a restricted environment. They use the environment variables provided by the OS to determine where they should save stuff. Modern versions of Windows make it easy to do the same thing, even if you don't want to use Win32-proprietary constructs like the Registry. For example:

• %USERPROFILE% = $HOME - if %HOME% doesn't already exist, look for %USERPROFILE%.
• %ALLUSERSPROFILE% is a place to store per-machine settings, like license keys, terminal addresses and so on. Normally, only Administrators can write here, but everyone can read from here.
• Items written to %USERPROFILE% automatically follow the user around in their roving profile, if roving profiles are in use on a network. Another possibility, like Galileo uses, is to let the installer specify a network drive for user settings and use the user's home directory (H: or Z: usually). Just make sure your users have this drive, and spell out the requirements in your install guide so guys like me aren't scratching their heads.
• For "Bob's" sake, don't automatically install in C:\(whatever). Use Installshield or Windows Installer to package your app, and let it find where "Program Files" is. Smart admins like me will restrict access to the root of hard drives so users aren't tempted to store stuff there, and not get backed up on the servers.
• Test, test, and test some more. Give your customers perks for testing your software, and be prepared to receive feedback. Lots of it.
• If you use the Registry, store in HKEY_CURRENT_USER first. Only store machine-specific stuff in HKEY_LOCAL_MACHINE and expect that most of your users won't be allowed to change stuff there.
• 16-bit coders: %WINDIR% is NOT where you store stuff! Give us the chance to specify an alternate location to store stuff. Sabre has a "Userdrive" setting which you can change to a home drive but there's no installer option for it. Don't expect to have write permissions in %WINDIR%.
• %TEMP% != %WINDIR%\TEMP - Win2K and XP change %TEMP% for each user using short filenames, and is recognizable by 16-bit Windows apps.
• If you code for Java, including Sun's JVM, look at the Java environment for where you should save settings. It's much the same. Why, oh why does Sabre for Java store its settings in C:\SABRE instead of %USERDIR% or whatever it's called?

See? That wasn't hard.

If you are a developer who deals with the travel industry, expect to see more of me. I'll gladly hand you a copy of this rant if you need help. Oh, and I also test applications for a measly C$30.00/hour. Take advantage of it.