NOT for use with Visual Studio anything.
NOT for use with .NET anything.
It works for ME.
I am using some intense game graphics and process logic. I have found that Microsoft has been trying (for years) to lock programmers (outside of Visual Studio and .net) from using straight C++ as written by Stroustrup. I have been allowed to find another way to remove more of Microsoft's attempted blocks from my using C++.
For years, I used Visual Studio. I programmed in it for a long time. Now I am working toward quitting using Visual Studio and .net completely.
You should do the same.
Change the extension to the attached file from ".txt" to ".xml" .
Enjoy.
Expand|Select|Wrap|Line Numbers
- <!-- manifest.xml-->
- <!--
- The Manifest.xml file has no effect for Windows systems prior to XP.
- This "Application Manifest" is allowed to be included because
- Applications without a Compatibility section in their manifest will receive Windows Vista
- behavior by default on Windows 7 and future Windows versions.
- Note that Windows XP and Windows Vista ignore this manifest section and it has no impact on them.
- DirectDraw Bit Block Transfer (Blt) to Primary without Clipping Window
- Windows 7 64 bit (and above?):
- Applications manifested for Windows 7 are prevented from performing
- Blt's to the primary Desktop video buffer without a clipping window.
- Doing so will result in an error and the Blt area will not be rendered.
- Windows enforces this behavior even if you do not turn on Desktop Window Manager Composition.
- Windows 7 compatible applications must Blt to a clipping window.
- Windows Vista (default) (and XP ?):
- Applications must be able to Blt to the primary Desktop video buffer without a clipping
- window as legacy applications depend on this behavior.
- Running this application turns off the Desktop Windows Manager (for this program).
- The following works:
- <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
- <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
- <dependency>
- <dependentAssembly>
- <assemblyIdentity
- type="win32"
- name="Microsoft.Windows.Common-Controls"
- version="6.0.0.0"
- processorArchitecture="x86"
- publicKeyToken="6595b64144ccf1df"
- language="*"/>
- </dependentAssembly>
- </dependency>
- <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
- <security>
- <requestedPrivileges>
- <requestedExecutionLevel
- level="asInvoker"
- uiAccess="false"/>
- </requestedPrivileges>
- </security>
- </trustInfo>
- </assembly>
- -->
- <!-- Below is a simple example of an XP theme manifest for 32-bit applications:
- with compatibility stuff-->
- <?xml
- version="1.0"
- encoding="UTF-8"
- standalone="yes"
- ?>
- <assembly
- xmlns="urn:schemas-microsoft-com:asm.v1"
- manifestVersion="1.0"
- xmlns:asmv3=”urn:schemas-microsoft-com:asm.v3″>
- <assemblyIdentity
- name="SingleBallBouncing"
- version="1.0.0.0"
- processorArchitecture="X86"
- type="win32"
- />
- <!--The following will supposedly not have any impact when run on previous operating systems-->
- <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
- <application>
- <!-- Windows 10 -->
- <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
- <!-- Windows 8.1 -->
- <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
- <!-- Windows 8 -->
- <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
- <!-- Windows 7 -->
- <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
- <!-- Windows Vista -->
- <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
- </compatibility>
- <description>
- Description of your application
- </description>
- <!-- Enable themes for Windows common controls and dialogs (Windows XP and later) -->
- <!-- On Windows XP sp 2 this exe compiles and runs with and WITHOUT the following dependency stuff. -->
- <dependency>
- <dependentAssembly>
- <assemblyIdentity>
- type="win32"
- name="Microsoft.Windows.Common-Controls"
- version="6.0.0.0"
- <!--The following might be necessary for 7 and later operating systems. Maybe.-->
- <!--"In order to get the common controls 6 visual styles, introduced with Windows XP"-->
- <!--This seems to also work to allow a window that was designed for a small screen
- to be stretched a lot larger.
- (REFERENCE: https://community.teamviewer.com/t5/General-Questions/Remote-display-too-small-to-see/td-p/5351 )-->
- <!--This seems to work with DPI Scaling-->
- <!--This seems to fix Remote Desktop DPI scaling with high resolution laptops
- (REFERENCE: https://vworld.nl/?p=4468 )-->
- <!--This issue is caused by lack of not being DPI scaling aware of the Remote Desktop Client. (REFERENCE: https://vworld.nl/?p=4468 )-->
- <!--How to get older programs to scale on HiDPI displays in Windows 10
- (REFERENCE: https://pocketnow.com/hidpi-scalling-in-windows-10 )-->
- publicKeyToken="6595b64144ccf1df"
- processorArchitecture="x86"
- language="*"
- />
- </dependentAssembly>
- </dependency>
- <!--Also the following for DPI Scaling (REFERENCE: https://pocketnow.com/hidpi-scaling-in-windows-10 )-->
- <!--Maybe this might be for when this executable is compiled on an amd64.
- <dependency>
- <dependentAssembly>
- <assemblyIdentity
- type=”win32″
- name=”Microsoft.VC90.CRT”
- version=”9.0.21022.8″
- processorArchitecture=”amd64″
- publicKeyToken=”1fc8b3b9a1e18e3b”>
- </assemblyIdentity>
- </dependentAssembly>
- </dependency>
- -->
- <!--Adding the trustInfo is not essential, but it has some valid use.
- This supposedly will allow the .exe to get the correct version of the Windows operating system that
- it is running on.
- Some of the following is from https://en.wikipedia.org/wiki/Manifest_file#Application_and_assembly_manifest -->
- <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
- <security>
- <requestedPrivileges>
- <!--
- asInvoker: The application will run with the same permissions as the process
- or user that started it. The application can be elevated to a higher
- permission level by selecting Run as Administrator.
- highestAvailable:
- The application will run with the highest permission level that it can.
- If the user who starts the application is a member of the Administrators group,
- then this option is the same as requireAdministrator.
- If the highest available permission level is higher than the level of
- the opening process, then the system will prompt for credentials.
- requireAdministrator:
- The application will run with administrator permissions.
- The user who starts the application must be a member of the Administrators group.
- If the opening process is not running with administrative permissions,
- then the system will prompt for credentials.
- The uiAccess is for a "Windows Store" Application which
- is specified by the uiAccess attribute.
- uiAccess
- (This applies to applications "apps" that are to be referenced by some as
- "SOLD" or "Leased" or etc. via a Microsoft web page store.)
- Standard Privilege Level (uiAccess="false"):
- Not for testing "Window's Store Applications".
- Extended Privilege Level (uiAccess="true"):
- Yes for testing "Window's Store Applications".
- Generally, a "Window's Store Application" is an "app" that is ALLOWED to be SOLD via
- a Microsoft store for use on a Microsoft Windows operating system.
- "Microsoft Store" (formerly known as "Windows Store")
- is a "digital distribution platform" owned by Microsoft,
- which is an online site that is owned by Microsoft.
- Microsoft Store is curated (edited or filtered or policed by Microsoft),
- and apps must be certified for compatibility and content.
- Microsoft takes a 30% cut of the app purchases,
- regardless of overall sales of the app.
- Reference: https://en.wikipedia.org/wiki/Microsoft_Store_%28digital%29
- -->
- <!-- level='asInvoker' = Tells the Windows operating system that this program is
- okay to run with whatever security privilege level that the user currently has
- (It does not require access to special security.). -->
- <!-- uiAccess='false' = Tells the Windows operating system that this is NOT
- a Windows Store Application.-->
- <requestedExecutionLevel level='asInvoker' uiAccess='false' />
- </requestedPrivileges>
- </security>
- </trustInfo>
- </assembly>