I am testing my desktop application on a Windows 8 machine and I noticed there is a new column in the Task Manager details view called "Operating system context". This shows my application running under the "Windows Vista" context.
I haven't specified anything in the application manifest to force the application to run under this context in Visual Studio. The application is a Visual C++ App and was built in Visual Studio 2010.
Don't get me wrong, the application runs smoothly on Windows 8 so I am not looking to solve crashes or bugs. It just annoys me to see such a thing and would like to fix it.
So my question is how can I make my application run under the "Windows 8" context under Windows 8?
Ok, I think I've found the answer here. It says:
Applications without a Compatibility section in their manifest will receive Windows Vista behavior by default on Windows 7 and future Windows versions
So if you don't have anything in your manifest, Vista is what you get. Reading the rest of the article, it seems the best you can do is get Windows 7 rather than Windows 8, so maybe that's something specific to Store Apps?
EDIT
Ok, I finally found the entry you need for Windows 8:
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
So try putting that in the compatibility section of your manifest.
I know you're using VS2010, so this may be different, but with VS2012, I did the following:
Created a new WPF application
Right-click on project in Solution Explorer and choose Add New Item
Select Application manifest from the list
A new manifest is added to the project with compatibility settings commented out. A cut-down example with everything uncommented is as follows:
<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity version="1.0.0.0" name="MyApplication.app"/>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- A list of all Windows versions that this application is designed to work with.
Windows will automatically select the most compatible environment.-->
<!-- If your application is designed to work with Windows Vista, uncomment the following supportedOS node-->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"></supportedOS>
<!-- If your application is designed to work with Windows 7, uncomment the following supportedOS node-->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- If your application is designed to work with Windows 8, uncomment the following supportedOS node-->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"></supportedOS>
</application>
</compatibility>
</asmv1:assembly>
After rebuilding, the application shows as expected in Task Manager:
Related
I just recently found out about the need for a manifest file so that my native C++ Windows app will properly detect the Windows version. Previously my app was running under the "Operating System Context" of "Windows Vista", but thanks to the manifest file it now runs under the appropriate context for the OS it's running on.
This has sent me down a rabbit hole to learn more about what "Operating System Context" means, and why I should care about it. I've been searching for specific information on what happens under the hood and the best page I've found is:
https://msdn.microsoft.com/en-us/library/dd371711(VS.85).aspx
This page details what the Windows Vista (default) application behavior is, and what behavior you can get if you add Windows 7 support via the manifest file.
Here's my problem; I can't find any information like this for Windows 8, 2012, 10, or 2016. I read through the Windows Compatibility Cookbook, but it doesn't seem to contain the type of information available in the above link.
What terms should I be searching for? Is there an up-to-date MSDN page I can bookmark that keeps track of the "Operating System Context" differences?
Thanks!
Partial answer -
Microsoft's page on Application Manifests for Windows 8 and Server 2012 has a section on the SupportedOS element, which refers readers to the download page for the Windows 8 and Windows Server 2012 Compatibility Cookbook. This Cookbook also covers Windows 8.1 and Windows Server 2012 R2. Within this Cookbook, the heading "App (executable) manifest" discusses the the Windows features included in Windows 8 and 8.1 (as well as Windows Server 2012 & 2012 R2) which are impacted by the presence or absence of the corresponding supportedOS element. Search this doc for supportedOS, as it is mentioned in other sections as well.
As for Windows 10 (and implicitly Windows Server 2016), the latest Windows Compatibility Cookbook can be read online or downloaded from this web page. Unfortunately, this latest Cookbook does not go into the details of the specific Windows features that are new or impacted by the supportedOS element for Windows 10. But many of the various behavior changes or compatibility issues with Windows 10 are discussed here.
MS states, with regard to the Application Manifest compatibility section:
Manifestation of Change
Applications without a Compatibility section in their manifest will
receive Windows Vista behavior by default on Windows 7 and future
Windows versions. (...)
(...)
DirectDraw Lock
Windows 7: Applications manifested for Windows 7 cannot (...)
Windows Vista (default): Applications will be able to (...) Running the application turns off Desktop Window Manager.
The note is repeated for the next DirectDraw entry.
What the heck does this signify? None of or desktop (MFC) apps defines a compatibility manifest, but we've never noticed anything on "turning off" on any Desktop.
This page:
Application Manifest
Lists certain changes that occur if you specifically flag your application as compatible with Windows 7. For example:
Windows 7: To improve scalability and reduce thread counts, RPC switched to the NT thread pool (default pool). For Windows Vista, RPC used a private thread pool.
...
Windows Vista (default): For binaries compiled for Windows Vista and below, the private pool is used.
Are there any similar lists of changes that occur on newer versions of Windows (8, 8.1, 10) if you specify their supportedOS GUID in the manifest, vs not specifying one at all?
You are reading Windows 7 documentation. Try reading newer documentation, such as this one for Windows 8:
App (executable) manifest
Windows 10 has not been released yet, so MSDN does not have much in the way of Windows 10 documentation yet. However, the supportedOS guid for Windows 10 has been mentioned in some MSDN blogs, at least:
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
The following build error occurs when using .NET Micro Framework project, whether in emulator mode or not.
0x80131700
or
error MMP0000: 0x80131700
Solution by way of a drop-in file available on CodePlex (click here), also contains suggestions about frameworks.
Note: Ran into this problem during an electronics class, Googled the above answer, posting solution here for people to find, for archive and easy future reference.
Description
MetaDataProcessor fails with the above error during the build of .NET Micro Framework project on a computer where only .NET Framework 4.0 is installed (e.g. Visual Studio 2010 on a clean Windows XP Mode virtual machine). To workaround the issue copy the attached MetaDataProcessor.exe.config file into a directory where the .exe file is located (default %ProgramFiles%\Microsoft .NET Micro Framework\v4.1\Tools); alternatively install .NET Framework 2.0+ (3.5 SP1).
File Attachment - MetaDataProcessor.exe.config contents:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319"/>
</startup>
</configuration>
I have a 32-bit application I'm working on that targets .NET 3.5; VS2010 is my development tool. My app requires elevated privileges for a variety of things, so I have an application manifest for it that has the following line in it:
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
Because it's the right thing to do, I also have the lines in the manifest that indicate the application is compatible with Windows 7 and Windows Vista:
<!--The ID below indicates application support for Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
The app runs great on Windows 7 and Windows Vista. It immediately pops up the UAC prompt, it does not get affected by registry virtualization, etc. The manifest is clearly working there.
However, on 2008 R2 none of these things are true. UAC prompt does not appear. Registry virtualization happens (my primary problem). It's like it's completely ignoring my application manifest. I have no idea where to look or what to check. I have run the exact same bits on 7, Vista, and 2008 R2 and get exactly the same results every time. My 2008 R2 install is completely vanilla, as it's just a freshly-installed VM for testing.
Also, I'm fairly sure that Server 2008 is acting just like 2008 R2, basically ignoring the manifest. Any help would be greatly appreciated!
I have figured out the strange answer to my own question, though it comes in two parts:
For some reason, I'm not getting a UAC prompt in either 2008 or 2008 R2, but in both cases the app is getting properly elevated and application virtualization is disabled correctly.
My app, being 32-bit, was writing into the Wow6432Node registry key, hence I thought virtualization was happening because my changes weren't appearing. If I had tested on 2008 x86, which I had not, I would have found that the changes were appearing there but not in the x64 OSs.
Server 2008 R2 has UAC turned off by default. If it's turned off, then users from Administrators group have full admin rights and non-admin users do not have them and can't be elevated into an administrator account.