geelaw

如果你是在 Windows 的“属性”对话框里看到的 Image ID ，那么它可能对应的是 ImageUniqueID ，用

exittool "-ImageUniqueID=" C:\path\to\file.jpg

可以删除之。

@hesongtao #7 典型的 UWP 都是自己绘制非客户区的（应该是 XAML 框架或者 CoreApplicationView 做的），所以都受到此问题的影响。

@hesongtao #8 沿着其他路径拖动会先让窗口还原，所以 Fitts 定律的 hack 不会出现。这些问题的根源似乎都是 Aero Snap 没有让窗口先恢复为还原的状态。

@hesongtao #3 看到图了，看起来是 Windows 对最大化窗口的非客户区有新的处理，可以看出那个白条实际上是额外的非客户区（注意最小化等按钮）。

同时我觉得我的猜想应该是对的，窗口的系统绘制非客户区和自己的非客户区都显示“向下还原”按钮，虽然目前窗口已经不是最大化的状态，这说明窗口（受 Aero Snap 影响）错误地以为自己依然是最大化状态。

可以猜一个临时解决方案：再次执行 Snap ，例如用鼠标或者 Windows + 方向，应该可以缓解此问题。

截图看看？

另外 Word 和 Chrome 都是自己绘制非客户区的，可以试试 Explorer 的窗口（系统绘制非客户区）是否有这个问题。当然，如果同一个软件旧版 Windows 无此问题的话，这依然是 bug 。

非客户区：标题栏和调整尺寸的边界和最小化、还原、最大化、关闭按钮。

我的猜测是这样的：最大化的窗口实际上会溢出屏幕几个像素，是古代简便实现 Fitts 定律的方法，在 Aero Snap 里用楼主的方法操作的时候，窗口一直保持最大化而没有向下还原，而进入 1/4 布局（预览？）的时候窗口依然没有向下还原，只是改变了最大化的尺寸，自己绘制非客户区的窗口依然绘制溢出屏幕的像素，也就是白条。

Windows 最近有很多 Aero Snap 的 bug ，我目前用的版本依然有从最大化按 Windows+左右 一次，Snap 的窗口尺寸错误的问题。

技术上正确的说法：不会。因为数字签名不一定伴随抗碰撞散列函数。

实现上准确的说法：Windows 现在使用的数字签名的验证方式的第一步就是计算文件内容（如果是内嵌签名，则删去内置签名部分）的某个散列函数，再继续验证步骤。所以验证签名本身就“验证了散列值”。

如果系统启用了驱动签名校验，且签名后的驱动被修改为不同的文件，且被修改过的驱动没有重新签名，且没有攻破签名方案，那么 Windows 会拒绝加载修改后的那个驱动。

@dilidilid #1 无提示通话录音在美国不违法，联邦法律只要求至少一个参与对话的人允许录音，既然机主和其他人打电话，机主自然可以允许自己录音，而不需要提示其他人。

注意：有些州有更严格的规定，比如 Apple 总部所在的加州规定所有参与对话的人都要同意才可以录音。

几乎不可能，现代英语的读音和拼写的关系很混乱，要确定正确读法最好就是查字典。

用函数作用于一个输入，那么输出是固定的，没有任何随机性。如果输入本身是随机的，那么作用函数之后依然是随机的，但熵不会增加，而且非常明显的例子是把具有 1024 bits 熵的输入用楼主提出的两种方式作用，得到的结果熵必然不能超过 256 bits 。

当然，经过函数作用后，“计算熵”可以增加，然而标准模型下很难分析 SHA-512 和 SHA-256 对输入的计算熵产生何种影响。

只考虑抗碰撞的话，多个函数复合的抗碰撞能力当然不超过最里面的那个的。