/*
    This file is part of Magnum.

    Copyright © 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019
              Vladimír Vondruš <mosra@centrum.cz>

    Permission is hereby granted, free of charge, to any person obtaining a
    copy of this software and associated documentation files (the "Software"),
    to deal in the Software without restriction, including without limitation
    the rights to use, copy, modify, merge, publish, distribute, sublicense,
    and/or sell copies of the Software, and to permit persons to whom the
    Software is furnished to do so, subject to the following conditions:

    The above copyright notice and this permission notice shall be included
    in all copies or substantial portions of the Software.

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
    DEALINGS IN THE SOFTWARE.
*/

namespace Magnum {

/** @page platforms-windows Windows
@brief Tips and tricks for Windows platforms

@tableofcontents
@m_keyword{ANGLE OpenGL compatibility layer,,}
@m_footernavigation

@section platforms-windows-hidpi 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:

@code{.xml}
<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>
@endcode

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

@code{.cmake}
add_executable(my-application MyApplication.cpp)
if(CORRADE_TARGET_WINDOWS)
    target_sources(my-application PRIVATE WindowsHiDPI.manifest)
endif()
@endcode

Some toolkits (such as GLFW in @ref Platform-GlfwApplication-dpi "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](https://msdn.microsoft.com/en-us/library/windows/desktop/mt846517(v=vs.85).aspx)
for more information.

@m_class{m-block m-info}

@par Supplying manifests with MinGW
    With MinGw the operation is slightly more involved, as you need to pass it
    through a `*.rc` file. A downside is that MinGW is not able to merge
    information from multiple manifests like the MSVC toolchain can.
@par
    @code{.txt}
    1 RT_MANIFEST "WindowsHiDPI.manifest"
    @endcode
@par
    Then you add the `*.rc` file using @cb{.cmake} target_sources @ce like
    above. Here's a CMake snippet that will work for both:
@par
    @code{.cmake}
    add_executable(my-application MyApplication.cpp)
    if(CORRADE_TARGET_WINDOWS)
        if(MSVC)
            target_sources(my-application PRIVATE WindowsHiDPI.manifest)
        elif(MINGW)
            target_sources(my-application PRIVATE WindowsHiDPI.rc)
        endif()
    endif()
    @endcode

@section platforms-windows-rt 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 @ref building-windows-angle and
@ref platforms-gl-es-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 @ref Platform-Sdl2Application-bootstrap-winrt "SDL2 bootstrap application".

@code{.xml}
<?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>
@endcode

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`.

@section platforms-windows-msvc-version-mapping 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](https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Internal_version_numbering)
for mapping to Visual Studio versions. For example, a check for MSVC 2017
would look like this:

@code{.cmake}
if(CMAKE_CXX_COMPILER_ID STREQUAL "MSVC" AND NOT
   CMAKE_CXX_COMPILER_VERSION VERSION_LESS "19.10")
    # Code requiring MSVC 2017
endif()
@endcode

@note CMake supports `VERSION_GREATER_EQUAL` in the @cb{.cmake} if() @ce
    statement only [since version 3.7](https://cmake.org/cmake/help/latest/release/3.7.html#commands),
    use a negated `VERSION_LESS` like above in older versions.

@see @ref platforms-macos-clang-version-mapping

@todoc DLL paths
@todoc vcpkg
@todoc desktop ES
@todoc mingw, clang, clang/c2...
@todoc "unicode"
@todoc colored console output
@todoc lcov on mingw (ugh)
*/

}