@opengps #3 这个问题和句柄泄露无关，USER 句柄是不计数的，泄露方式只能是建立的窗口之后不使用。而且一个会话里的 USER 句柄数量最多是 65536 。

“用户不能操作”仍然不是一个有意义的定义，而且用户当然可以操作 IME 窗口，不然候选词列表怎么用？如果你觉得任务栏是否显示这个窗口的按钮可以作为判据，那么你可以模拟任务栏的选择，这是有文档记录的：

https://docs.microsoft.com/en-us/windows/win32/shell/taskbar#managing-taskbar-buttons

定义“无意义”，如果当前没有显示的窗口是无意义，你可以通过 IsWindowVisible 和 DwmGetWindowAttribute 判断。

微软做了极简风：粗糙。Google 做了极简风：微软粗糙。显然截图里微软的 UI 更有用：显示修改日期、子对象数目、共享状态等。

另外，OneNote 笔记本实际上是文件夹，类似于本地 OneNote 的结构，而且 OneNote 笔记本的名字和位置都需要显示才能管理，假设你想有两个同名的笔记本，如果不显示位置则无法区分哪个是哪个，也没法移动位置，而且 OneNote 笔记本共享、删除等也可以和其他 OneDrive 里的对象一样管理。既然本来就是同类物，为什么不显示呢？

Google Photos 和 OneNote 无法像 OP 所说那样比较，OneDrive 里也有不显示但是占用空间的东西，比如 Windows 8 、Windows Phone 备份数据。根本区别在于 Google Photos 没有把照片当“文件”管理，而 OneNote 就是文件。

最后，日历、邮件、联系人放在一个 app （我想你说的是 Outlook 和衍生的 communicationapps ）是因为 Outlook 的定位是 personal information manager，而不是单纯的“邮件客户端”。

@ipwx #19 #20 基于 RSA 签名算法并不是“用私钥加密”，根本没有“加密”的概念。

#0 JWT 不一定具有保密功能，不存在“密文”“加密”的概念。不过楼主有一部分说得没错，验证签名、消息验证码不需要使用 hash 函数，只不过真实世界里的签名、消息验证码都在某些步要用 hash 函数，因为不用 hash 函数的（可证明安全）方案实际效率令人无法忍受。

难道你么不觉得最重要的暗示是 Desktop application 也可以使用 Live Tile 了吗？这个是一个巨大进步。

另外这个自定义色彩的删除是一个巨大退步，实际上从 Windows 10 最开始就一直在走下坡路，仔细看 Windows 8/8.1 的磁贴渲染，颜色的运用和动画的缓动函数都好太多了。

C# 不可能的，Windows 95 于 2001 年结束支持，C# 1.0 是 2002 年发布的。

上古版本的 BASIC 是可以的。

你不需要知道 tuple_cat 或者 index_sequence 或者 disjunction，这些全都可以通过基础手段实现。

第二个的思路：列表 A 没有重复等价于 (A 是空的) 或 (A 第一个元素不等于其他且 A 去掉第一个后无重复)。

第三个的思路：可以通过枚举算出一个元素在列表里的位置。

使用 hash 函数 ❌
使用伪随机函数 ✔

这样会得到一个具有适应性密码泄露安全性的方案：使坏者可以请求任意 app 的密码，最终它需要猜出一个未曾见过密码的 app 的密码，希望它猜不出来。

一种方式是把 hash 函数建模为随机预言，这样 hash 函数可以充当伪随机函数，但是这显然不如伪随机函数好，后者是标准模型下可证明安全。

在实践中，大家相信 AES 是伪随机函数（而且 AES 比 SHA256 快，而且 SHA256 已经不能被建模为随机预言了），所以正确的做法应该是通过 KDF 把密码变成 AES key，然后把 app 名字编码为 AES 输入，把 AES 输出映射为 app 密码。

@Sngo #3 搜索 adjust cleartype text 然后运行第一个结果

@YuxiangLuo #5 这个功能是 Windows Vista 引入的，在最近的系统里可以通过 File Explorer 的 View 选项卡里的 Item check boxes 开关。

不过这里也暴露了 Windows 重命名里不太令人满意的处理：如果重命名 A (2).ext 为 A.ext 且 A.ext 存在且 A (3).ext 不存在，更好的问题应该是：“要取消重命名 A (2).lnk 吗？”

问题错误，对于一个一般程序来说不存在浏览器里 origin 的概念，自然不可能有“跨域”甚至“禁止跨域”的说法，程序做的事情是用 TCP 和另一个机器对话。

对于网页来说，它是浏览器模型下的程序，自然受到浏览器的约束。同源策略是为了保证浏览器模型下的隔离设置的，而浏览器的安全模型是向用户提供安全保证的契约。实践表明同源策略可以防范许多用户不希望遭受的攻击，所以会加入现代浏览器的安全策略。

另外，从逻辑简单性+归缪的角度思考这个问题：Chrome 也只不过是一个一般程序，如果一般程序必须和一个域名绑定（假设这句话甚至是有意思的），为什么 Chrome 不是只能访问 Google 的网站？

Tuicool 没有署名，jishuwen 进行了演绎，而 studygolang 没有提供 CC BY-NC-ND 4.0 许可链接，至于它们是不是商业行为我就不知道了。

“阶乘”，最不具有技巧性的方法是使用 Stirling 公式进行估计。

然而对于这个问题来说 Stirling 公式或者因数分解都是小题大做了，因为 100! >= 8^(100 - 8) = 2^276 > 2^256 。

@binsys #2 Cloud files API，见
https://docs.microsoft.com/en-us/windows/win32/cfapi/build-a-cloud-file-sync-engine

@codehz #1 UUID 的生成算法不一定是不可预测的。

> 钉钉渲染不出错的话应该不会显示图片源

这是一个很怪异的陈述，楼主到底想要防什么呢？任何可以获得图片的人，再获得图片的 URI 有什么不可以的吗？

另外请楼主不要重复发贴 /t/656378

可以用 UI Automation 监听事件，我写了一个例子

https://gist.github.com/GeeLaw/7c2bc923564fe562425d259caf3f40de

@alphatoad #10 Windows Store （至少曾经）的 TOS 和 GPL 是兼容的 https://opensource.stackexchange.com/questions/4460/can-a-gplv3-app-be-uploaded-to-the-windows-store

@alphatoad #8 这个理解是不对的，否则几乎没有（有意思的） GPL 软件可以（实际可行合法地）从各种 Store 获得，因为几乎所有有意思的 GPL 都是多个人贡献的。

@iasuna #6 这个上传不符合 GPL 的要求，因为没有提供获得源代码的方式，也没有提供 GPL 协议链接 /文本。

另外这个上传者不能说是“冒充”，它没有使用楼主的名字，软件名字“划词翻译”也不能说是楼主拥有的名字。楼主可以用 https://www.microsoft.com/en-us/concern/dmca 反映侵犯版权的情况，并顺便提示它们 Report abuse 的功能坏掉了。

如果你是说 Windows 上为一个文件执行 打开方式 > 选择一个程序 的话，可以用 ShellExecuteEx，传入 SEE_MASK_INVOKEIDLIST 并设置 lpVerb 为 L"openas"。

如果你想用默认文件关联打开一个文件，可以 ShellExecute 这个文件。

如果你想查询文件关联，可以用 IQueryAssociations 。

更多资料见
https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecuteexw
https://docs.microsoft.com/en-us/windows/win32/api/shlwapi/nn-shlwapi-iqueryassociations
https://geelaw.blog/entries/windows-fileassoc-walkthru/#consume-fileassoc