Member Avatar for Robert_66

Hi, I'm trying to make a program that sets up the hight dpi compatibility mode programatically on Windows 10, so that I don't have to set up manually the properties of every legacy *.exe program I use, there are hundreds.

When you set up that on a local drive, Windows creates a registry entry such as:

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] "C:\Program Files (x86)\Iperius Backup\Iperius.exe"="~ HIGHDPIAWARE"

But if the file resides on a mounted share, the value will be something like:

SIGN.MEDIA=13E07B7 Somedir\test\test.exe

The SIGN.MEDIA is different for every directory on the same share.

Is there a C/C++ API that would allow to compute this SIGN.MEDIA value?

  • 2 Contributors
  • 1 Reply
  • 1K Views
  • 7 Minutes Discussion Span
  • Latest Post Latest Post by rproffitt

Dani AI

Generated

If an exe is not on a fixed local path (removable media, mapped share, sometimes UNC), Windows writes the compatibility setting under Layers using a tokenized value name like:
SIGN.MEDIA=<hex> <relative-path-from-media-root>. Those entries also show up when the Program Compatibility Assistant (PCA) records activity in its Store/Persisted keys. The intent is to make the rule survive changing drive letters. You can confirm the key locations and behavior in practice by inspecting Layers and PCA’s Persisted entries. (nirsoft.net)

Re your specific question: there is no public C/C++ API or Microsoft-documented algorithm for computing the SIGN.MEDIA token. Community reports (including ’s note) often see the hex portion equal to the executable’s byte size, which matches many registry dumps in the wild, but this is an observation, not a supported contract. If you rely on it, test thoroughly. (pchelpforum.net)

Two reliable ways to avoid computing SIGN.MEDIA:

  • Launch with the compatibility layer set via the __COMPAT_LAYER environment variable. For High DPI override (Application), this applies per-process and works from any location.

    // Launch legacy.exe as High-DPI aware without touching the registry
#include <windows.h>
int main() {
    SetEnvironmentVariableA("__COMPAT_LAYER", "~ HIGHDPIAWARE");
    STARTUPINFOA si = { sizeof(si) };
    PROCESS_INFORMATION pi = {0};
    CreateProcessA("Z:\\Somedir\\test\\legacy.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
    CloseHandle(pi.hThread); CloseHandle(pi.hProcess);
    return 0;
}

    Windows honors __COMPAT_LAYER (Microsoft has documented it in the context of Office issues), and Layers stores High DPI overrides like "~ HIGHDPIAWARE". (learn.microsoft.com)

  • At scale, ship a custom AppCompat database (.sdb) with the HighDpiAware fix using Compatibility Administrator (part of the ADK). This route is supported and avoids per-file registry entries entirely. (learn.microsoft.com)

Practical workflow tip: if you must write to Layers, run the exe once from the share and read HKCU...\AppCompatFlags\Compatibility Assistant\Persisted to grab the exact SIGN.MEDIA=<hex> <relative-path> string Windows generated, then use that as the value name under Layers. (any.run)

Member Avatar for rproffitt

I found no authoritative answer but this seems to be the answer (quote and link follows.)

From the original post information they had a Hex value of 2A314 which equals decimal 172820 - which is the size of the file they list in bytes. My test file was a hex value of 1B32F48 and is 28,520,264 bytes.

From https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/10442e93-1ae6-4bb1-8693-d476916f5292/windows-compatibility-setting-for-removable-media-questions?forum=windowscompatibility

Edited by rproffitt because: Formatting.
Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.