Why does a Win32 application need a manifest?

Recently, in the programming section, a question was asked: “Why does a Win32 application need a manifest? What does it affect? ​​” The first thing that most programmers immediately think of is design themes. But in fact, in modern Windows, a manifest is needed not only for this. I thought and wrote five key aspects that are affected by the manifest or its absence. After that, several people at once asked to arrange this post in the form of a more detailed article.

To begin with, I suggest recalling how manifestos generally appeared on Windows and how they evolved.

Manifest history

In ancient times, hell reigned in Win95 / 98, or rather DLL hell . It arose due to the fact that Windows was conceived as an ideal system. All applications in it should always be written using the latest versions of system libraries. And the different versions of the libraries themselves were supposed to be interchangeable. Reality quickly proved to everyone that for a popular OS it was a pipe dream, and hell arose. Every second application during installation overwrites the system libraries with the versions it needs. As a result, after installing application X, previously installed application Y began to fail. And after reinstalling application Y, application X started to fail. In general, users had fun.

To solve this problem, Windows XP introduced Side-by-side Assembly (SxS) technology.. Its essence was that the application could explicitly indicate which version of the library it wants to work with. This information could be indicated either in a special .manifest file, or in the application resources in the Manifest section. In XP itself, on the basis of new technology, they implemented one of the most noticeable new system features - themes.

Typical manifest:

Your application description here.


SxS was good for everyone except one - it was terribly inconvenient for a programmer. In 99% of cases, the manifest was used only to include those same themes, and for nothing more. Windows developers realized that they needed a new, easier to use way to specify supported versions of system libraries. Then they came up with a simple rule: within the same version of the system, the interface and behavior of these libraries does not change. It was only necessary in some way to learn to determine which version is required for a particular application. So in Windows 7, the Compatibility section appeared in the manifest, where you can specify with which OS versions the application was tested.
Also in the manifest, starting with Windows Vista, a few more sections appeared, about all of them below.

Manifest functions

  1. Activation of themes ( Visual Styles )
    This technology appeared in XP and is completely based on SxS. It works simply: you request the sixth version from the ComCtl32.dll system, and voila - all standard controls are drawn according to the theme activated in the system. If you don’t mention ComCtl32.dll in the manifest, or the manifest will be absent in the application at all, then the system will load ComCtl32.dll of the fifth version by default, which draws controls in the Win95 style. In addition to supporting themes, the sixth version of ComCtl32.dll contains some functionality that is not present in the fifth version. Therefore, if you disable themes, some applications will work and do not look like their authors intended.

    On the right is the same application without a manifest:



  2. Interaction with UAC has several aspects :
    • The requestedExecutionLevel.level key allows you to specify the level of user rights required by the application. For example, if you specify requireAdministrator, then the application will be granted administrator rights (if the user allows it).

      User permission request:



    • If the entire section for interacting with UAC is not in the manifest, file and registry virtualization will be applied to the application . If such an application tries to write something to protected folders like “Program files”, it will be redirected to the “% userprofile% \ AppData \ Local \ VirtualStore \ Program files” folder. Similarly, attempts to write to the HKEY_LOCAL_MACHINE registry key will be redirected to “HKEY_CURRENT_USER \ Software \ Classes \ VirtualStore \ MACHINE. ”Naturally, the changes made in this way will be visible only to applications running in virtualization mode.

      File system virtualization in:



    • The requestedExecutionLevel.uiAccess key allows applications running without administrator rights to interact with application windows running as administrator. This may be required on-screen keyboards, applications such as AutoIt, on-screen readers, test and debugging tools. For this key to work, the application must be signed with a Microsoft Authenticode certificate .

  3. Management DPI-scaling
    Since ancient times, the Windows interface has a zoom mechanism depending on the DPI of the monitor ( here says that it all started in XP, but it seems to me that before ). In those days, this setting was set only manually, probably due to the lack of EDID. It did not enjoy popularity, perhaps because it was hidden away, and perhaps because there were very, very few monitors with high resolution. In addition, most of the work needed to support scaling was left to the applications themselves and their authors. And programmers, as you know, people are very lazy, so a lot of software for Windows was written under the assumption that DPI is always equal to the standard value of 96. Very often there was a situation when the application used libraries supporting non-standard DPI, while the code of the application itself didn’t supported. This led to the appearance of terrible artifacts in the application interface, it cost the user to set the DPI, for example, to 120 (scaling 125%):



    Vista developers did not endure such a disgrace, and put it inDWM the ability to scale independently, and applications to lie that the DPI is still 96. Moreover, the system settings that depend on it, monitor resolution and even mouse position are also recounted. Unfortunately, Vista developers were not wizards, so DWM scaling is done using simple image stretching algorithms. And if the application interface needs to be increased, then the picture is blurred. Imagine what would happen if the developers of Photoshop could not turn it off. Nobody wanted such riots on the ship, so it was possible to indicate in the manifest that your application still knows how to properly scale its interface, and it does not need DWM help. The dpiAware parameter is responsible for this.. It should be noted here that by default DWM scaling is enabled at a magnification of 150% and higher. Apparently, Microsoft considered that when scaling 125%, artifacts as in the screenshot above are quite tolerable.

    On the left, scaling is done by DWM, and on the right is the application itself:



    In Windows 8.1, it became possible to specify different scales for different monitors if several are connected at once. Accordingly, the dpiAware key has a new value of “True / PM”. It means that the application can dynamically change the scale of its interface when moving windows from one monitor to another.

  4. Declaration of compatibility
    It works very simply: the programmer tests his application in a specific version of Windows, and if everything works as it should, he adds the GUID of this version to the manifest.

    Example:



    The most interesting question is: “What are these GUIDs influencing?” So far, the list of differences in the behavior of system libraries is small. Most interesting is the mention of RPC optimization . It turns out that applications that have declared compatibility with the seven will work faster.
    In the future, this section of the manifest will surely play a larger role than it is now. After all, Windows is full of different hacks designed to provide compatibility. And now there is an opportunity to protect normal applications from them.

    If GUIDs are completely absent in the manifest, then the rules apply to the application as compatible with Vista:



  5. Management of other functions
    Above, I described only those functions that I had to deal with personally. But this is not all that can be controlled from the manifest: msdn.microsoft.com/en-us/library/aa374191.aspx Unfortunately, the documentation for most of the other functions is not available. Perhaps it will be published later, as happened with the Magnification API .


Epilogue

With this, I, perhaps, conclude my discussion of the capabilities of the manifestos of Win32 applications. If you have any corrections or additions, please write them in the comments.

Also popular now: