@Osk #3 你自己已经知道是 procmon 了呀

YouTube 视频的标题是从微软的服务器获取的，缩略图是从 YouTube 获取的。

如果你设置 HKCU\Software\Microsoft\Office\16.0\Common 的 BlockHTTPImages 为 (DWORD)1，则不会获取缩略图。
如果你设置 HKCU\Software\Microsoft\Office\16.0\Common\Security 的 DisableExtraPathChecks 为 (DWORD)1，则不会获取标题也不会获取缩略图。

由于这两个设置都是 undocumented，而且出现在 Common 里面，你应该自己了解风险后选择。

此外，OneNote 还会查询 HKCU\Software\Microsoft\Office\16.0\OneNote\Options\Other 的 DisableAuthorWidget，但是改变这个值似乎没有效果。

@CruelMoon #29 UTC 的 1970 年 1 月份 1 日凌晨对应惟一的“时刻”，而“现在”也是一个时刻，所以 Unix 时间戳是用一个时刻（时间戳表示的时刻）和一个固定时刻（ 1970-1-1 ）的差表示第一个时刻。

@love #13 你需要知道哪些时间点发生了闰秒，以及你需要的时区，以及那个时区在那个时候的夏令时调整。

@webdisk #19 我觉得 @Septembers 和 @rrfeng 以及其他人观点不同是因为大家认为的“日期时间”不是同一个。

我认为“日期时间”是指按照历法决定的一个时刻的年、月、日、时、分、秒（不考虑相对论，假设只有一个时刻），而“时刻”是一个和历法无关的概念。

例如“太平洋时间 2019 年 3 月 10 日 2 时 31 分 12 秒”是一个不存在的“日期时间”，因为夏令时的调整。

再比如“北京时间 2017 年 1 月 1 日 7 时 59 分 59.5 秒”对应两个“时刻”，因为闰秒。

设备编号一般是 deviceId 才对（假设没有一个 dedicated 设备标识符的概念的话）。

没什么可写就可以不写。从整个文档的角度看读者可能是熟知什么是 deviceId 的，但是从这个有限的上下文看，很容提出一个自然的问题：deviceId 是如何获得的？

@love #10 需要许多额外数据才能把时间戳转换为挂钟时间

在 .NET 里面默认比毫秒还要精确，是 tick （ 100 纳秒），数据库内部存储时间可能是存储从某刻经难过的 tick 数，也可能是挂钟时间。

这并不是一个通常那种感觉的“ API ”——它的消费对象非常有限。

你可以认为 github.com 也是 API ——提供主页渲染服务的——那它自然要返回 HTML。同样，recent-activity 不过是这个 API 的一个小小的子过程。

学习了一下 Google File Stream 是什么……你是说 Drive File Stream 吗？（也就是 Windows 10 最近开放的 storage provider 接口提供的 on-demand 文件同步 API。）

如果是的话那真的是💊了，因为 Drive File Stream 是 G Suite （企业产品）专用，居然是这样的 support 水平……

@bolide2005 #4 很多时候解释一些事情不需要扯到政治正确，我觉得一个技术上更简单的解释是：Unicode 里面雌性符号的编码是 9792，雄性符号是 9794，然后 emoji 字符组是不参加频率排序的，所以永远看到的是女性版本在前面，或者只有女性版本。

另外输入框的解释 #4 是对的，Unicode 是一个进化中的标准，一些字符序列的含义是较新的 Unicode 标准。

用 Windows Media Player 的 object。

https://docs.microsoft.com/en-us/windows/desktop/wmp/windows-media-player-object-model
https://docs.microsoft.com/en-us/windows/desktop/wmp/embedding-the-windows-media-player-control-in-a-custom-program

各种 UI 库通常也有播放器，比如 WinRT/XAML 的 MediaElement。

Word 不需要，HTML 里面最好的方式是用标注语言的方式自动插入空白，但是因为工程量太大的问题目前只是插入空格解决。

开发没有数据库的权限。

此外你还可以用一个随机过程模拟此事，也就是动态决定发生的时机。数据库里记录操作内容和截止时间，把时间量化，比如要求在未来 720 小时内必须进行某个操作，时间量子是 1 小时，那么过了第一个小时后以 1/720 的概率执行操作，如果决定执行则执行并删除记录；否则，再过一个小时后以 1/719 的概率执行操作；如此类推。

需要考虑的问题是：

- 谁应该消费这个函数？
- 潜在消费者和提供者之间有边界吗？
- 怎样效率高？

可能这就是学海无涯的奥义：让人难懂。

@qdwang #7 #14 那是因为你第二次触碰的力度太大了，我在 Windows 里完全不记得有这样误操作过。倒是在 macOS 里面拖动经常出问题（在选定、打开预览和拖动之间拧巴），不过经过练习我已经基本上掌握了技巧。你可以尝试找一找如何调整触控板识别点击的阈值。不过我还有一个疑问：MacBook 和 Surface Book 的触控板都是有触摸、点击、按下三档的，你在 MacBook 上不会误操作吗（ macOS 默认不使用单击锁定，但对力度的掌握仍然会影响是否能完成日常操作）？

Windows 默认的情况下支持单击锁定拖动、按住单指拖动、按住双指拖动，并不支持三指拖动。从 Windows 的角度来说，单击锁定和按住单指拖动是“自古以来”的。

三指拖动已经用于 Task Switcher 了。

一个错误的想法是以为产品的生命长度总是不少于贷款的久期……