为什么不搜索一下呢？

https://stackoverflow.com/questions/870173/is-there-a-limit-on-number-of-open-files-in-windows

C 运行时默认会限制最多同时有 512 个流式访问的 FILE，以及最多同时有 8192 个文件描述符，超过该限制则需要使用 Win32 CreateFile 系列 API，而一个进程可以同时使用的文件句柄数量的最大值至少是 16384。

看起来是 VirtualBox 没有采用 ClearType 反走样的设置

没有人想和 C++ 标准对着干，但是似乎不存在完美实现标准的编译器。

如果惟一可能的释放点是进程结束之前，那么是没有必要进行这个操作的，因为“大厦马上就要拆除了，没有必要打扫房间”。

不过你的第一个问题可以用简单的逻辑论证为什么你不需要释放：如果你释放了 strdup 产生的内存，则无法正确调用 execvp （除非你准备静态存储用来放置参数，但这显然无端增加麻烦，系统不会这样设计），因此你无法释放这段内存。

第二个问题取决于你的对内存泄露的定义。

解决这个问题的一个办法是用 LGPL 发布自己的开源项目。

你需要的是确定性加密（ deterministic encryption ）。有现成实现的加密算法通常具有 CPA 安全性（实际上一般是 AEAD 或 CCA ），密文必须比明文长，所以很可能需要自己造轮子。

欢迎来到 1998，就快要到千禧年了呢！

http://misweb.cbi.msstate.edu/~rpearson/tips/monitors.html

Imperative 是“祈使语气”，而不是“第一人称”，而且根据最先的原文这个只适用于对代码改变的描述（原因描述需要其他人称和语气）。

@x537196 #5 最简单的想法是用不 rich 的 TextBox。

@ysc3839 WinForm 默认情况下会对每个 UI 变化进行检查，如果当前线程不是建立该 UI 对象的线程则直接抛出异常。

你应该认为所有的 UI 对象都相当于一个 STA COM 对象，而 Windows 提供的 SendMessage 等 API 相当于是带有 marshalling 的，因此如果你尝试从另一个线程 SendMessage 到 UI 对象，就相当于你进行了正确的跨 apartment COM 调用。SetWindowText 最终也会变成 SendMessage，因此调用 Win32 API 会有正确的结果。

然而这样随意的编程方式很危险——因为 SendMessage 自己会进行消息处理，你的 WndProc 必须是 reentrant 才行，大多数人写出来的都不是。WinForm 的做法就是默认不允许跨线程操作，程序员需要显式表达线程切换——好习惯从最开始就要培养。

首先，大量进行 AppendText 本来性能就不行，使用 #1 的思路，限制 append 的频率，一次 append 多条消息（先拼好再送去 AppendText ）。另一个思路是使用性能更好的控件，例如这里完全没有体现为什么要用 RichText。

@mcdull619 #3 是强行背诵式回答问题，对 UI 的变化只能在 UI 线程上进行。

这个程序的注册完全没必要使用管理员权限，你可以注册到 HKCU\Software\Classes 里。
它不能正确处理从 Open/Save (common) dialog 里点击的情况。
它的位置更新是低效率的轮询。
它获取当前路径的方式应该是使用 IFolderView、IPersistFolder2 而不是尝试理解标题。

更好的策略是自己 host 一个 IExplorerBrowser 并嵌入 console emulator。

工具思路很好，代码一团糟，是未来的兼容性炸弹而且未遵守现在 Windows 编程的正确实践。

Store 是水果，TestData 是橘子，OnFinishCallback 是“能处理任意水果”的类型。因为 test1 初始化的表达式不能处理任意水果（只能处理橘子），所以不行。

用术语来说是 A => void 对 A 是逆变，如果 B is-an A，则 (A => void) is-a (B => void)，而不是反过来。

Windows 8/8.1 的“开始”比 10 的不知道好多少倍，磁贴图标也是。

@Osk #1 无数个版本以前，我感觉 2013 就有

希望微软赶紧砍了 OneNote WinRT 版本。

用 display: table 也可以

@liaoliaojun #35 提前存储素数是完全不安全的做法。只要 N 的一个质因数存在于预先存定的质数表里，就可以迅速分解 N。