@geelaw
@ysc3839 我找到了微软官方的文档
https://learn.microsoft.com/en-us/windows/win32/directshow/overlay-mixer-filter
早期视频叠加渲染独立于 d3d （ VMR-9 开始才支持 d3d ），用的是 directshow ，和 dx surface 没有任何联系
楼上说的不用 alpha 混合，说的应该是 vmr-7 以及之后的渲染方式，显然稍微新一些的应用都不需要在这个方面扣性能了
也找到了颜色相关的描述，如果没有指定颜色键的话，深灰色适用于较新的显卡，洋红色适用于较旧的 256 色卡。
这种模式下，最多只能显示一个视频流，有两个视频播放的话就可能产生闪烁
启用了视频叠加还会禁用 dwm ，也就是说，基本上和 d3d 也冲突了
这个模式充满了历史感，用的是所谓的视频端口，文档中还包括了 line-21 也就是 cc 显示的功能和所谓的 DVD 子画面（显然也是特殊显示器 /电视机才能实现的），为了用上硬件加速可真的是不择手段啊。。。
这里列出了古代视频渲染（显示到屏幕的部分）方式列表
https://learn.microsoft.com/en-us/windows/win32/directshow/choosing-the-right-renderer

@yolee599 但是如果你用 msys2 的 git ，会有一些路径转换的问题等着你

@felixlong 果然是用颜色 mask 做的，我看 wiki 里写
As a consequence of hardware overlay use, a screenshot program (for example, the one automatically built into Windows that activates when a user presses the PrtSc key) often does not capture the content appearing in the hardware overlay window. Rather, a blank region containing only the special mask color is captured. This is because the screen capture routine doesn't consider the special video memory regions dedicated to overlays – it simply captures the shared main screen as rendered by the software's graphical subsystem.
还以为是啥特殊的东西，原来就是直接特殊颜色啊

@ADMlN 现在截图谁还用 dc 的方法截图啊（这种多数游戏一类的一开始就截不到），性能还慢，更好的 api 太多了（

虽然不能确定，但是我可以提供一个可能原因
视频播放用的是硬件叠加层( https://en.wikipedia.org/wiki/Hardware_overlay )（然后就能获得硬件加速），在前 dwm 时代，硬件叠加层是完全独立于窗口绘制，windows 需要给叠加层设置裁剪区域以“模拟”窗口被别的窗口覆盖的场景，显然截图变黑就很好理解了，因为根本就不在一个图层上（
至于穿透的话，则应该算是 bug 了，考虑到 mspaint 以前基本上是 gdi 功能演示程序，不排除是 gdi 和硬件叠加层之间的处理问题

@brader 云服务器防火墙那种感觉是黑洞了，可能在更底层处理的，比如直接丢弃了相关的包，表现出来就是没响应直到超时

对付普通 dos 工具还是有效果的（也不排除直接 bypass ip 栈绕过 tcp 状态机处理），ddos 就没啥用了

windows 充电各家方案都不太一样，建议找厂商对应的工具

那你这么做的话，可能就和具体系统没啥关系的 app 了吧
那就直接 web app 吧——

你可以先排查一下扩展*

先检查下有没有中毒吧。。。

默认的沙箱拦不住扫盘吧（
得隐私保护沙箱，那个兼容性更差一点

@ksedz poll 和 select 都是不支持 poll 的时候直接返回，原因多半是因为缺少错误报告的手段（用 fdset ，报错的时候你咋知道是哪个的问题），而 epoll 可以在 ctl 的时候返回报错，这就是原因

@ksedz 那是用户态提供 buffer 有问题的情况才会失败，这个角度所有设计 buffer 的 syscall 你都得考虑失败了。。。但这情况你重试也没用啊

@ksedz urandom 极端情况也不会失效，那函数实现就是在没墒的时候发几个警告就过了
static ssize_t urandom_read_iter(struct kiocb *kiocb, struct iov_iter *iter)
{
static int maxwarn = 10;

/*
* Opportunistically attempt to initialize the RNG on platforms that
* have fast cycle counters, but don't (for now) require it to succeed.
*/
if (!crng_ready())
try_to_generate_entropy();

if (!crng_ready()) {
if (!ratelimit_disable && maxwarn <= 0)
++urandom_warning.missed;
else if (ratelimit_disable || __ratelimit(&urandom_warning)) {
--maxwarn;
pr_notice("%s: uninitialized urandom read (%zu bytes read)\n",
current->comm, iov_iter_count(iter));
}
}

return get_random_bytes_user(iter);
}
可以看出根本没有失败的执行路径，get_random_bytes_user 里也没有任何失效的代码，就纯算法而已））出错就直接 panic 了，根本没机会返回爆炸的结果）
你那个资料可能过时了））
实际上按之前的 poll 方法，那也是纯粹毫无作用，是原开发者的错误理解，你这如果只需要考虑 linux 平台的话（你看都用 epoll 了，肯定是 linux only ），就直接返回可读即可

但是 urandom 按定义就是不会阻塞的，你这个 epoll 也没意义啊。。。
urandom/random 只实现了 read_iter, write_iter, unlocked_ioctl, compat_ioctl, fasync, llseek, splice_read, splice_write 这几个方法，没有实现 poll 方法，因此 epoll 不能用（
至于 poll 和 select 系统调用，当发现目标没有实现 poll 方法的时候，直接就原样放回去了（假装都可读写）

https://developer.arm.com/documentation/ddi0344/c/programmer-s-model/thumb-2-instruction-set
直接看官方的说明不就可以了

我的建议是，用联网同步的密码管理器（

主程序 32 位方便分发而已）