Lots of Vista info for qurious Windows users
- utopiomania
- Addict

- Posts: 1655
- Joined: Tue May 10, 2005 10:00 pm
- Location: Norway
Mike, thanks for the link. I've read some pages, and I wonder how it's going to affect my installer which
writes to HKEY_LOCAL_MACHINE to make the uninstall procedure appear in controlpanel add/remove
programs.
If I run it as a standard user (limited rights) in XP, XP allows me to log on as an admin an continue
the install successfully, but it won't work if I continue as a standard user with limited rights. Nothing
gets installed.
I wonder if Vista allows standard users to run installers or if Installers requires admin rights to run
correctly?
Has anyone installed programs under Vista with a standard user account?
writes to HKEY_LOCAL_MACHINE to make the uninstall procedure appear in controlpanel add/remove
programs.
If I run it as a standard user (limited rights) in XP, XP allows me to log on as an admin an continue
the install successfully, but it won't work if I continue as a standard user with limited rights. Nothing
gets installed.
I wonder if Vista allows standard users to run installers or if Installers requires admin rights to run
correctly?
Has anyone installed programs under Vista with a standard user account?
-
Mike Stefanik
- User

- Posts: 53
- Joined: Wed May 03, 2006 6:34 am
- Location: California, United States
- Contact:
Applications can add a manifest which specifies that it needs to run with elevated or administrator privileges; when that happens, they'll get a UAC prompt asking them for the administrator password.
Of course, if a key is being written in the registry or a file is being created with administrative rights, a standard user would also need privileges to be able to access that key. I think in the vast majority of cases, folks won't run into a problem with older applications as long virtualization is enabled; but as I mentioned earlier, that's only really a short-term solution.
It's nothing for programmers to panic over, but it is something that they need to factor into their development plans and make changes as necessary. You can no longer make the assumption that your program will have complete access to every resource on the system.
Of course, if a key is being written in the registry or a file is being created with administrative rights, a standard user would also need privileges to be able to access that key. I think in the vast majority of cases, folks won't run into a problem with older applications as long virtualization is enabled; but as I mentioned earlier, that's only really a short-term solution.
It's nothing for programmers to panic over, but it is something that they need to factor into their development plans and make changes as necessary. You can no longer make the assumption that your program will have complete access to every resource on the system.
Mike Stefanik
sockettools.com
sockettools.com
- utopiomania
- Addict

- Posts: 1655
- Joined: Tue May 10, 2005 10:00 pm
- Location: Norway
-
Mike Stefanik
- User

- Posts: 53
- Joined: Wed May 03, 2006 6:34 am
- Location: California, United States
- Contact:
You can completely disable UAC by opening the Control Panel and selecting User Accounts and Family Safety -> User Accounts -> Turn User Account Control On or Off
You can modify UAC on your system by changing your security policies. From Start -> Run enter "secpol.msc" and select Local Policies -> Security Options. If you normally use an account with administrative privileges (most Windows developers do), you can tell it to automatically elevate privileges by changing the "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" setting. Keep in mind that if you set it to "Elevate without prompting", you'll get a security center warning that your system is no longer secure.
You can also disable UAC for administrators through the "User Account Control: Run all administrators in Admin Approval Mode" setting. That will also give you a security center warning.
In general I would really recommend that developers don't disable UAC, even though that does make things more convenient. If you use an account with administrative privileges and have UAC disabled, you're basically back to using the XP security model. The problem is, most end-users will have UAC enabled, so you'll end up testing your code in an environment that doesn't match your user's. You could have a program that just runs fine on your system, but fails elsewhere.
It's not really reasonable to require your end-users to disable UAC. Technical issues aside, if you tell them to do that, they're always going to see this red "shield" icon in the notification area and a warning when they boot up telling them that their system is not secure. Not a very good way to give your customers a warm, fuzzy feeling about your software; that in order for it to work, they have to make their system "insecure".
You can modify UAC on your system by changing your security policies. From Start -> Run enter "secpol.msc" and select Local Policies -> Security Options. If you normally use an account with administrative privileges (most Windows developers do), you can tell it to automatically elevate privileges by changing the "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" setting. Keep in mind that if you set it to "Elevate without prompting", you'll get a security center warning that your system is no longer secure.
You can also disable UAC for administrators through the "User Account Control: Run all administrators in Admin Approval Mode" setting. That will also give you a security center warning.
In general I would really recommend that developers don't disable UAC, even though that does make things more convenient. If you use an account with administrative privileges and have UAC disabled, you're basically back to using the XP security model. The problem is, most end-users will have UAC enabled, so you'll end up testing your code in an environment that doesn't match your user's. You could have a program that just runs fine on your system, but fails elsewhere.
It's not really reasonable to require your end-users to disable UAC. Technical issues aside, if you tell them to do that, they're always going to see this red "shield" icon in the notification area and a warning when they boot up telling them that their system is not secure. Not a very good way to give your customers a warm, fuzzy feeling about your software; that in order for it to work, they have to make their system "insecure".
Mike Stefanik
sockettools.com
sockettools.com
Not at all, just disable that warning iconl. That can be done separately for each warning messageMike Stefanik wrote:It's not really reasonable to require your end-users to disable UAC. Technical issues aside, if you tell them to do that, they're always going to see this red "shield" icon in the notification area and a warning when they boot up telling them that their system is not secure. Not a very good way to give your customers a warm, fuzzy feeling about your software; that in order for it to work, they have to make their system "insecure".
I Stepped On A Cornflake!!! Now I'm A Cereal Killer!
-
Mike Stefanik
- User

- Posts: 53
- Joined: Wed May 03, 2006 6:34 am
- Location: California, United States
- Contact:
I can guarantee you that any user with good sense (and any business) would give your software a pass if you told them that a requirement of using your program was disabling UAC and then hiding the warning icon in the notification area.GeoTrail wrote:Not at all, just disable that warning iconl. That can be done separately for each warning messageMike Stefanik wrote:It's not really reasonable to require your end-users to disable UAC. Technical issues aside, if you tell them to do that, they're always going to see this red "shield" icon in the notification area and a warning when they boot up telling them that their system is not secure. Not a very good way to give your customers a warm, fuzzy feeling about your software; that in order for it to work, they have to make their system "insecure".
Not a good idea.
Mike Stefanik
sockettools.com
sockettools.com
- utopiomania
- Addict

- Posts: 1655
- Joined: Tue May 10, 2005 10:00 pm
- Location: Norway
Well, I think the whole idea behind UAC is good. If users can loaf along using programs that don't need
admin rights to do things, they are in a much safer environment,
and I would like to contribute to that by writing apps that conform to the MS guidelines linked to in Mikes post.
There's lot's of info out there about this http://blogs.msdn.com/junfeng/rss_tag_Vista.xml
admin rights to do things, they are in a much safer environment,
and I would like to contribute to that by writing apps that conform to the MS guidelines linked to in Mikes post.
There's lot's of info out there about this http://blogs.msdn.com/junfeng/rss_tag_Vista.xml
Hmm most of the time microsoft was really good at copying features, however it seems they lost this with Vista, the 3d accelerated Desktop needs dozens of times the power of Apples Aqua (which runs fine on integrated graphics cards), as well as aiglx/xgl which the Linux guys put up in 1-2 year(s). It seems that because *nix always had the strong seperation between the User accounts they also have a big advantage in this area. I mean there are very few applications whichneed root privileges, this is mostly only needed for software that realy administers like the package manager or disk formating tools.
On the other hand the open source way makes things much easier because someone will definitely fix an application if it's needed and it doesn't comply to newer standards.
On the other hand the open source way makes things much easier because someone will definitely fix an application if it's needed and it doesn't comply to newer standards.
Visit www.sceneproject.org
Enable Vista Glass look on Unsupported Video Cards
If you have an older graphics card that isn't completely supported by Vista and the special effects has been disabled after installation of Vista here's a way to manually enable it.
To turn on this effect just execute c:\Windows\System32\UXSS.exe or enable and start the User Experience Session Management Service.
1. Open up Regedit.
2. Navigate through HKEY_local_machine, Software, and Microsoft.
3. Create a new KEY called DWM.
4. In the new DWM key you created, create a DWORD called EnableMachineCheck.
5. Make sure this value is set to 0 and hardware checking is now disabled.
Quick Note: Although you can get it to run on older hardware, with the lack of WDDM drivers available, it is going to run very slowly if at all.
To turn on this effect just execute c:\Windows\System32\UXSS.exe or enable and start the User Experience Session Management Service.
1. Open up Regedit.
2. Navigate through HKEY_local_machine, Software, and Microsoft.
3. Create a new KEY called DWM.
4. In the new DWM key you created, create a DWORD called EnableMachineCheck.
5. Make sure this value is set to 0 and hardware checking is now disabled.
Quick Note: Although you can get it to run on older hardware, with the lack of WDDM drivers available, it is going to run very slowly if at all.
I Stepped On A Cornflake!!! Now I'm A Cereal Killer!