Main Area and Open Discussion > General Software Discussion
Windows 7 — first impressions
Stoic Joker:
In my field I frequently run into vertical market software that is exorbitantly priced, slapped together, and rushed to market (prime offenders for permissions headaches). (Client needs security but can't afford update...) So for simplicity's sake I have reset the NTFS permissions on only the program's install directory, which leaves the rest of the system's security intact but lets the program run for users with out making the Admins. Surgical strike as opposed to throwing the baby out with the bath water.
Just a thought ;)
J-Mac:
And then there are some developers who are apparently trying but it simply isn't working. I use - or use to use up till a few days ago - ACDSee Photo Manager 2009. Worked fine on XP and Vista, but won't work for many on Windows 7. For months ACD Systems was totally silent on the problems but recently they finally posted a warning that the program isn't working for "some users" on Windows 7. However it is certified as Windows 7 compatible by Microsoft. If you had looked at the Windows 7 Compatibility page for ACDSee just a few days ago it showed ACDSee Photo Manager 2009 as fully compatible. Yet some were claiming that the number of users who could not use it on Win7 exceeded 50%, though I don't know of any valid statistics on that. Suffice it to say that the ACDSee forums and other image software-related forums have a heck of a lot of posts about it. It seems that after installation the software runs fine the first time. Then it never runs or runs poorly and usually crashes the system every time after that. Something to do with the file locations and permissions that it uses. Microsoft says it "should" work, and indeed it does for many. But it crashes a lot of folks also.
Anyway that program stayed on the compatible list for months and was just removed yesterday or the day before. Now it shows ACDSee 10 as "Coming soon". Which means I guess that they are not going to fix whatever is causing problems in the current version. And that isn't he only developer with issues like this. So ACDSee gets by UAC because it is officially pronounced as OK, while others, mostly from private developers who can probably least afford the additional programming, get honked by UAC every time. It needs work. No one should need to either install all programs to a different drive than C:\, nor set up programs to start as scheduled tasks to get around this "annoyance".
Jim
Carol Haynes:
All a developer has to say to a customer is 'cheange the permission in the shortcut that starts the app'. You can easily set any app to avoid UAC if you need to.
Personally I think it is a good idea that MS have put an obstacle in the way of sloppy software writers. At least the user knows that poorly coded software needs elevated privileges to run properly and have the choice of saying 'yes I trust them' or 'no I don't' on older systems the user is blissfully unaware.
Having said that I presume MS certified that ACDSee was Win 7 compatible because ACDSystems are big enough to cough up for the certification. I don't know how much test MS do on software to get into their list but I bet it isn't much more than run the installer and see if it works.
What I don't understand is why MS didn't simply make the choice of making all new user accounts default to user level security (and they could have done that back from Windows XP). Most of these issues would have been ironed out long ago. Seems to me that they are too lily livered to do the write thing so they introduce UAC as a kludge to fix something that isn't basically broken - just a bad choice.
f0dder:
Poorly programmed isn't the same as crapware. In this case, it's about not following design guidelines that have been around since, oh I dunno, NT4 or so. It's not about "satisfying the UAC program", stuff throwing UAC prompts simply wouldn't have worked on XP (or win200 or NT4 or anything non-Win9x) when not running with an account with administrative privileges.
And for the case of Everything, it's perfectly fixable: as mentioned before, the program needs to be split into a service running with admin privileges that have access to the MFT, and a GUI frontend that runs privilege-less and communicates with the service. Presto, problem solved. It's been the proper way to handle this kind of thing at least NT4 (I don't have experience with pre-NT4.)
ACDSee breaking probably has nothing to do with UAC but everything to do with poor programming practices... hardcoding locations, doing tings in nonstandard ways, whatever.
What I don't understand is why MS didn't simply make the choice of making all new user accounts default to user level security (and they could have done that back from Windows XP). Most of these issues would have been ironed out long ago. Seems to me that they are too lily livered to do the write thing so they introduce UAC as a kludge to fix something that isn't basically broken - just a bad choice.
-Carol Haynes (December 11, 2009, 07:40 PM)
--- End quote ---
I agree fully that MS should have made the default user non-admin a long time ago - preferably at the time of Win2000, and definitely no later than WinXP when people really started migrating from Win9x. Also, WinMe should never have seen the light of day, Win98 should have been the last 9x Windows.
I find UAC to be a pretty nice system, though - the alternative would be having to run applications in admin mode and always supplying an admin password in order to be able to do so...
Carol Haynes:
I find UAC to be a pretty nice system, though - the alternative would be having to run applications in admin mode and always supplying an admin password in order to be able to do so...
-f0dder (December 12, 2009, 12:46 AM)
--- End quote ---
UAC is just a poorly designed fix - it is slightly less poorly designed in 7 than Vista but nevertheless it is and always will be an excuse for not doing the right thing.
Few, if any, user level applications NEED admin rights to run and if they do they can be written properly so that the relevant parts can be elevated to admin status during setup.
How about having a system similar to secure layer certificates for website so that any application requiring elevated privileges has to have a certificate (not necessarily from MS) so that you can clearly identify the source of the software. If SSL cert providers broadened their scope to include this kind of cert then it wouldn't cost developers much to certify their apps and it would be a real incentive to get the apps correct in the first place. Multiple certs for different applications from the same developer could be very cheap because the initial identification would go through with the first registration.
There could be an exception (UAC style) just for installation so you don't have to log out and login as an admin user to do that. But then the installers would need to be certified to run at that level.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version