Legacy non-dpi-aware application resolution scaling

I did a little experimentation with some code I had around from another project a while back that directly accesses the Windows API for displays (EnumDisplaySettings and ChangeDisplaySettingsEx)

It was pretty easy to adapt it to set a resolution on a specific display from the command line. It works like a charm. I think MS just removed the setting from the dialog, but not from the underlying API and/or driver.

If anyone else needs a Windows command line tool for setting display resolution, I have posted it on my command line utilities page here.

Usage: DisplayResSet.exe /H -    This help
       DisplayResSet.exe with no parameters - list current display devices and supported modes
       DisplayResSet.exe /Dn /Xxxx /Yyyy - set resolution of device n to xxx by yyy pixels
       DisplayResSet.exe /Q - Quiet mode - suppress console output

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:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Windows\\System32\\mmc.exe"="~ HIGHDPIAWARE"

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:

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\exefile\shell\disabledpi]

[HKEY_CLASSES_ROOT\exefile\shell\disabledpi]
@="Disable DP&I Scaling"

[HKEY_CLASSES_ROOT\exefile\shell\disabledpi\command]
@="cmd /c @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%1\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\">nul"
"IsolatedCommand"="cmd /c @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%1\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\">nul"

[-HKEY_CLASSES_ROOT\Msi.Package\shell\disabledpi]

[HKEY_CLASSES_ROOT\Msi.Package\shell\disabledpi]
@="Disable DP&I Scaling"

[HKEY_CLASSES_ROOT\Msi.Package\shell\disabledpi\command]
@="cmd /c @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%1\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\">nul"
"IsolatedCommand"="cmd /c @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%1\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\">nul"

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:

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\Directory\shell\disabledpi]

[HKEY_CLASSES_ROOT\Directory\shell\disabledpi]
@="Disable DP&I Scaling"

[HKEY_CLASSES_ROOT\Directory\shell\disabledpi\command]
@="cmd /c @start /min cmd /c for /f \"usebackq delims=\" %%i in (`dir /b /s \"%1\\*.exe\" \"%1\\*.msi\"`) do @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%%i\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\""
"IsolatedCommand"="cmd /c @start /min cmd /c for /f \"usebackq delims=\" %%i in (`dir /b /s \"%1\\*.exe\" \"%1\\*.msi\"`) do @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%%i\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\""

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:

Windows Registry Editor Version 5.00

[-HKEY_CLASSES_ROOT\exefile\shell\disabledpi]

[HKEY_CLASSES_ROOT\exefile\shell\disabledpi]
@="Disable DP&I scaling"

[HKEY_CLASSES_ROOT\exefile\shell\disabledpi\command]
@="nircmd.exe execmd reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%1\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\""
"IsolatedCommand"="nircmd.exe execmd reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%1\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\""

[-HKEY_CLASSES_ROOT\Msi.Package\shell\disabledpi]

[HKEY_CLASSES_ROOT\Msi.Package\shell\disabledpi]
@="Disable DP&I scaling"

[HKEY_CLASSES_ROOT\Msi.Package\shell\disabledpi\command]
@="nircmd.exe execmd reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%1\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\""
"IsolatedCommand"="nircmd.exe execmd @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%1\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\""

[-HKEY_CLASSES_ROOT\Directory\shell\disabledpi]

[HKEY_CLASSES_ROOT\Directory\shell\disabledpi]
@="Disable DP&I scaling"

[HKEY_CLASSES_ROOT\Directory\shell\disabledpi\command]
@="nircmd.exe execmd for /f \"usebackq delims=\" %%i in (`dir /b /s \"%1\\*.exe\" \"%1\\*.msi\"`) do @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%%i\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\""
"IsolatedCommand"="nircmd.exe execmd for /f \"usebackq delims=\" %%i in (`dir /b /s \"%1\\*.exe\" \"%1\\*.msi\"`) do @reg add \"HKCU\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers\" /v \"%%i\" /f /t REG_SZ /d \"~ HIGHDPIAWARE\""

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 of reg 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.