@geelaw #11

>如果修改密码的时候提供旧密码，那么 Windows （在操作人有合适的权限的情况下）当然可以修改它记住的 H ，允许用新密码通过 Windows 的登录逻辑。但是没有 P 的时候 S 、K 依然无法还原。

应该改成

>如果修改密码的时候 不 提供旧密码……

@dgzting #10 是否有那个问题是数学决定的，不是 API 决定的。Windows 有一些自动加密的内容使用用户的密码导出的密钥，可以简单地理解为这样的模式：

1. 用户建立的时候生成 AES 密钥 K
2. 如果用户密码是 P ，则计算 S = MakeKeyFromPassword(P)，其中 S 是另一个 AES 密钥
3. 在硬盘上保存 AutoKey = AES.Enc(key=S, plaintext=K)
4. 如果用户设置文件 F 要加密，则在硬盘上保存 EncF = AES.Enc(key=K, plaintext=F)，解密的时候可以用 P 导出 S ，再用 S 解密 AutoKey 得到 K ，最后用 K 解密 EncF 得到 F

注意 K 是没有直接保存在硬盘上的。

5. 如果用户修改密码，那么先用旧密码 P 得到 S ，然后用 S 解密 AutoKey 还原 K ，再用新密码 P' 得到 S'，再设置 AutoKey 为 AES.Enc(key=S', plaintext=K)，这样每次修改密码的时候只需要重新加密少量数据，不需要把所有文件都解密再重新加密一次。

这个机制和 Windows 验证用户登录的机制是分开的，你可以认为 Windows 另外保存了密码 P 的 hash 值 H ，而 H 本身没有加密，登录时 Windows 只是计算用户尝试登录时输入的密码的 hash 并和 H 比较。可以简单认为登录成功的时候 Windows 重新见到了 P ，因此可以重新算出 S 、K 并在内存里缓存 P 、S 、K 。然而假设用户没有登录，比如操作系统刚启动的时候，此时 Windows 只知道 H ，不知道 P 、S 、K 。

如果修改密码的时候提供旧密码，那么 Windows （在操作人有合适的权限的情况下）当然可以修改它记住的 H ，允许用新密码通过 Windows 的登录逻辑。但是没有 P 的时候 S 、K 依然无法还原。

换言之，是否允许登录纯粹是操作系统想不想的问题，但是否能解密数据，是能不能的问题。

* * *

你在 lusrmgr.msc 和 compmgmt.msc 里面修改用户密码的时候会提示

Resetting this password will might cause irreversible loss of information for this account.

等等一大串，并且告诉你（作为用户而不是开发者时候）正确做法是按 Ctrl+Alt+Delete 打开“Windows 安全”对话框，选择 Change a Password ，然后输入用户名、旧密码、新密码（两次）。

net user 和 Set-LocalUser 都不需要旧密码，因此一定会导致密码学数据不再可用（除非你后来想起来旧密码并且旧的例如 AutoKey 和 EncF 还没有被删除，我不知道 Windows 会不会自动删除失效的 AutoKey ）。实际上它们和 lusrmgr.msc / compmgmt.msc 归结为同一个 API 。

而 NetUserChangePassword 需要旧密码，而且实际上 NetUserChangePassword 会类似之前提到的解密、重加密操作，所以不会有这个问题。它和 Ctrl+Alt+Delete 是一样的。

* * *

是否丢失密码学保护的数据和用户在本地还是域控制器上无关。在 Windows 提供的 API 下，丢失数据当且仅当修改密码不需要提供旧密码。

用 net user 修改密码是有多想不开……

凡是不需要旧密码就可以强行修改密码的手段，都会导致被修改密码用户原先保存的密钥失效，使这个用户（密码学意义上）不能再访问加密数据（ EFS 、基于用户的 Crypto 系列 Windows API ）。

推荐从 https://learn.microsoft.com/en-us/windows/win32/api/lmaccess/nf-lmaccess-netuserchangepassword 开始阅读文档。

这个问题很容易诊断，但是用文字表达比较麻烦。

简而言之，你应该检查 HKCR\.png\OpenWithProgIDs 里面的东西，删除多余的 value ，并且删除多余的一些 ProgID 。但后面（删除多余的 ProgID ）这个操作是要比较小心的，不熟悉的话容易删除正常的文件关联项。

@sdjl #4

>请勿使用“否定式反问句”。
>难道你没有这种感觉？

自己写个发邮件的程序一样可以，Gmail 现在也是可以的，而且我记得还有一种模式是记住其他账户的密码，从而直接通过正确的服务器发送。这算不上伪装吧，毕竟 Sender 写明了是谁。

电子邮件头的很多信息和传输来源目的是分开的，比如很多邮件服务器都会在送达 bcc 收件人的时候也删去 bcc 行，另外邮件列表也大量运用 Sender/From 不同、To/Cc/Bcc 都没有实际收到邮件的邮箱地址的情况。

我怀疑楼主混淆了微软的个人账户（微软账户）和微软托管或者联邦认证的机构账户。

微软账户 = 个人 OneDrive 账户 = Xbox 账户 = Skype 账户

如果微软账户具有微软控制的域名的邮箱，则它也是 Outlook.com/Hotmail 账户，并且后者永远都是微软账户。

Office 365 教育版是机构账户。如果你想把机构的 OneDrive 在个人的 OneDrive 里使用，我记得不久以前不行（可以从机构里 share 出来，如果机构允许，但似乎不能把共享文件夹加入个人账户），现在的情况还请查阅文档。但最简单的用法是在电脑上同时使用 OneDrive 和 OneDrive for Business ，在两个没有包含关系的文件夹里同步就行了。

https://learn.microsoft.com/en-us/windows/apps/design/shell/tiles-and-notifications/windows-push-notification-services--wns--overview

Since Windows 8

这件事情大概要 Windows 自己做才能做好。从权限上考虑，剪贴板是 window station 级别的对象，并且同一个 window station 里面的所有窗口都可以访问（包括高权限、普通权限、低完整级别的进程，即可以从记事本复制命令到管理员权限的命令行，等等）。

但要完成这一点是相当困难的，因为远古时期的 API 是同步 API ，剪贴板也不例外，贸然插入一个模式对话框会导致尝试粘贴的程序假死。

@Whalko #4 远古时期（ 2003 年）的 Office 系列自带一个剪贴板历史管理工具，它显然要不断监听并读取剪贴板。

通常来说只需要几乎处处可微，比如 ReLU 在 0 不可微（但是作为凸函数又有次梯度），这里就不展开了。

如果你是用 PyTorch 提供的函数自己设置损失函数，那么可微函数复合依然可微，就是链式法则、反向传播，实际上损失函数不过是计算图普通的一部分，计算微分的方法无甚差别。

如果你是说自己用 C++ 写新的函数，那么你可以在 C++ 里实现函数和它的微分，并注册在一起，这样 PyTorch 计算微分的时候就知道怎么算了。我在微软的时候做过一个 TensorFlow 的扩展（三重线性插值），不过他们没有开源（提供了一个编译好的包可以下载），但似乎新版的 TF 已经有这个功能了所以现在已经没必要了。

@zw1one #3 请注意括号里的提示，A 对 B 说 A 的工资不违法，A 对 B 说 C 的工资可不一定（ C 不等于 A ），讨论工资是权利，然而他人的工资或许是他人的隐私，因而受到保护。从 #4 才知道这是公开信息。

楼主可以从上面的回复了解绝大多数用户的想法，但我也想鼓励楼主：存在着对底层技术在意的用户的。

很简单，你可以把沟通的过程都用机构电子邮件记录下来，以后责任肯定不是你的，而且本科生可以照样拿钱，不是挺开心的？（当然，你很可能出于责任心而为进度拖延感到不开心。）

>老美同事马上来问我老板给本科生开的工资是多少。当得知是他工资的一半以后，他松了口气，说如果这个本科生工资比他高他就要退学了。

且不说这种八卦操作是否有失专业，我严重怀疑这种讨论（ A 告诉 B 另一个人 C 的工资状况，且 B 没有处理工资发放的 capacity ）是非法的，虽然我暂时没找到相关的条文。

一切可以保存文本的软件都可以录入公式，至于显示那就是另一个问题了。

- 单纯做笔记我一般是用 OneNote ，见 https://www.zhihu.com/question/418933529/answer/1525594474
- 和其他人交流简单内容我一般是用 Word 导出 PDF 或者 Outlook 邮件（对方也是 Outlook 则得到最佳格式的内容，其他情况如网页可以看到转换为图片的公式）
- 写文章我一般是用 LaTeX

Office 系列的公式编辑器是 UnicodeMath ，解读起来比 TeX 简单很多。

“编制”不算特色词汇，是政府语言，其本质是对任人数量有额定标准，英文可以用 budget/rate/ration 表达。

但现代程序理应可以处理 Unicode ，直接用汉字最简单。

@kkwa56188 #31 是 qing1long2yan3yue4dao1 ，另外汉语拼音正词法应该是 Qīnglóng-Yǎnyuè Dāo 或者 Qīnglóngyǎnyuèdāo ，即 Qing1long2Yan3yue4Dao1 或者 Qing1long2yan3yue4dao1 的大写方式比较好。