Some applications don't scale up well on high resolution screens. One proposed solution to this on Windows (for example, for Adobe CS6 applciations) is to "Enable Windows to prioritise external manifests" with a registry change, then create a manifest for the application that tells Windows to apply its default UI scaling.
I'm a firm believer in not making system-level changes like registry changes without first understanding what they mean. I've tried researching enabling Windows to prioritise external manifests to learn more, but all I find is examples of this hack being used to make various stubborn applications scale on high-resolution screens.
I believe that this registry change essentially enables a certain type of config file (.manifest) to be read when applications are launched (?). I'd like to understand what the implications of enabling them are. The closest I've found to an answer in my research is this promising but much-less-than-authoritative comment on Adobe forums. I'd essentially like to know if this is true or not:
As far as other implications to the registry change, as long as you
don't have other .manifest files along with your executables that are
in conflict with those within the executables themselves – which
should be very uncommon – it seems to be a change with little
downside.
In particular (in order):
- Is it true that this registry change will not affect any system behaviour except for cases where I manually create a manifest file for an application? This article makes me think this is the case. Or does it have other implications (for example, maybe checking for manifests is common enough to slow down certain system processes?)
- Clearly there's the risk of a poorly configured manifest breaking one application. Are there further risks, such as security concerns (malware creating manifests?) which an end user must be aware of before enabling them?
- This MSDN article sounds like it's saying manifests exist to allow application-specific registry overrides. Is that a correct interpretation, in lay terms?
If Windows version is relevant, I'm most interested in Windows 8.1 and Windows 7 (in that order).
Best Answer
Manifest files contain settings for Windows about how to handle the module at startup. As you already figured out, it can be embedded in the module itself or stay outside as *.manifest file. Normally the embedded one takes priority so that the external one won't count if the module has an embedded one already. The registry setting changes this behaviour to count external ones first.
I don't believe that priortising external manifests will slow down the system performance. Most processes will run as normal after checking that there is no external one. Even if there are, manifest files are small xml files so that they won't take much time to process.
There WERE some cases just like you said. Example: http://www.symantec.com/security_response/vulnerability.jsp?bid=21550 So for security concerns, I think it's safer not to priortise external manifests at all, even if there is no ongoing issues on Windows.
The article said that the same goal was achieved with Registry in the past. Now it's different because modules can have internal manifests. In addition, manifests cannot be used as generic registry virtualisation.
Actually, there is a way to modify "internal" manifest. This article illustrates how to do that at your own risk. http://csi-windows.com/toolkit/240-great-pe-editor-for-internal-manifests
I tested this trick with an app developed by myself and worked fine. Note that you should start with "developer mode" to save the exe, need to remove the existing manifest and then re-add a new manifest. Not to mention, don't forget to backup the original.
If this trick works for you, that will be much better than changing the priority. However - commercial applications may not work as this way breaks digital signatures and may conflicts on protections, if any. If it does not work, the best way should be to ask the original developer to change the internal manifests for newer Windows versions or to find newer versions of software which may have fixed the original issue.