1<?xml version="1.0" encoding="utf-8"?> 2<asmv1:assembly manifestVersion="1.0" 3 xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1 assembly.adaptive.xsd" 4 xmlns="urn:schemas-microsoft-com:asm.v2" 5 xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" 6 xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" 7 xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" 8 xmlns:co.v1="urn:schemas-microsoft-com:clickonce.v1" 9 xmlns:co.v2="urn:schemas-microsoft-com:clickonce.v2" 10 xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 11 xmlns:xrml="urn:mpeg:mpeg21:2003:01-REL-R-NS" 12 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 13 14 <asmv1:assemblyIdentity type="win32" 15 name="codeblocks.exe" 16 version="1.0.0.1" 17 processorArchitecture="ia64" 18 publicKeyToken="0000000000000000" /> 19 20 <description xmlns="urn:schemas-microsoft-com:asm.v1">Code::Blocks application</description> 21 22 <dependency> 23 <dependentAssembly> 24 <assemblyIdentity language="*" 25 name="Microsoft.Windows.Common-Controls" 26 processorArchitecture="ia64" 27 publicKeyToken="6595b64144ccf1df" 28 type="win32" 29 version="6.0.0.0" /> 30 </dependentAssembly> 31 </dependency> 32 33 <!-- User Account Control: 34 Back when Windows Vista launched and the User Account Control feature was first introduced, 35 there was one key recommendation for game developer writing PC games: your game should not 36 require administrator rights to run, and you should add the proper embedded manifest to the 37 game EXE so Windows Vista could tell the game was updated for the new OS. With Visual Studio 38 2005, this was done by turning on some settings for the Linker (Generate Manifest File: Yes) 39 and Manifest Tool (Embed Manifest: Yes) and then setting the "Additional Manifest Files" 40 field to point to a text file that contained: 41 --> 42 <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 43 <security> 44 <requestedPrivileges> 45 <requestedExecutionLevel level="asInvoker" uiAccess="false" /> 46 </requestedPrivileges> 47 </security> 48 </trustInfo> 49 50 <!-- High-DPI 51 Windows Vista introduced another feature, High-DPI which scaled the UI by a factor of 52 125% or 150% but is off by default. With Windows 7 this was enabled by default depending 53 on the EDID native DPI information so the recommendation is for all Direct3D full-screen 54 applications to declare themselves "High-DPI Aware". This is done via another manifest 55 element. Options are: {False , True , Per-monitor , True/PM} (PM=per monitor). 56 --> 57 <asmv3:application xmlns="urn:schemas-microsoft-com:asm.v1"> 58 <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> 59 <dpiAware>False</dpiAware> 60 </asmv3:windowsSettings> 61 </asmv3:application> 62 63 <!-- Program Compatibility Assistant (PCA) 64 With Windows Vista, just having the UAC elements was enough to know that the application 65 had been updated for Windows Vista. If no UAC manifest element was found, Windows Vista 66 enabled the Program Compatibility Assistant (PCA) which could check for common failures 67 and resolve them. 68 Windows 7 needed a new way to detect if the EXE really understood Windows 7 to avoid any 69 use of the PCA, and UAC manifest elements alone wasn't sufficient. The solution was more 70 manifest elements! You again add an "Additional Manifest Files" file reference to a text 71 file containing: 72 --> 73 <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 74 <application> 75 <!--The ID's below indicates application support for specific Windows versions --> 76 <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}" /><!-- Windows Vista/Server 2008 --> 77 <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}" /><!-- Windows 7/Server 2008 R2 --> 78 <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}" /><!-- Windows 8/Server 2012 --> 79 <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}" /><!-- Windows 8/Blue/Server 2012 R2 --> 80 <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" /><!-- Windows 10 / Threshold --> 81 </application> 82 </compatibility> 83 84</asmv1:assembly> 85