Platform-specific guides » Windows

Tips and tricks for Windows platforms.

HiDPI support

Windows supports two approaches to advertising HiDPI support. The recommended way is via a so-called manifest file added to an executable, but it's also possible to it programatically through the SetProcessDpiAwareness() family of APIs. Note there's three different levels of DPI awareness setup for Windows Vista and newer, Windows 8.1 and newer and Windows 10, and for best support may want to support all three.

When using MSVC, the manifest file can be added directly via CMake. Advertising application-wide per-monitor support can look like in the following snippet, together with fallbacks for older systems:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
    <dpiAware xmlns="">
    </dpiAware> <!-- legacy -->
    <dpiAwareness xmlns="">
    </dpiAwareness> <!-- falls back to pm if pmv2 is not available -->

Then, the manifest file can be supplied directly in the sources list for add_executable(), via a variable, or you can add it conditionally later using target_sources(). For example:

add_executable(my-application MyApplication.cpp)
    target_sources(my-application PRIVATE WindowsHiDPI.manifest)

Some toolkits (such as GLFW in Platform::GlfwApplication) are advertising HiDPI support implicitly programatically. In that case the manifest file doesn't need to be supplied, but there may be some disadvantages compared to supplying the manifest. See the MSDN documentation about DPI awareness for more information.

Windows RT

Windows RT is a restricted subset of Windows API, used for UWP / "Metro" / Windows Store apps. The major difference is lack of access to APIs that are common in Win32 world, such as memory-mapped files, DLLs or environment variables.

In particular, Windows RT doesn't provide a direct access to OpenGL, the only possibility to use it is through ANGLE. See Building for ANGLE on Windows and ANGLE for more information.

For Windows RT you need to provide logo images and splash screen, all referenced from the *.appxmanifest file. The file is slightly different for different targets, template for Windows Store and MSVC 2013 is below, others are in the SDL2 bootstrap application.

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="" xmlns:m2="">
  <Identity Name="MyApplication" Publisher="CN=A Publisher" Version="" />
    <DisplayName>My Application</DisplayName>
    <PublisherDisplayName>A Publisher</PublisherDisplayName>
    <Resource Language="x-generate" />
    <Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="MyApplication.App">
        DisplayName="Magnum Windows Store Application"
        Description="My Application"
        <m2:SplashScreen Image="assets/splash.png" />

The assets are referenced also from the main CMakeLists.txt file. You have to mark all non-source files (except for the *.pfx key) with VS_DEPLOYMENT_CONTENT property and optionally set their location with VS_DEPLOYMENT_LOCATION. If you are using *.resw files, these need to have the VS_TOOL_OVERRIDE property set to PRIResource.

MSVC version mapping

MSVC and Visual Studio use three, er, four different versioning schemes. CMake exposes compiler version equivalent to the _MSC_VER macro, see this handy Wikipedia table for mapping to Visual Studio versions. For example, a check for MSVC 2017 would look like this:

    # Code requiring MSVC 2017