UAC/UAP hopes

  • Thread starter Thread starter deebs
  • Start date Start date
D

deebs

I think I can understand why limited user accounts in XP Pro may not
have been popular.

Recent experience with an all-in-on unit under XP Pro to scan something
works swimmingly under admin login but under a limited user login the
same task generates an error and report followed by a prompt closure
with task not even started.

I wonder how easy it will be under Vista to work around those sort of
events?
 
Microsoft has spent a lot of time trying to make the new security in vista
work as well as possible with legacy and poorly written applications;
however, this time around, security was put first and application
compatability second. It is ultimately up to the application developers to
change their ways.

I suppose Microsoft had to make a decision ... users can either suffer from
poor security and stability (and blame Microsoft) but have most applications
work in order to appease application developers, or users can have better
security and reliability but suffer from poorly written software (and
probably still blame Microsoft but we all know this is the application
developers fault).

Unfortunately, both choices cause suffering... but I think MS made the
correct decision.
 
As a late addition:

i am surprised how many programs do not run under a limited user account in
Windows XP.

Given the time that XP has been around one would have expected providers to
have met a good practice workflow of:
- install from admin
- run from limited user

If one's own experience is anything to go by, and i am not saying it is, it
seems the majprity of stuff available on XP is limited to running in admin
accounts?
 
If one's own experience is anything to go by, and i am not saying it is,
it seems the majprity of stuff available on XP is limited to running in
admin accounts?
Click to expand...

That's been my experience as well.

A lot of programs simply expect the user to be admin - primarily because the
"average user" has always been an admin. In XP it is more complicated to
develop an application that works as a standard user. The result: Many
programmers don't take the time to do it right. If it won't be a big deal to
most of their customers, and it's harder to do right, they simply don't
care.

Now, the "average user" will always be a limited user, with the minority
running as admin (disabled UAC).

This will benefit everyone, even the users who turn off UAC, in the long
run, as applications will finally be developed in accordance with
Microsoft's guidelines, since they no longer have a choice if they want the
"average user" to be able to use thier program.
 
If the user subsequently updates the program to the Vista-aware version (a
free upgrade) then the virtualized Program Files can lead to complex
problems. I know you can disable virtualization using a manifest, but then
won't some of the user's files seem to disappear? To fix up an app whose
former version has fallen prey to virtualization seems a non-trivial task.
Click to expand...

You are correct, this is a real pickle. It would be unsafe to move files
from their virtualized locations to a new folder during the upgrade process
(unless you replace them with symlinks or hardlinks), as there may be other
applications relying on that location.

Also, if the user has saved a file to a non-standard virtualized location,
you have no way of finding them, unless your files have a unique extension
or some other uniquely-identifiable information in them that you can scan
for.
Personally I think this virtualization has more problems than benefits,
especially for Program Files. On XP, if you do not have admin rights, an
attempt to write to Program Files will be denied access. So the user will
be forced to write somewhere else. Problem solved.
Click to expand...

Yes it does have some nice benefits, but as you have discovered, it is a
real PITA in more ways than one in many circumstances :)
Writing to the HKLM registry is more complex, because the program may just
fail silently. But this is something applications REALLY shouldn't have
been doing.
Click to expand...

Agreed. At best, this will save millions of people from the current
generation of spywares. At worst, it will make it much easier to clean up.
 
Jimmy said:
That's been my experience as well.

A lot of programs simply expect the user to be admin - primarily because
the "average user" has always been an admin. In XP it is more
complicated to develop an application that works as a standard user. The
result: Many programmers don't take the time to do it right. If it won't
be a big deal to most of their customers, and it's harder to do right,
they simply don't care.

Now, the "average user" will always be a limited user, with the minority
running as admin (disabled UAC).

This will benefit everyone, even the users who turn off UAC, in the long
run, as applications will finally be developed in accordance with
Microsoft's guidelines, since they no longer have a choice if they want
the "average user" to be able to use thier program.
Click to expand...

Hi Jimmy:

I am a developer and I welcome the opportunity to modify my apps so they
will run as non-admin. In my case, it will be extremely easy (I think)
and I am mad at myself that I did not do this before.

The problem comes if people install and run the old version of my apps
on Vista. They actually will run pretty much correctly, but perhaps with
virtualization of Program Files (depending on what the user does). If
the user subsequently updates the program to the Vista-aware version (a
free upgrade) then the virtualized Program Files can lead to complex
problems. I know you can disable virtualization using a manifest, but
then won't some of the user's files seem to disappear? To fix up an app
whose former version has fallen prey to virtualization seems a
non-trivial task.

Personally I think this virtualization has more problems than benefits,
especially for Program Files. On XP, if you do not have admin rights, an
attempt to write to Program Files will be denied access. So the user
will be forced to write somewhere else. Problem solved.

Writing to the HKLM registry is more complex, because the program may
just fail silently. But this is something applications REALLY shouldn't
have been doing.

David Wilkinson
 
Back
Top