Windows OSS Only For Administrators?

Torsten writes "We all know it: it is no good idea to run Windows with Adminstrator privileges all the time. But when you use a normal user account, many programs will not work properly. I have recently recognised that even open source software has difficulties with the Windows rights model. Openoffice will continue to ask for registration until an Administrator stops it. Firefox will not install new search plugins for normal users and will not even tell why. FlightGear starts the configuration screen, but only an Administrator can fly. Have the OpenSource developers problems adapting the windows right model? Or does nobody bother being Administrator?"

Re:Seems like...

[I8TheWorm]

Create a test account on the box with very few privileges. Really, any developer worth their weight ought to know to have a non-development environment to test projects.

Further out on the extreme branch, one could either partition and install a few OS's, or use MS Virtual PC to create a few different "boxen" with different OS's, different patches, etc... to get a full view of what the project is(n't) compatible with.

Happens all the time

[red_dragon]

If you spend enough time with NT-derived versions of Windows, you'll find that a lot of software simply assume that it is running under Windows 95/98/ME or require that you do some fiddling with permissions on the filesystem or registry to run properly. This causes me no end of grief as I try to keep our PCs sufficiently protected from stupidity while being functional enough to avoid receiving support calls.

All of the examples given can be duplicated in commercial software. MS Office 2000 won't stop displaying the "please register" nag dialogue box until an admin dismisses it. Regular users can't install plugins in Internet Explorer either, although I guess one could set the plugins directory to Everyone:F, but that's big security hole. One little commercial programme we use here to track fixed assets won't run under a regular user account unless its registry key in HKEY_LOCAL_MACHINE is set to full access to everyone because it keeps running state information there. Nero Burning ROM will not burn dics under a regular account without installing an extra utility that grants disc burning privileges to admin-specified users or groups. Palm Desktop, even in its current iteration, keeps user data in its programme directory, which requires the admin to set the directory's permissions to Everyone:F - again, another gaping hole. The list goes on and on, and it goes to show that a good part of the crappy Windows user experience is caused by the lousy software that runs on it.

Backwards compatibility

[kawika]

Windows 9x apps could drop files anywhere they pleased, and they did: the Windows directories, app directories, the root of the drive, you name it. Windows NT/2K/XP solved this issue with the "Documents and Settings" area, and that's supposed to be where apps put their temp files, logs, databases, and other data. But most 2000 and XP systems loosen security to make old apps work. (How could apps write .INI files in the Windows directory otherwise?)

Since old apps don't break, developers are tempted to follow bad examples or old habits. It seems like the only way this would change is if Microsoft shipped XP as secure by default--the default user would not be an admin, and NTFS security was set to prevent writes to Program and Windows dirs. That would cause a massive support headache.

The Windows Installer [microsoft.com] docs have some guidelines on where things should go for best compatiblity, but of course a lot of people use other installers and those may not try to enforce any rules. This doesn't seem to be an issue that Microsoft is crusading about, but maybe they should.

Re:The solution I used...

[Anonymous Coward]

Thanks for the great BT client, works great out of the box, no tweaking necessary and it complies with the windows idea of where app settings and the like should be stored.

You're absolutely right about it being an elegant solution. Ignore the naysayers and keep up the good work.

Change Permissions

[Noksagt]

If you trust the software, just grant the Users group extra permissions & file a bug report for what you had to do. In environments where I trust the users, I am lazy & grant users the same permission for the apparently relevant files and directories as the accounts that can run the software. On some occasions, this includes changing permissions of dlls outside of the installation directory. I use listdlls [sysinternals.com] to do this. In less trusted environments, I will gradually add read+execute access for the users to the programs & dlls users need. If I get sick of trying to fix it, I usually reevaluate the need to install the program or the level of trust to grant the users.

OpenOffice on Multiuser Windows Systems

[sybarite]

I'm not trying to through rocks, but trying to highlight a need... Running OpenOffice on a Windows system with multiple users where said users are not administrators is a problem for me and an impediment to the adoption of OpenOffice for many of my clients. Most Windows software I run needs to be installed only once while administrator and then all other nonpriveleged users can run the software. This doesn't appear to be the case with OO. I don't get the per-user install requirement for OO. This problem is most pronounced on Citrix. I found an ugly script that includes multiple reghacks on OOOforum.org that I will soon test, but in general, this issue has got to be an impediment to OO deployment on many Windows networks.