@stianhoiland I could jump in here if you like. There are two possibilities:

• Microsoft wants us to specify DPI awareness and context in the manifest. Creating a manifest file and adding it in the resource script is easy. However, it requires you to turn off automatic manifest creation in the linker settings of MS Visual Studio.
• Alternatively, we could call SetThreadDpiAwarenessContext() (min. Windows 10) or one of its ancestors if you want to keep some backward compatibility.

Do you have any preference?

@eugenesvk Nice catch. This is something cmdtab should support.

@german-one Thanks for the offer of assistance and quick summary! My eyes are crossing over trying to wrap my head around the various DPI-related APIs. Here are the right docs, and this seems to be a very complete reference implementation, though all too verbose and extensive for my liking—I like small surfaces :)

I can't shoulder this change at the moment. I will however review any pull requests for this feature. In particular, since cmdtab is such a long-running process, its implementation should support WM_DPICHANGED.

EDIT: It is hard for me to state a preference since I can't visualize the overall impact of the alternatives. I may prefer the manifest solution if it is the original DPI awareness mechanism. What's the significance of requiring that automatic manifest creation be turned off?

[...] its implementation should support WM_DPICHANGED.

I really don't think that you want to process the WM_DPICHANGED message. Let me try to explain it a little more in detail ...
The reason for making this app DPI aware is that we want antialiasing for the window content getting calculated based on the actual DPI and scaling, rather than on an assumption it was 96 DPI with 100% scaling. Once this is specified, it will keep working accordingly. You only process WM_DPICHANGED if you want the app doing something if the DPI value changed. Perhaps something like updating the size of the window. However, this would feel quite wrong and could have been specified from the beginning. E.g. making the app per-monitor DPI aware would be simply another possible setting via manifest or API. But - as I said - it feels wrong if the window gets a completely different size whenever you move it from one monitor to another.
So, out of my experience, it is absolutely sufficient to set it system DPI aware.

[...] I may prefer the manifest solution if it is the original DPI awareness mechanism. [...]

Well, this is rather Microsoft's preference. They may have a reason 🤷‍♂️ The manifest file would look like so ...

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <asmv3:application>
    <asmv3:windowsSettings>
      <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">system</dpiAwareness>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

... and get added to the resource script like this ...

1 RT_MANIFEST "cmdtab.manifest"

[...] What's the significance of requiring that automatic manifest creation be turned off?

Otherwise there would be two manifest files which makes the linker throw because it can handle only one.

Only for completeness and in case you change your mind - we can get the same effect by just calling one of the below API. Preferably after the AlreadyRunning clause in RunCmdTab().

SetProcessDPIAware() (>= Vista)
SetProcessDpiAwareness(PROCESS_SYSTEM_DPI_AWARE) (>= Win 8.1)
SetThreadDpiAwarenessContext(DPI_AWARENESS_CONTEXT_SYSTEM_AWARE) (>= Win 10)