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.
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.
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}"/>
I have an application written in Delphi XE5 that targets mainly Windows 7, but also Windows 8 and 8.1. It does require that the user has administrator rights.
It works fine on nearly all of my user's computers, but on a few it only works when selecting compatibility mode for Windows 7 in Windows 7.
The error presents itself directly when starting up the application as a windows dialog stating that:
[NameOfMyProgram] has stopped working.
Problem Event Name: APPCRASH
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7601.18839
Exception code: 0eedfade
My question is the following: Why is there a compatibility mode for Windows 7 on Windows 7, and what does it mean to use this mode that could affect my application in the way described above?
I have not been able to find any documentation about this specific compatibility mode.
When you're running Windows 7, the "Windows 7" option appears on the compatibility list when you have Windows 7 SP1 installed. If you don't have SP1 installed, then that option will not appear on the list.
The option makes Windows appear to the program as though it does not have the service pack installed, which may affect the behavior of certain API functions.
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.
We have a Server/Client cybercafe management application which used to work fine on Windows XP and Vista but now fails to run on Windows 7.
The Client was supposed to get 'Locked' on Client PCs of the Cybercafe, meaning it replaced Windows Explorer by changing the registry key
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell"
to the path to the Client application's EXE file.
This worked just fine on Windows XP and now on Windows 7, neither Explorer.exe nor Client.exe are run and just a blank, blue screen is shown.
We thought it might have something to do with UAC so we disabled it, with no luck.
When we managed to start Explorer.exe on the Client PC through another computer, and used the Explorer window to open Client.exe, the Client started just fine.
(Note that running Explorer.exe didn't start Windows Shell and just opened an Explorer window, since the registry key was pointing to Client.exe and Shell doesn't start unless the registry key points to Explorer.exe)
Ideas, everyone? Any big difference between XP and 7 in this area?
Fixed it. Hope someone finds this useful:
A 32bit app running on 64bit Windows can't access certain areas of Windows Registry. The request to access that section is routed to some other key. That's why our application couldn't lock on Windows 7 (It was a 64bit Windows).
Changing Client.exe from x86 to "Any CPU" in Visual Studio fixed the problem.
However, it was still necessary to disable UAC to allow the Client to work.