很多闪盘是比机械硬盘快的，否则 Windows Vista 不可能推出 ReadyBoost 。

用静态构造器，具体来说把 public Ngan 改成 static Ngan 。

功能访问残废化

我想说我第一反应是 dental ache 🤣

int * 当然是类型。正确的原因如 #1，因为 * 是和标识符结合，而不是和类型名字结合。

int *a, b; 的意思是 int *a; int b; 如果写成 int* a, b; 则容易误以为意思是 int *a; int *b; 所以 * 永远靠近标识符。为了一致性，在声明返回类型的时候也让 * 靠近标识符（即函数的名字）。

@archoot #12 答案是不能一步到位，因为 DOS 不支持任何单个文件可以超过 2 GB 的文件系统，因此不可能存储 Windows 10 的安装文件（ WIM 文件过大）。所以如果不是订阅用户，则无法只用 DOS 更新到 Windows 10 。

@nobody123123 #14 “既然知道大小，那就不用比了”是天真的想法，说不定 Alice 就是想知道到底是多 1 还是多 2，而 Bob 对此则毫不知情。也可以换一个场景：Alice 知道 Bob 和她的财富差距是 1 或者 2，但是不知道是四种情况的哪一种，那么经过计算，Alice 不但知道了是多还是少，而且还对差距有更多掌握。

安全的方案必须满足：经过计算之后了解的 额外 信息不能超过计算所允许得到的，无论先前已经掌握多少信息。

你需要有 MSDN 订阅才能做到这一点。

首先你需要写一个在 DOS 上可以登录 MSDN 并下载文件的程序，然后用它下载 Windows 3.0 、Windows 95 、Windows 2000 Pro 、Windows XP Pro 、Windows Vista Pro 、Windows 7 Pro 、Windows 10 Pro，分别进行更新。

如果最终目标是 Windows 10 Home，则可以使用 Windows 98 SE 代替 Windows 2000 Pro 并把之后的版本都换成 Home 。

@nobody123123 #8 我在 #7 第二段已经提出了一个（在特定场景下）让 Alice 知道自己比 Bob 多 /少多少钱的方法了，反驳的方式应该是提出那个攻击的错误，或者（更好方式是）提供一个安全证明。

想当然安全不代表真的安全，你怎么知道“Alice 当然最终只会知道 a，b 的大小关系，不会知道自己比 Bob 具体多几块钱”呢？

我对知乎文章里提到的那个方案很怀疑——它可证明安全吗？显然为了正确性我们需要 ax+y 和 bx+y 作为整数小于 n，即没有“溢出”。

看起来并不安全，考虑 Alice 知道 Bob 比她多 1 块钱或者 2 块钱，在多 1 块钱的情况下 A 和 B 有 1/2 的概率奇偶性不同，在多 2 块钱的情况下 A 和 B 的奇偶性一定相同。这样经过一次计算，Alice 就可以得到 Bob 财富的信息。

而且百万富翁问题的第一个、最经典的解法是用乱码电路。当然既然本帖提到了同态加密，那么这个问题（半诚实安全性）可以很容易用带有电路保密性的全同态加密算法解决。

@sillydaddy #1 诚实提供输入的问题无法用密码学技术解决，需要使用机制设计。

@MeloForsaken #5 请你 cite 内容的时候给出链接。
另外你似乎没有搞懂 object monitor 和 ObjectMonitor 和 monitorenter 的关系。

Object monitor 是英文词组，意思是对象的管程，这是一个概念。
ObjectMonitor 是 JDK 源代码里类的名字，它是 object monitor 这个概念的是一个实现。
monitorenter 是一个 Java 字节码指令，它的意思是“进入对象的管程”，即它的作用对象是 object monitor 这个概念，至于是调用 ObjectMonitor 的方法还是怎么样，那是实现细节，取决于 object monitor 的状态。

要理解 Java 的同步机制，首先需要理解不特定于 Java 的同步机制。你问的问题似乎是没有搞清楚同步机制（管程）、Java 同步机制（ Java 对象的管程、monitorenter ）、Java 同步机制的实现（ ObjectMonitor 类）之间的关系。

换言之，你所谓的“重量级锁”是 ObjectMonitor，一个 Java 对象的管程可能是用 ObjectMonitor 实现的，也可能是用别的代码实现的，而且同一个对象的管程可以一会儿不用 ObjectMonitor 一会儿用，而 monitorenter 的实际效果是根据对象管程的实现决定的。

楼主看的文章里说 synchronized 锁有多种状态且会变化，然后又问 monitor （管程）锁是什么，显然是没有理解 synchronized 的原理、Java 对象结构、什么是 Java 对象的管程。

Java 对象的管程 = 可以用 synchronized 访问的那个同步机制，所谓 synchronized 不过是访问 monitor 的语法机制，而“synchronized 所用的锁会变化”就是说 Java 对象管程里的锁会变化。

区分三个概念：

- 识别文件处理程序的机制
- 文件格式
- 文件类型

“机制”在 Windows 世界里即 MIME 类型和扩展名，“格式”是通用、良定义概念，即所有有效文件内容构成的集合，楼主的问题在于不理解或者不能形成“类型”的良定义，且会混淆“格式”和“类型”的概念。

可以如此定义：文件是“A 类型”当且仅当它是 A 格式且具有正确识别 A 的处理程序的机制。

那么在 Windows 里，把磁盘上有效的 PNG 类型文件的扩展名改为 .jpg ，那么该文件仍然是 PNG 格式，但不再具有正确的识别机制，从而不是有效的 PNG 类型的文件，由于 PNG 格式和 JPEG 格式不相交，也可以推断该文件不是有效的 JPEG 格式的文件，从而也不可能是有效的 JPEG 类型的文件。

再举一个例子：考虑修改有效的 C++ 源代码类型的文件的扩展名为 .txt ，由于文本格式是 C++ 源代码格式的超集，可以判断修改后的文件仍然是有效的文本类型的文件，且仍然是有效的 C++ 源代码格式的文件，但不再是有效的 C++ 源代码类型的文件。

再举一个例子：考虑一个不使用扩展名和 MIME 类型的系统，在这个系统里修改扩展名不会对格式和类型产生任何影响。

@jinliming2 #31 在几乎所有现实的系统中，读取文件名比文件内容的前几个字节效率都要高很多倍。如果文件类型需要在 UI 上有所反映（例如不同类型的文件可以有不同的操作，而不仅仅是“打开”一个操作，或者不同类型的文件需要使用不同的图标等），那么通过文件内容识别绝对是糟糕透顶的设计。
另外几乎所有值得使用的浏览器都会在另存为的时候自动识别 MIME 类型并通过文件关联查询 MIME 类型对应的扩展名，然后帮用户加上。

@1YsX1 #4 这是双重理解错误。

1. FILE * 实际起效果的是“被指向的” FILE 结构，而不是 FILE * 本身，复制指针的值并不会复制 FILE 结构，因此操作的是同一个 FILE 。
2. fseek 传入的参数是 FILE * 而不是 FILE *&，并不存在“操作传入的变量”这种说法，它获得的永远是传入值的副本。把 fp 复制到 nowfp 再传入是多此一举，不会有任何效果。

我觉得很诡异的是楼主都用 win32com 了居然没发现 VBA 和 win32com 都只是 COM 的投影罢了。

为了数据安全最好还是不要对接这个系统，使用非伪随机的密钥以及使用密钥相关的 IV，都会破坏 AES 所有的安全保证。

直接不设置图标不就行了，还可以自适应系统更新后的图标变化。

@geelaw #3 Oops，太久没练习都生疏了。黎曼函数是那个只保留分母的……我提到的那个累积概率函数是严格单调且在且仅在无理数点连续的函数。

@LaureatePoet #2 如果你说的是 xD(x)，它只在 0 连续。仅在无理点连续的函数构造不那么简单，需要弄一个 Q 上每点概率都非零的概率测度，然后考虑它的累积概率函数。

极限存在和去心邻域连续是完全不同的概念，产生这样的错觉是非常严重的想当然。正确的直观：每个点的极限都只和这个点的去心邻域有关，而任意两个不同的点都可以找到分别的去心邻域使之不相交，特别地，这包括一个点的任意一个去心邻域里的任意一个点。因此一点处的极限不可能导出该点任何去心邻域里任何点的极限性质。