Platform-specific guides » Windows

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"
          xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:application>
  <asmv3:windowsSettings>
    <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      true/pm
    </dpiAware> <!-- legacy -->
    <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
      permonitorv2,permonitor
    </dpiAwareness> <!-- falls back to pm if pmv2 is not available -->
  </asmv3:windowsSettings>
</asmv3:application>
</assembly>

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)
if(CORRADE_TARGET_WINDOWS)
    target_sources(my-application PRIVATE WindowsHiDPI.manifest)
endif()

If you're not using CMake, here's how to do it directly with mt.exe. 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.

Unicode support

Windows is the only major platform that forces developers into UTF-16. This presents several challenges, however Magnum tries to shield users from this as much as possible:

• All Magnum APIs work with strings encoded as UTF-8, converting to UTF-16 behind the scenes if necessary
• If you use Corrade::Utility::Directory instead of C file APIs or std::fstream, all filesystem operations are Unicode-aware, working with paths encoded in UTF-8
• All Magnum APIs operating with files (Trade::AbstractImporter::openFile(), GL::Shader::addFile(), ...) use Corrade::Utility::Directory underneath, meaning you're implicitly Unicode-aware as long as you use Magnum APIs
• Corrade::Utility::Arguments expose environment variables as UTF-8, decoding them from UTF-16 input on Windows
• And finally, for Unicode-aware console I/O and command-line arguments, simply link to the Corrade::Main library, which will do needed conversion implicitly for you

Executable icon

In order to supply an icon for the executable, make an *.ico file (preferably out of multiple different sizes) and create a *.rc file referencing it. The first argument can be anything (it can be used for retrieving the icon later at runtime via Windows APIs), Windows always pick the first icon in the *.rc file for the executable.

MYICON ICON "my-icon.ico"

Then add the *.rc file to your application sources and CMake will take care of the rest:

if(CORRADE_TARGET_WINDOWS)
    target_sources(my-application PRIVATE icon.rc)
endif()

Note that this doesn't have any effect on the window icon — there it has to be specified at runtime, for example via Platform::Sdl2Application::setWindowIcon(). See also the IcoImporter plugin for importing icon files.

Colored terminal output

There's two options for colored terminal output — either using the classic Windows API (which is the default), or making use of the ANSI color escape codes compatible with all Unix systems. The former has a restriction that it works only when printing directly to the terminal (so your colors will get lost if you redirect to a file). The latter is available only in Windows 10, has to be explicitly enabled using CORRADE_UTILITY_USE_ANSI_COLORS when building Corrade and additionally requires an explicit setup during application startup. This setup is done when you link to the Corrade::Main library, see its documentation for more information.

Hiding console window

By default, CMake compiles GUI applications with a potentially unwanted console window lurking in the background. This can be fixed by creating your executable with add_executable(... WIN32 ...) and linking to the Corrade::Main library. See its documentation for more information.

Vulkan on Windows

OpenGL on Windows

Using Clang-CL

As an alternative to MSVC it's possible to use Clang-CL. Compared to MinGW it is fully ABI-compatible with MSVC, sharing the same STL implementation, and thus you can freely mix and match libraries built by either of them.

If you already have MSVC 2019, clang-cl is available as an optional install component. Configuring your project to be used with e.g. Ninja could then look similarly to the following. Custom clang-cl installations work as well of course, adapt the paths as necessary:

C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Auxiliary/Build/vcvarsall.bat" x64

cmake .. ^
    -DCMAKE_C_COMPILER="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/Llvm/bin/clang-cl.exe" ^
    -DCMAKE_CXX_COMPILER="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/Llvm/bin/clang-cl.exe" ^
    -DCMAKE_LINKER="C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/Llvm/bin/lld-link.exe" ^
    -DCMAKE_CXX_FLAGS="-m64" ^
    -G Ninja

CMake is currently having issues propagating correct bitness to clang-cl when using Ninja, which means you may need to explicitly pass either -m64 or -m32 to Clang. In the above case, vcvarsall.bat was called with the x64 parameter but the Clang bundled with Visual Studio is 32-bit and thus defaults to 32-bit builds. Additionally, if your code needs to use exceptions (Magnum itself doesn't, but Corrade::TestSuite relies on them to report failures in tests), you may need to explicitly pass /EHs via CMAKE_CXX_FLAGS as exceptions are currently disabled by default.

While Magnum itself is tested to work with this compiler, be prepared that you might run into exciting new issues that aren't present with MSVC, MinGW or Clang alone. In dire situations, you can use CORRADE_TARGET_CLANG_CL to add compiler-specific workarounds.

More information on the Microsoft C++ Team Blog.

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 OpenGL ES translation layer 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="http://schemas.microsoft.com/appx/2010/manifest"
         xmlns:m2="http://schemas.microsoft.com/appx/2013/manifest">
  <Identity Name="MyApplication" Publisher="CN=A Publisher" Version="1.1.0.0" />
  <Properties>
    <DisplayName>My Application</DisplayName>
    <PublisherDisplayName>A Publisher</PublisherDisplayName>
    <Logo>assets/logo-store.png</Logo>
  </Properties>
  <Resources>
    <Resource Language="x-generate" />
  </Resources>
  <Applications>
    <Application Id="App" Executable="$targetnametoken$.exe"
                 EntryPoint="MyApplication.App">
      <m2:VisualElements
        DisplayName="Magnum Windows Store Application"
        Description="My Application"
        BackgroundColor="#202020"
        ForegroundText="light"
        Square150x150Logo="assets/logo.png"
        Square30x30Logo="assets/logo-small.png">
        <m2:SplashScreen Image="assets/splash.png" />
      </m2:VisualElements>
    </Application>
  </Applications>
</Package>

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:

if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" AND NOT
   CMAKE_CXX_COMPILER_VERSION VERSION_LESS "19.10")
    # Code requiring MSVC 2017
endif()

Troubleshooting

src\Corrade/Utility/Debug.h : warning C4819: The file contains a character that cannot be represented in the current code page (949). Save the file in Unicode format to prevent data loss

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /utf-8")

add_executable(MyApplication ...)
set_property(DIRECTORY ${PROJECT_SOURCE_DIR} PROPERTY VS_STARTUP_PROJECT MyApplication)

GL::Shader::compile(): compilation of vertex shader 1 failed with the following message:
ERROR:2:1: `` : syntax error: illegal extended ASCII character (0xef)
ERROR:2:1: `` : syntax error: illegal extended ASCII character (0xbb)
ERROR:2:1: `` : syntax error: illegal extended ASCII character (0xbf)

C:/msys64/mingw64/lib/libMagnumGlfwApplication-d.a(GlfwApplication.cpp.obj): duplicate section ".rdata$_ZTSN6Magnum8Platform15GlfwApplicationE[_ZTSN6Magnum8Platform15GlfwApplicationE]" has different size.

lld-link: error: duplicate symbol: typeinfo name for Magnum::Platform::GlfwApplication
>>> defined at CMakeFiles/appExec.dir/src/main.cpp.obj
>>> defined at libMagnumGlfwApplication-d.a(GlfwApplication.cpp.obj)