Since Windows 8.1 doesn't allow system-wide "Windows XP style" high DPI support, how can I make the Microsoft Management Console apps (mmc.exe) high-DPI aware? There is no "Troubleshoot compatibility" context menu item for it.
Since Windows 8.1 doesn't allow system-wide "Windows XP style" high DPI support, how can I make the Microsoft Management Console apps (mmc.exe) high-DPI aware? There is no "Troubleshoot compatibility" context menu item for it.
The Compatibility tab is hidden for system files, so to replicate the functionality of the "Disable display scaling on high DPI settings" checkbox you would add the following to the registry:
This has the added benefit of making all MMC snap-ins like Group Policy Editor also use native scaling instead of the blurry rasterized version.
You can save that as .reg file and import it, or use paste the following command into the Run dialog:
reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /v "C:\Windows\System32\mmc.exe" /f /t REG_SZ /d "~ HIGHDPIAWARE"
If you find yourself using that workaround often you may want to add it to the right click context menu for .exe files. You can also add it to .msi files since the Compatibility tab is missing for those files as well:
Since the "Run as Administrator" and "Disable DPI scaling" settings are stored together, invoking that command on a file already set to run as admin will clear that flag and set the DPI scaling flag instead. That only affects files you've manually checked the box for, not those with the correct requestedExecutionLevel in their manifest.
Just for reference, when both are checked the string is "~ RUNASADMIN HIGHDPIAWARE" but I wouldn't put that into a context menu option since it's already available for one-time use on the context menu and it's not a good idea to make the administrator token necessary so easily.
If you want the option to disable DPI scaling for executable and installer files in a specific folder you can use the following .reg import:
Using that option on a root-level folder like Program Files is a bad idea because you'll create hundreds of registry entries. But for some cases it's essential, particularly for Process Explorer and the rest of the Sysinternals utilities, or the Nirsoft utilities, all of which run great with DPI scaling disabled but don't have the option explicitly specified in their manifests.
The last batch of code uses the internal start command to get the command prompt window out of the way as quickly as possible and keep it minimized as it parses the contents of the folder. The @ symbol is used to prevent echoing back the command in the output, and nul redirection is used to hide the output "The operation completed successfully." for each entry since it never changes.
If you happen to have the excellent nircmd tool you can hide the brief flash of the command prompt window entirely:
If nircmd.exe is not in your path you can either add its location above or add its folder to your path in the System Environment Variables dialog. To bring up that window you can use the command
rundll32 sysdm.cpl,EditEnvironmentVariables
The argument could be made that it would be more elegant to add the registry keys by creating a .reg file at runtime and importing it silently with the undocumented
reg import /s
option. But in my experience, writing any files at runtime raises all sorts of alarms with security products like COMODO Internet Securita, its equivalent versions from Panda, Norton, etc. and anything based on a HIPS model. I don't see a need to do that when the above works just fine, especially if you're using this on multiple computers or sharing it and don't want to create a false alarm for someone else.However if you're already using nircmd, it would make sense to use its
regsetval
command instead ofreg add
for the .exe and .msi shell extensions. The folder option would still need to iterate over the directory listing to add each entry so it won't work for those. PowerShell and VBScript are options but their availability depends on the version of Windows and a host of other variables. From a security standpoint, VBScript has a reputation as an exploit vector particularly when downloaded from the internet or shared on a network, and PS1 scripts won't run at all without explicitly setting PowerShell's execution policy to allow remote signed scripts.Let me know if you notice anything odd when using that code as it's still a work in progress. That being said it should make configuring Windows 8.1's DPI settings much easier.
On Windows 10 you can achieve the same effect by doing:
1: Depending which build you have (to find it, hit Windows+R, type "winver", press Enter) either:
Enter the scaling level manually, even if it's one that's available in the dropdown. You'll know you've done it correctly if you're prompted to sign out for the setting to take effect.
2: Save the following to a .reg file on your desktop and double click it to add the contents to your registry:
3: Save the following file as
c:\windows\system32\mmc.exe.manifest
4: Open any MMC windows (Services, Device Manager, etc.) and they will now be bigger and sharper