@luoyou1014 #11 https://www.zoho.com.cn/mail/help/usage-policy.html 里面说了不能发送自动电子邮件。通常来说自动化发送邮件是特种服务，不会包含在一般的企业邮箱服务里面。

另外楼主混淆了概念类别。

Gmail 和 Exchange Online 和 SendGrid 可以认为是类似类别的概念，都是某种服务的提供商，Gmail 和 Exchange Online 都是为了接收邮件和手动发送邮件的，SendGrid 是为了自动化发送邮件的。至于 SMTP ，和上面是不同类别的概念，无论是自动化发送邮件还是手动发送邮件的服务，都可以以 SMTP 的方式提供服务。

所以严格来说可以如此回答：有，并且是的。

比如 SendGrid 。

宏大叙事和思而不学则殆的结合产物

已经火速看完 S2E1 了（

提示一下把你的 license 换成 AGPL 没有任何实质作用，因为：

1. “敌人”已经拿到了 MIT 授权的此软件
2. 任何人都可以从 Git 仓库的旧版本重新以 MIT 授权获得此软件

此外 Twitter 用户在 https://x.com/bclee0827/status/1879997738789794261 做了一张假截图？

这个域名的 WHOIS 信息显示

Updated Date: 2025-01-16T16:51:47Z
Creation Date: 2018-05-26T10:17:22Z
Registry Expiry Date: 2025-05-26T10:17:22Z

注册人信息不写成文字了，避免被搜索到，见最后的图。

按照楼主的说法，域名在 2024 年 4 月之后、今天（ 2025 年 1 月 17 日）之前过期。
正常来说域名过期被别人买入，creation date 会是最后一次买入的日期，要如何解释这个日期是 2024 年之前？
我的猜测是这个域名是通过过期域名拍卖买入的，因此实际上是上一个注册商自动延长一年之后，转移给了新主人。

说明 Twitter 用户可能计划周密……

https://imgur.com/ol8xrcn

wow 这个问题完全 under-specified 。第一个问题：你知道要调用什么函数了，可你怎么制造不同类型的参数传入之？

但楼主不应该尝试回答我的第一个问题，而是应该直接说自己实际上要解决的问题，而不是来问自己觉得可行的一半解决方法的另一半。

有些节目演员/解说员口齿不清，字幕可以极大降低解读功耗。专业播音、专业演员、专业配音员的语音比较清楚，不用字幕也比较轻松。

@hamsterbase #11
Git 和签名有完全不同的场景，因为 Git commit 通常是 non-adversarially constructed （非别有用心构造的），所以用一个过时的散列函数危害没有那么大。如果用户对自己的 Git 仓库构造 SHA-1 碰撞，受害者是用户自己，而不是别人。请注意 Git commit 签名和 commit hash 是两码事儿，它的 commit 签名的作用对象是 commit object 被 sign 之前的内容，而不是 commit hash ，而 commit object 本身的信息是当前内容快照加上一些 commit 信息（比如消息、时间、committer ），因此可攻击的面仅限于内容快照。

当然，我的观点是 Git commit 签名意义不大，考虑用户 A 签名 commits 后又继续被别人开发，然后用户 A 的私钥泄露，那么对于新来的人，没有办法确认过去被 A 签名的 commits 到底是泄露之前签名的，还是泄露之后伪造的——除非重新签名并改写过去所有的 Git 历史。其意义不大的根本原因在于我期待软件开发历史隽永，但是签名的安全性并不隽永。

@drymonfidelia #14

考虑我定义的签名算法 Sign(sk, msg) = 123 并且给所有程序都加入这个签名。显然该算法不安全，请问它是否有伪造的风险？

答：有“被伪造的风险”，但是此问题无意义，因为没有任何人会认为被这个不安全算法签名的程序是“有背书的”，即没有“错误认为有安全签名的风险”。

习题：过期的证书不被信任，一个证书的证书链只能追踪到过期的根证书，那么被这个证书签名的程序，是否有伪造签名的风险？

没有验证程序支持的签名，不过是一堆无甚意义的数字。

@hez2010 #35 我说的是装箱拆箱的问题，不是 int 和 enum 存在转换的问题。

StringSpiltOptions e = (StringSplitOptions)1;
int i = (int)e;

不是

object o = (StringSplitOptions)1;
int i1 = (int)o; // bad, but works
int i2 = (int)(StringSplitOptions)o; // good, and works

装箱拆箱在 C++ 标准里最接近的是 std::any_cast ，它并不允许把存放了 enum 的 any 通过 any_cast 变成 int ，但这个论证无意义，因为 C++ 的 any 比 CLR 晚了很久。

另一个接近的是 C++ 允许 std-layout type 的 pointer 和它 first member 的 pointer 做 reinterpret_cast ，但是 C# 里面装箱后的值类型（根据 CLR 定义，这是和值类型不同的、一个自动产生的类型）应该理解为多态类型（“具有虚表”），此时不是 std-layout ，所以也不适用这个类比。

很多是哪些？知名的 SHA-1 根证书已经过期了。

@w568w #30 数组可变性是从 JVM 抄到 CLR 里最恶心的特性之一，根本不应该支持。解决方法是 public readonly struct S<T> where T : class { public readonly T O; public S(T o) { O = o; } } 然后用 S<T>[]。

@GuoJikun #7 Alt+P 是官方的预览方式（但很可惜在 pickerhost 里不行）

@geelaw #3 那个文件的名字是 Magnify.lnk 。另外要让 notepad.exe 显示所有文件，只要在文件名里面输入 * 再按一下回车。

答案是不要尝试做这件事情。

IShellWindows 枚举的是 shell (Explorer) 里面打开的窗口，其他程序打开的文件选择对话框和 shell 没什么必然关系。

使用 GetWindowTextW 得到的是 hwnd 里面的文字，首先在那个文件对话框里面，对话框本身和对话框里面的文件名组合框（可以输入文本、可以下拉选择，也可以通过选定项目改变的，左边写着“文件名(&N):”的框），是两个窗口（甚至有可能那个组合框是无窗口控件），它们的 hwnd 都不一样，在对话框的 hwnd 上调用 GetWindowTextW 得到的是对话框的标题，和文件名没有关系。

那个组合框里的文本可以是用户乱写的，不一定对应任何一个文件。

即使用户通过选择一个文件导致组合框显示了文件名，它显示的名字也不一定是你期待的那一个——你可以在 notepad.exe 里面打开“打开”对话框，然后导航到 C:\Users\用户名\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Accessibility ，选定放大镜的快捷方式，你会发现：

1. 显示的名字没有 .lnk
2. 显示的名字不是 Magnify.lnk 而是（中文）“放大镜”或者（英文）“Magnifier”

但是那个文件的名字是 Magnifier.lnk ，显示的名字是通过 desktop.ini 控制的。

————

最好直接问你想要做什么最终用户受益的事情，而不是怎么做你想到的一种可能的做法，避免 X-Y 问题。

@geelaw #6 “数组逆变”应该更正为“数组协变”。

有一些很坏的特性，比如数组逆变（性能有极大损失），类型兼容性版本太多并且不一致（比如装箱 int 不可以拆箱为 uint ，但装箱的 int enum 可以拆箱为 int ，但 int[] 是 uint[]，并且我永远记不住 int[] 是不是 int enum 数组；完全采用依名判定会简单很多），再比如实现多个可变接口时可变接口解析的歧义性，当然这都是 CLR 的问题。

C# 自己的问题大概是加入一些不必要的限制，比如古代的 C# 语言不许用 Enum 作为范型约束，虽然它完全有意义并且自古以来就受到 CLR 的支持。