This post is part 3 of a series about using a limited (standard) account in Windows for everyday activities rather than logging in as a computer administrator all the time. (You may want to read part 1 and part 2 before continuing.)
If you follow my advice and switch to a limited account, you may find that some of your programs stop working. This is annoying, but there are various ways to deal with it.
I’ll start with a bit of history. As Neal Stephenson once said: “In the beginning was the command line.” Back in the early 1990s, my PC ran MS-DOS, so when I turned it on it went straight to a command prompt; I didn’t need to log in first. Installing new software would basically involve creating a new folder and then copying files off a floppy disk. This meant that it was standard practice for applications to be self-contained: if they needed to create any new files (e.g. a saved game) then they’d use the installation folder. That way, if you removed the application, everything would go, and you wouldn’t have any stray files lurking around.
Windows 3.1 sat on top of DOS, and there was still no security: anyone who turned on the computer had full access to everything on the hard drive. For instance, if you ran Word (or “Word for Windows” as it was then!) you could save documents anywhere you liked. Installing new applications was a bit more complicated, because you’d often need to copy DLL files to the Windows folder, but you would put the main installation folder anywhere you liked (e.g. C:\Games). Windows for Workgroups 3.11 allowed you to log into a network, but that only affected what you could do elsewhere (e.g. which folders you could access on the server); everyone who logged in could still access the whole hard drive of the local PC.
When Windows 95 came out in 1995, it introduced the “C:\Program Files” folder, and developers were encouraged to install applications there. It also had a login screen, even if you weren’t on a network, but this was just a way to share a machine and let everyone choose their own settings, e.g. desktop wallpaper. If you clicked “Cancel” on the login screen then you could still get in, and everyone still had full access to the whole hard drive. (The same applies to Windows 98 and Windows ME.) Windows 95 also introduced the registry, which (more or less) replaced ini files.
Meanwhile, Windows NT was aimed at business users, and it took security a bit more seriously. Everyone had to log in, and different people had different permissions. In particular, there were three main groups: Users, Power Users, and Administrators. Users could just log in and run programs, Power Users could install new software, and Administrators had full control over the machine, e.g. they could create new user accounts. (In practice, a Power User could become an Administrator fairly easily, so there wasn’t much difference between these groups.)
Windows NT was superceded by Windows 2000, then Windows XP merged the two “tracks” (home/business) together, followed by Windows Vista and Windows 7. So, all modern copies of Windows support security groups with varying levels of access to the hard drive and registry.
Unfortunately, some software still assumes that it has full access to the machine, because the developers haven’t kept up with current events, so they’re still following old habits. In fairness, this is partly because some development environments (e.g. VB6) require admin privileges, but that’s no excuse for not using a separate machine for testing. I reported a problem to one software company, and they sent back an email that literally said “We can’t imagine anyone not running as administrator.”
Again, I have to defer to Aaron Margosis, who has written several useful articles about this:
What is a “LUA Bug”? (And what isn’t a LUA bug?)
Fixing “LUA bugs”, Part I
Fixing “LUA bugs”, Part II
Changing access control on folders vs. files
In particular, he has written the excellent LUA Buglight tool, which I have used several times to diagnose problems. Basically, you use it to run a program with two sets of credentials (standard and admin). If the program tries to do something as a standard user but fails, LUA Buglight will intercept the code and provide admin credentials instead. When you’ve finished running the application, you get a list of all the things the program is trying to do which it can’t, e.g. opening particular files or modifying a particular part of the registry.
A typical problem is for an application to keep all its files together, so programs and data are all stored in the installation folder. If you’ve installed the program under “C:\Program Files”, that folder is read only, so you won’t be able to modify those data files. I’ve also seen applications that create log files in the root of the C drive; in Windows 2000, everyone could do that, but in Windows XP (and later versions) you need admin privileges for that. The annoying cases are where the program doesn’t need to modify the file at all, but it’s opening it with read/write access anyway! E.g. this might be a data file that stores the location of a database, so the application has to read in information from the file each time it starts up. In that situation, I normally give the INTERACTIVE group Modify rights to the individual file, so that the rest of the folder is still protected.
Aside from LUA issues, I’ve found it useful to separate programs from data because it makes my backups easier. If my hard drive went up in flames, I’d re-install Windows and applications from CDs/DVDs, then I’d just need to retrieve my documents from a backup. On the plus side, some applications will let you configure the location of data files, even if they default to the installation folder. For instance, Word 2003 has the default template (Normal.dot) in its installation folder, which is then read-only to standard users, but you can use the Options screen to refer to your own copy elsewhere.
If you can’t reconfigure software, the ideal scenario is that you get the developers to fix the problem, but that’s easier said than done. In my experience, the worst offenders are the companies who produce special hardware with bundled software. For instance, suppose you buy a heart rate monitor, which can then copy its data to your PC. In that situation, you’re stuck with the software that they provide – you can’t shop around, unless you’re willing to replace all the hardware as well. In some cases, there’s only one company that actually produces suitable hardware, so they have no incentive to fix their software. The only way you can get any leverage is to talk to the company before you hand over any money; that’s obviously easier if you’re buying expensive equipment for your company than it is as a home user.
In theory, open source software has a great advantage here, since you can fix the problem yourself. Sadly, it can be a bit more complicated than that. For instance, GameBase has some LUA bugs: it stores the Access databases in the installation folder and it saves configuration details in the registry under HKEY_LOCAL_MACHINE (rather than HKEY_CURRENT_USER). Since it’s open source, I was able to download the source code, and it’s in a language that I know (VB6). However, I don’t have a licenced copy of VB6, so I decided that it would be better to convert it into VB.NET and then fix the LUA issues at the same time. I started in June 2007, and I’m still working on it! The main problem here is that I don’t have a huge amount of spare time, and nobody else in the GameBase forums has the skill to help me. (I’ve heard people describe SourceForge as “the place where open source projects go to die”, and I think there’s a lot of truth in that.)
You may find that some problems take a while to appear. I mentioned DigiGuide in part 1, and I initially installed that when I used one account for everything (i.e. my everyday account had admin privileges). This meant that I was the owner of the installation folder, so I still had full control over it even when I stopped being an administrator. It’s better for the Administrators group to be the owner in this situation, and you can control this through Group Policy (again, see Aaron’s blog for details).
There are some applications which really do need to run as an administrator. In this case, “Run As…” can be quite useful. Hold down the SHIFT key while you right-click on the application (either the shortcut or the actual program file), then choose “Run As…” from the pop-up menu, and type in the username/password for a different account. That way, you don’t have to log out, and you just run that one program as admin rather than all your programs. Unfortunately, there are a couple of snags:
1) If you’re in a workplace with roaming profiles, and the alternate username you specify hasn’t logged in there before, you may have to wait a minute or so before the application launches, since it has to copy your profile to that PC.
2) If you’re using mapped network drives, they don’t work here. For instance, suppose that you try to run a program on your Z drive: the alternate user won’t know what your Z drive is, so it says it can’t find the program. However, the bizarre thing is that this still happens when both accounts have the same drive mapping! In practical terms, that means that I sometimes have to copy setup programs to the local hard drive first, and run them from there.
Ultimately, you will have to decide how important a particular application is to you. Microsoft have a list of programs that don’t work correctly, although it was last updated in 2005 so it’s a bit out of date now. That list includes “Mary-Kate and Ashley’s Dance Party of the Century”, and I don’t think you’d really be any worse off if you couldn’t run that anymore! On the other hand, they also mention Quicken (accounting software), which might be critical to a company’s operation. At the very least, if you try running as a standard user for a while then you can gauge the extent of the problem and make an informed choice about whether to revert to running as admin.
There are some changes in Windows Vista and Windows 7 that make life a bit easier, and I’ll discuss them in part 4.