Flyover Country

A while back, I created a table detailing every system color from every official Windows theme in existence. I keep moving or misplacing this page for some reason, but the link below works:

Here’s the table of Windows system colors in its entirety:

Possibly Related Posts:

• Dan Tynan is a dolt on Office 2007
• When is Too Much Transparency a Bad Thing?
• “We can’t spy…if we can’t buy!”
• Build Outlook 2007’s UI in WPF – Hand-on Lab
• Meet UAC – Why you must factor out your apps’ admin components

Let’s say you have a shareware application that can do exciting things like self-registration and updating on the fly. Back in the Windows XP days, supporting scenarios like these would be a cakewalk; you could simply write a serial number to HKLM, or run an MSI downloaded off the Internet. Too bad if a user didn’t have administrative privileges on their XP machine; that wasn’t really a normal scenario anyway.

Windows Vista throws an interesting kink into the mix with UAC. Now, an application cannot write data to protected locations like Program Files or HKEY_LOCAL_MACHINE unless it has administrative privileges. Just to make matters worse, your app cannot be granted new privileges once it’s running. Let me state this again, just because I’ve found this is the part of the message that gets missed most often.

Once your process is started, it cannot be granted new privileges. It also cannot shed permissions.

This is true if you’re running as a standard user or as an administrator. It doesn’t matter. A user whose account belongs to the Administrators group still must deal with UAC just like a standard user. The two key differences are:

1. Administrators receive a consent dialog (“are you sure you want to do this?”) as opposed to the credentials dialog standard users see (“please enter the user name and password for an account with privileges to accomplish this task”).
2. Processes launched by an administrator with administrative privileges (i.e. launched through a UAC consent dialog) run as the same user who launched them. Administrative processes launched on behalf of a standard user (i.e. with a UAC credentials dialog in the so-called “over the shoulder” scenario) run as the administrator who launched them. This is a extremely critical point. I have mentioned it before, and will do so again, because it is REALLY IMPORTANT.

Let’s say Abby just bought a brand-new machine with Windows Vista on it. She brings it home, sets it up, transfers her data off the family’s old Windows XP machine. Abby creates an account for herself (creatively named Abby) with administrative privileges. Abby also creates an account for her teenage son, Toby. Toby gets standard user privileges and some locked-down functionality courtesy of the new parental controls in Vista. For example, Toby is not allowed to play games rated M.

Not surprisingly, Toby doesn’t like this arrangement. He really wants to play Prey, Crysis, and Halo 2. Really bad. So, being the devilishly smart cookie that he is, he convinces his mom that he really needs to have Word or Notepad, or whatever, launched for him with administrative privileges. Toby goes to the File.Open dialog, navigates to the system32 directory, right clicks on MMC, chooses Open, selects the Users and Groups snap-in, and adds his account to the administrators group. Damn, mom just got pwned.

The bottom line is that requiring a piece of software to be run with administrative privileges in such a way that a standard user can interact with it can lead to very unexpected, very deleterious effects. This is why when you write software for Vista you should make absolutely certain that only the barest minimum chunks of code run with administrative privileges. For the 95% case, your app should never require administrative privileges to perform a task. For the other 5%, stay tuned: I’ll be writing about how to factor these pieces of administrative functionality into a separate application. 

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Embedding Manifests in Managed Apps
• Meet UAC – Creating a UAC Manifest
• Meet UAC – Understanding Virtualization and Run Levels
• An even better screen capture tool

Over the past few blog posts, we’ve looked into what Virtualization and run levels are all about, and learned how to create a Fusion manifest that is appropriate for inclusion on Windows Vista. When we created that Fusion manifest for Windows Vista, we never solved the problem of how to include it in your application. I gave you a hand-wavy answer about including the manifest file side-by-side with your app. This is an okay solution, but certainly not a great one. Ideally, we’d be able to embed our manifest directly into our managed exe, just like the big dogs do with their fancy native apps.

Today, we’re going to do just that. It’s actually surprisingly easy to accomplish this with Visual Studio 2005, due to the awesomeness of the managed Project system and MSBuild (not that I’m biased or anything ).

Step 1: Locate the Project in Solution Explorer that builds your executable.

Step 2: Double-click on the Properties node in Solution Explorer.

Step 3: Click on the Build Events tab in the App Designer (or Project Designer, or whatever it’s called).

Step 4: Add the following text to the Post-Build Steps:

“C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin\mt.exe” -manifest “$(ProjectDir)Borealis.exe.manifest” -outputresource:$(TargetDir)Borealis.exe;#1

Clearly, you should make sure that the path to mt.exe jives with the installation location on your machine, and you should name the manifest and output executable files according to what they’re actually called for your project (hey, what’s Borealis?). But yeah, otherwise you’re done. That was pretty easy, no? Check out the screenshot below.

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Why you must factor out your apps’ admin components
• Meet UAC – Creating a UAC Manifest
• Meet UAC – Understanding Virtualization and Run Levels
• An even better screen capture tool

Last time, we took a dive into what virtualization on Windows Vista is all about, and examined the different run levels available to your application. Like I mentioned before, unless you know for a fact that your app should run with higher privileges, you should always make your application run under asInvoker.

Today, we’re going to look at how to create a UAC-aware Fusion manifest, in order to deliver the best User Experience possible to your customers on Windows Vista.

The manifest file itself is relatively simple: it’s a blob of XML that sits either side-by-side or embedded within your executable. Back in the Windows XP timeframe, there were two ways to give your application Windows XP visual styles. The first was to call the method EnableVisualStyles() on the Application() class in your Main() method. The second was to create a Fusion manifest:

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1"
            manifestVersion="1.0">
  <assemblyIdentity
      version="Insert Your Exact Version Number Here"
      processorArchitecture="X86"
      name="Name of Application"
      type="win32"
  />
  <description>Description of Application</description>
  <dependency>
      <dependentAssembly>
          <assemblyIdentity
              type="win32"
              name="Microsoft.Windows.Common-Controls"
              version="6.0.0.0"
              processorArchitecture="X86"
              publicKeyToken="6595b64144ccf1df"
              language="*"
          />
      </dependentAssembly>
  </dependency>
  </assembly>

When Windows Vista came along, the simplest way for the UAC team to correctly support various runlevels was by overloading the functionality provided by a Fusion manifest to provide this extra information. You can specify the desired runlevel for your application by adding an extra bit of goop to your application’s manifest. If your app doesn’t have one yet, don’t fret! We’ll handle that, too.

UAC information specified within a Fusion manifest looks like the following:

    <!-- Identify the application security requirements. -->
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
      <security>
        <requestedPrivileges>
          <requestedExecutionLevel
            level="asInvoker"
            uiAccess="false"/>
        </requestedPrivileges>
      </security>
    </trustInfo>
  </assembly>

There are two key elements specified within the requestedExecutionLevel:

• level – This is the runlevel we explored last time. Unless you have a very good reason not to, you should always specify asInvoker here.
• uiAccess – Set this to “false” unless you know exactly why you require UI access. Essentially, this parameter specifies whether or not your application requires the ability to drive UI input into other apps. Examples of apps in this class would include assistive technologies like screen readers or automated UI testing frameworks.

The full Fusion manifest updated for Vista will look like this:

  <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity
        version="1.0.0.0"
        processorArchitecture="X86"
        name="ChimpSoftware.Borealis"
        type="win32"
      />
    <description>Chimp Software Borealis</description>
    <dependency>
      <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
          />
      </dependentAssembly>
    </dependency>

    <!-- Identify the application security requirements. -->
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
      <security>
        <requestedPrivileges>
          <requestedExecutionLevel
            level="asInvoker"
            uiAccess="false"/>
        </requestedPrivileges>
      </security>
    </trustInfo>
  </assembly>

Drop this text into a file named MyApplication.exe.manifest, and place it next to your executable. Clearly, MyApplication should be the name of your app. You should also replace the references to Chimp Software Borealis with references to the name of your app (gee, what’s Borealis?). Now, launch your app and then Task Manager. You should see that your application is no longer being virtualized. If you do bad things, like writing to Program Files or the Windows directory, these calls will now promptly fail. This is good, because those are bugs in your app. Go fix ‘em!

Clearly, you still need a way to bundle the manifest with your application. You could simply add the manifest to your setup application, but you’d be better off embedding the manifest directly into your application. Directions for doing this are pretty straightforward for native applications, and instructions already exist on how to do this. Trying to do this for a managed application with VS 2005 is trickier. Next time, I’ll show you how to solve this problem.

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Why you must factor out your apps’ admin components
• Meet UAC – Embedding Manifests in Managed Apps
• Meet UAC – Understanding Virtualization and Run Levels
• An even better screen capture tool

You’ve probably heard a lot about User Account Control (UAC) on Windows Vista already. Contrary to popular perception, it’s really not that bad, as long as the developers creating the software you use do the right thing by not trying to write or access stuff where they shouldn’t. Ensuring that your software correctly supports UAC is critical to providing your users with a great experience on Vista.

On 32-bit versions of Windows Vista, a system called virtualization is used to improve compatibility with apps that still do the wrong thing in terms of irresponsibly writing data to protected locations, such as the Windows directory, Program Files, or HKLM. Basically, virtualization silently redirects non-privileged writes to these locations to a location where the user who launched the process can write. You can see right now which of your applications are virtualized by opening Task Manager and choosing Select Columns from the View menu.

Virtualization is something that your software is automatically opted into on 32-bit Windows. To specifically exclude your application from being virtualized, you must include an XML manifest with your app that specifies its UAC runlevel. A runlevel consists of one of three values:

• asInvoker – Run this process with the account and privileges of the person who launched it. You should default to choosing asInvoker, and only deviate if absolutely necessary.
• highestAvailable – This one is kind of an odd duck. Basically, it says that this application should be run with the highest privileges available to the account that launched it. For example, let’s say you’re logged into your computer with an account that is a member of the Backup Operators group. Windows sees this, and requests that you authorize this application to be run at that privilege level. From the Ux perspective: if this app is launched by a standard user, it just runs. If the app is launched by anyone else (Administrator, Backup Operator, etc.) they will get a UAC prompt. Regedit uses highestAvailable. You shouldn’t. End of story.
• requireAdministrator – Just like it sounds. This app is only available to people with administrative privileges. If your account has admin privs, you’re presented with a UAC consent dialog. If you don’t, then you get a UAC credentials dialog. The UAC credentials dialog requires an administrator to come along and enter their password “over the shoulder” of the person operating the computer. Here’s the funky bit: if an administrator does launch a process that is marked as requireAdministrator, that process runs as that administrator. If an application has the ability to launch other apps from within it, those will also be run with the administrator’s privilege set (likes beget likes is the rule of thumb). Be cautious, in any case. Some apps, like MMC, require administrative privileges to launch.

Whew, that was a mouthful. I still have a lot more to talk about: creating your manifest, specifying the runlevel, embedding it into your managed application with VS 2005. I’ll be along with a follow-up soon to answer all of these questions.

In the mean time, I highly recommend reading the old posts on the UAC team’s blog. They have a wealth of information available, there.

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Why you must factor out your apps’ admin components
• Meet UAC – Embedding Manifests in Managed Apps
• Meet UAC – Creating a UAC Manifest
• An even better screen capture tool

A while back I wrote about a new snipping tool included with Windows Vista. I just found an even cooler one just now that leverages Vista’s DWM to create perfect screen captures on Vista every time, as seen in the screenshot below:

You’ll notice that the background doesn’t bleed through, nor do you get ugly rectangular black borders around your screenshot. Many thanks to Kenny Kerr for providing such an awesome, useful utility!

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Why you must factor out your apps’ admin components
• Meet UAC – Embedding Manifests in Managed Apps
• Meet UAC – Creating a UAC Manifest
• Meet UAC – Understanding Virtualization and Run Levels

If you’re anything like me, you probably spend a good chunk of time using Print Screen or Alt+PrtSc in conjunction with MSPaint or Photoshop. Microsoft has included a cool, little utility in Windows Vista that will make your life so much easier.

I found Snipping Tool (catchy name, huh?) in Windows Vista Ultimate yesterday. It may well be in other SKUs as well, but I have no easy way to check. Go to the Start menu and type in snippingtool. You’ll be rewarded with the following window:

From here, you can do free-form selections, rectangular selections, hwnd-based window selections and full screen selections. This certainly won’t replace the commercial screen capture utilities out there, but it’s a nice addition to Windows.

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Why you must factor out your apps’ admin components
• Meet UAC – Embedding Manifests in Managed Apps
• Meet UAC – Creating a UAC Manifest
• Meet UAC – Understanding Virtualization and Run Levels

One of the big, new features in Windows Vista is User Account Control, which is designed to…

…reduce the exposure and attack surface of the operating system by requiring that all users run in standard user mode. This limitation minimizes the ability for users to make changes that could destabilize their computers or inadvertently expose the network to viruses through undetected malware that has infected their computer.

There is a good deal of useful, interesting information available on the topic from the UAC team’s blog, which I highly recommend reading through. For today, though, I want to dig into one topic for which I haven’t seen any coverage yet. If you’re writing a managed application, it’s not immediately obvious how to add a shield to buttons in your application without manually copying a bitmap resource into your project…which kind of sucks. So, without further ado, here’s one way (presented “as-is with no warranties expressed or implied”) to handle this operation:


using System;
using System.Collections.Generic;
using System.Runtime.InteropServices;
using System.Text;namespace SecurityButtonTest
{
  public class ShieldButton : System.Windows.Forms.Button
  {
    public ShieldButton() : base()
    {
      this.FlatStyle = System.Windows.Forms.FlatStyle.System;
      this.ShowShield = true;
    }

And here is the ShieldButton control in action:

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Why you must factor out your apps’ admin components
• Meet UAC – Embedding Manifests in Managed Apps
• Meet UAC – Creating a UAC Manifest
• Meet UAC – Understanding Virtualization and Run Levels

Windows Vista’s finally out the door, and with it comes a whole bevy of new stuff, like .NET FX 3.0 (with WPF/Avalon). I’ve spent the past year working on nothing but ensuring that Visual Studio works beautifully with Vista, and it’s great to see Vista finally making it out the door. I’m just finishing up an installation of Vista RTM on my laptop right now. Can’t wait!

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Why you must factor out your apps’ admin components
• Meet UAC – Embedding Manifests in Managed Apps
• Meet UAC – Creating a UAC Manifest
• Meet UAC – Understanding Virtualization and Run Levels

An article on shell revealed goes into a great deal of depth about why the Windows Vista Aero Basic theme looks the way it does.

Why does Aero have a solid 1-pixel black border inside the frame, and Aero Basic doesn’t?
Because the DWM is rendering this black border, and the DWM is absent in Aero Basic. The glass starts in the non-client area and stops after the client glass margin, and there’s intentionally no seam between the client and non-client glass areas.
This client/non-client blend illusion is kept in Aero Basic for windows without caption text, like Explorer and the Aero Wizards.

Sure, it’s not really that important in the grand scheme of things, but it’s hella interesting from the ‘low-level, nitpicky perspective.’

[This message was pre-recorded; Aaron is currently on vacation]

Possibly Related Posts:

• Windows System Colors
• Meet UAC – Why you must factor out your apps’ admin components
• Meet UAC – Embedding Manifests in Managed Apps
• Meet UAC – Creating a UAC Manifest
• Meet UAC – Understanding Virtualization and Run Levels