In the July 11, 2002, Dot-Tech Perspectives, "Assemblies in .NET Applications" (see the URL below), I discussed how applications based on the .NET architecture use assemblies and manifests to run. Assemblies, as you'll recall, are the executable code for these applications, whereas manifests contain settings that control the application's presentation: security settings, versioning information, and the like. However, one thing I didn't mention is that the manifest can also control the way an application looks on the screen.
http://www.winnetmag.com/articles/index.cfm?articleid=25888
If you've used any Windows OS for longer than 5 minutes and have an ounce of curiosity, you might wonder how an application's manifest affects its appearance. After all, if you're running applications on Windows XP, you can change everything—even the appearance of the control buttons in application windows—from the Control Panel Display applet. However, what you might not have noticed is that not all applications respond in the same way to the settings that you choose. When you turn on the XP theme, for example, some applications will use the bright red and blue controls that characterize XP (unless you're a curmudgeon as I am and switched to Windows Classic View when you first started your XP machine). Some applications, however, won't use these controls. They'll use some of the color and appearance settings that you can control from the Display applet, but not all of them, even if those settings are specified in the theme you've loaded.
Why don't themes apply uniformly to all applications? The answer lies with the visual styles, not with the theme. Themes, a set of configuration settings contained in a .theme file that an application's Independent Software Vendor (ISV) provides, have been around since the Microsoft Plus! Pack for Windows 95. Themes include not only visual settings but also sounds. Visual styles, which Microsoft introduced with XP, have a subtler but more encompassing effect by determining the controls available to Windows applications. All applications running on XP have a nonclient area, which includes the window frame and scroll bars. The rest of the application's graphical interface, including Windows controls, is its client area. The graphical display engine applies a visual style to the nonclient area by default, but not to the client area. So, an application's title bar changes with the theme, but the control buttons for the application's window (e.g., Close or Minimize) might not change if the application isn't configured to use visual styles. Visual styles can affect an application's client area only if that application refers to the library of controls in ComCtl32.dll 6.0 or later, which is available only with XP and later OSs. Otherwise, the application uses the earlier version of the control library that's available to earlier Windows versions.
So, how do you make ComCtl32.dll available to an application? You—or, more precisely, an application's developer—set this mechanism in one way for applications that can use third-party extensions (such as plugins) and in another way for those that can't. However, regardless of the application's structure, the purpose of an application's manifest is to describe the components that are required to run the application, including any dependencies. In this case, the dependencies will include the library of visual styles. The application's type doesn't affect the structure of the manifest—the type just affects the code that the application needs to identify the manifest.
