为什么 Windows 上的第三方软件对高清屏支持这么差

为什么 Windows 上的第三方软件对高清屏支持这么差

不垄断发行渠道，对第三方软件不强制品质。（因为一旦控制必然导致第三方倒戈。当年任天堂怎么死的知道没？）
没有 C/C++ 版的类 WPF 界面库。（因此如果第三方想要软件「清楚」，就必须自己处理界面缩放——这可不是个简单活。当然也可以用 .NET，问题是不是所有人都装了 .NET。）
XP 退市太晚。（导致第三方不敢使用 Vista 以来的新功能。原因太多，当然在国内绝对是因为 Vista 和之后的 OS 不好破解。）

从 windows vista 开始微软引入了一套新 api 用来处理界面缩放（是 06 年提出的，比苹果早很多）。这套机制叫 dpi virtualization。在 windows 8.1 里 dpi virtualization 被强化以让不同显示器有不同的 dpi 设定。dpi virtualization 的目的是不让老程序在高 dpi 设置下出现界面错位，同时如果新程序可以处理缩放，则交给程序自己处理。 dpi virtualization 依赖 dwm 实现。当 windows 检测到你的程序（进程）不支持 dpi 缩放时（即运行非 dpi-aware 程序），它直接放大窗口，因为有非整比的缩放所以可能会造成界面「模糊」（不信你在 8.1 里可以试试 200% 缩放，结果是锯齿状的，和 osx 一模一样）；而对于新应用则不作特别处理。这套机制的具体行为非常复杂（特别是在引入分屏 dpi 设置之后），就不多展开了。有兴趣可以参阅 high dpi settings in windows。判断进程是否支持缩放的 api 很奇怪地在 8.1 之前的系统里一直没给，8.1 提供了，叫 getprocessdpiawareness。 windows 应用通知系统自己支持高 dpi 有两种方式，一种是向主进程的 manifest 中写入信息，另一种是使用 setprocessdpiawareness 函数。在 windows 8.1 中应用程序对高 dpi 支持有三级，对应 process_dpi_awareness 的三个属性，它们分别是： process_dpi_unaware：此程序不支持高 dpi process_system_dpi_aware：此程序支持在第一屏上按高 dpi 显示，不能处理多显示器的分别设置 process_pre_monitor_dpi_aware：此程序可以在不同显示器设置不同 dpi 时仍然工作良好 vista 到 win8 只有前两级，因为它们没分显示器的 dpi 设置。此时 api 稍有变化，是使用 setprocessdpiaware api。 对于那些被放大窗口的应用，系统会生成一系列的「假」数据给他们，包括屏幕分辨率和鼠标座标。这样就可以保证最大程度的兼容性。 从这种处理机制中可以看出微软在 vista 的年代就提出了一套良好的系统来对付高 dpi 环境可能造成的兼容性问题。然而现在被很多人诟病的「windows 不支持高分」原因在哪里呢？原因有三： dpi virtualization 支持非整比缩放，导致被放大的窗口会变模糊。这是微软的责任，他们应该使用更好的缩放算法，例如 hqx 或者 xbrz。但是记住，「模糊」是相对显示屏密度而言的，在高密度显示屏上它并没有那么「模糊」。更好的策略可能是像一些游戏机模拟器那样用两个缓冲，一个送显示一个给程序读屏用。 仍然有大量的应用程序不支持高 dpi。这是第三方的问题。下面详细展开。 和座标变换相关的问题。这个比较复杂，只会涉及一些跨窗口操作的应用程序和钩子程序，不展开了。 在第三方应用程序这边，因为系统得知应用是否支持高 dpi 是，应用程序通知系统的，因此就会出现四种情况： 应用在高 dpi 下运作正常，并通知系统：很好，应用清晰显示，行为正确。微软许多原厂应用（包括 word 2013、vs2013 等）都能做到这一点。sublime text 3 也属于这一类。 应用在高 dpi 下运作正常，然未通知系统：窗口被放大，应用程序显示模糊但是行为正确。这种应用数量不多，一些 cad 软件有可能属于这一类（cad 界使用高分屏已久，不少软件都有不错的高 dpi 支持）。 应用不支持高 dpi 却错误通知系统：系统不对应用作特别处理导致界面错位或者大小不正确。类似题主中 wps、photoshop、chrome 的情况。还有一种可能是用于启动程序的快捷方式里设定了「在高 dpi 下禁用界面缩放」，qq 应当是这个问题。（因为写这个答案的时候我同时开着 qq 和高 dpi，而我能明显看见 qq 窗口是被放大的。wps 也可能是这种情况。）