With Windows XP and lower, an administrator was always logged in as an administrator and a restricted user was always logged in as a restricted user. This meant that any program executed by an administrator would always be executed with full administrative rights. While any program executed by a restricted user would never have administrative privileges.
With the introduction of UAC, if a program required administrative privileges, such as writing to HKLM in the registry or writing to a system folder, the OS would notify the user of the required privileges before executing potentially damaging code - even when logged in as an administrative user. The OS determined this through the requestedExecutionLevel flag in the application manifest. If this flag was missing, the OS would do some fancy footwork and make a guess.
The key point here is that by embedding the required privilege within the program, a user - even a user with administrative privileges - did not have to work in a completely unprotected environment. This helps restrict access to much of the operating system when performing day-to-day tasks; and when malicious software is introduced on the machine, the restricted access given to that software should help mitigate any damage.
- Microsoft Download - Windows Vista/7 User Interface Guidelines
- MSDN Library - How to Create the Best User Experience for Your Application
- MSDN Library - The Windows Vista and Windows Server 2008 Developer Story: Windows Vista Application Development Requirements for User Account Control (UAC)
- MSDN Library - Windows Vista Application Development Requirements for User Account Control Compatibility
- MSDN Library - Designing UAC Applications for Windows Vista - Step 6: Create and Embed an Application Manifest (UAC)
- Microsoft TechNet - User Account Control Step-by-Step Guide
- Microsoft TechNet - Understanding and Configuring User Account Control in Windows Vista