In my last post, I told the tale about my travels with UAC and Pre-Vista/2008 Ready Applications. In tonight's post, as promised, I'm going to attempt to explain why UAC and Pre-Vista/2008 Ready Applications interact they way they do (in a semi fairytale format). Hopefully... you all like it. :>)
A long time ago in a galaxy far, far away, there was a company called Microsoft that created an operating system called Windows. Unfortunately, the Windows operating system lacked a built-in method to elevate a process from that of a standard user account to an administrative account. If you wanted to run a process using administrative rights, you had to either, log off, us Run as, or the realms personal favorite - always use an administrative account to begin with. Needless to say... this aspect of Windows was "bad" and in time a clan of evil wizards decided to subject Windows to their malicious ways.
After many years of senseless chaos, the powers at Microsoft decided that enough was enough and action had to be taken to defeat the evil wizard clan. So, for their "soon" to be updated version of Windows (Vista), Microsoft developed a magical technology called User Account Control (UAC). This technology, which is similar to something called "Sudo", was focused on limiting applications to using a standard user account regardless of a user's held privileges. Then if an application needed to complete an administrative task, the user would have to explicitly approve execution at a higher privilege level.
In creating UAC, Microsoft thought they had solved the privileged process execution problem, thus also defeating the evil wizard clan. However, after Vista was released, UAC soon proved to be both troublesome and annoying. One such troublesome aspect was with how UAC interacted with Pre-Vista/2008 ready applications. For you see... UAC uses an application's manifest file to determine if an application is an administrative application thus requiring it to prompt the user for elevated execution. With Pre-Vista/2008 ready applications, this information is missing in the manifest file because UAC didn't exist in previous versions of Windows. Thus, if a user were to attempt to execute an application that requires administrative rights, but lacks the required UAC information that defines the required privilege information. The user would most likely be prompted with an "elevated rights are required" message and stop execution.
***More importantly is this behavior with installers that call other applications or resources to complete an overall installation task. Those new processes are executed under the parent process's privilege level. You can kinda see where that one is going.***
Anyhow, to correct this issue, you have three options. One, have the application developer update their application and make it UAC compatible. Two, use Microsoft's Application Compatibility Toolkit to create a compatibility fix for the application. Or, just always execute questionable applications or installation packages using elevated rights.
Oh yeah... UAC and the evil wizard clan lived happily ever after!
Latest software headlines from Network World:
At 10, Google reiterates commitment to CIOs
As Google turns 10, enterprise success in question
Zoho adds Google Docs-like file management
|
Does Verizon's Voyager stack up to the iPhone? |
|
|
5 IT skills that won't boost your salary
[1,407]
Women 4 times more likely than men to cough up personal info
[589]
Japan's 10 funniest tech-related commercials [Videos]
[407]
Throwing away a promo CD is "unauthorized distribution"?
[1,265]
Adults too quick to dismiss educational video games
[682]
Attack of the iPhone clones [Slideshow]
[578]
10 things IT needs to know about AJAX
[1,258]
This Year's 25 Geekiest 25th Anniversaries [Slideshow]
[409]
|
|