devblogs-microsoft-com-oldnewthing

本文是系列文章的第二部分，探讨如何在多个协程之间安全共享单个 Windows Runtime 异步操作 (IAsyncOperation) 的结果。文章提出了一种简单直接的方法：让每个协程轮流尝试获取结果，从而避免重复执行相同的异步操作。

本文探讨了如何缓存单个 Windows Runtime IAsyncOperation 的结果，并在多个协程之间共享该结果，同时确保缓存的有效性得到正确判断。文章介绍了缓存策略的基本思路，以及在何种条件下缓存被视为有效，为后续深入讨论奠定了基础。

本文探讨了不同语言（C#、JavaScript 与 C++/WinRT）在对待 Windows 运行时异步操作等待次数上的哲学差异。C# 和 JavaScript 允许对同一异步操作多次执行 await，而 C++/WinRT 则出于设计理念的不同对此进行了限制，文章深入分析了背后的原因。

本文探讨了 System.Diagnostics.Process 类的一个设计问题：某些属性只有在调用 Start 方法后才有效，但开发者可能在不恰当的时机访问它们，从而引发混淆。作者提出了一个假想的重设计方案，将这些属性放在只有调用 Start 后才能访问的位置，从而在 API 层面避免误用。

本文解释了 COM STA（单线程单元）线程看似不需要泵送消息的现象。关键在于：你需要在空闲时泵送消息，但采样代码可能从未处于空闲状态——它可能只是快速创建线程并直接退出，或者立即调用了 CoUninitialize。真正的 STA 线程在等待调用返回、处理跨单元通信或执行其他 COM 操作时，必须泵送消息以避免死锁和确保正常通信。

这是一个陷阱问题：你无法直接使用Win32结构。但或许可以"假装"实现。文章探讨了在Windows运行时（Windows Runtime）中无法直接使用传统Win32结构这一限制，并提出了可能的变通方法。

经典 TreeView 控件允许按名称或 lParam 进行排序，但不能同时使用两者。文章指出，如果你需要同时按两种方式排序，需要自行安排从一个推导出另一个的逻辑。

本文探讨了 ERROR_ARENA_TRASHED 错误代码的历史由来。该错误源于 DOS 时代的内存管理机制，当存储控制块被破坏时触发。文章追溯了这一错误代码在早期操作系统中的起源及其对后续 Windows 系统的影响。

该博客文章指出，奇偶标志位（Parity Flag）的相关问题从代码编写之日起就一直被错误报告，但如今已经没有人愿意花时间去调试它，反映了开发者对底层细节关注度的下降。

本文探讨了一个CreateFileMapping函数始终报告ERROR_ALREADY_EXISTS错误的案例。原因很简单：该映射对象确实已经存在。文章通过这个实例提醒开发者，在调用CreateFileMapping时需要注意检查返回值和错误码，以确保正确理解系统行为。

答案当然是兼容性问题。这篇文章解释了为什么 32 位 x86 系统上的 Windows 客户端版本会人为地将可用 RAM 限制在 4 GB，原因在于需要确保与大量依赖 32 位地址空间的驱动程序、应用和硬件保持兼容。

本文介绍了一种利用已知数据结构实现的算法，能够在常数空间和线性时间内删除目录中除最近10个文件外的所有文件。该算法高效且实用，适用于需要定期清理大量文件的场景。

本文分析了一个在用户更改键盘布局时导致程序卡死的案例。作者通过深入调试，揭示了键盘布局切换与某些消息处理逻辑之间的竞态条件，并解释了问题的根本原因。文章展示了在Windows开发中处理输入法变化时可能遇到的隐藏陷阱。

本文提供了关于如何控制哪些句柄被子进程继承的额外说明，重点介绍了将句柄放在私有容器中的方法。这有助于开发者更精确地管理进程间句柄传递，避免意外继承导致的安全问题或资源泄漏。

你可以通过追踪文件 ID 来增强使用 ReadDirectoryChangesW 监测重命名操作时的可靠性。该方法能更准确地识别文件是否被重命名，而非仅仅依赖路径变化。

否则，它会被映射回 8 位代码页。本文提醒开发者在升级资源字符串到 Unicode 时，必须显式添加 L 前缀，以避免因默认编码回退导致的数据丢失或乱码问题。

静态库无法应对 API 行为随链接 SDK 而变的设计。因为静态库一经编译便固定了其调用的 API 版本，无法像动态库那样根据运行时的 SDK 环境动态调整行为，从而可能导致兼容性问题。

本文探讨了一个关于TAB键的争议如何揭示了微软与IBM在组织架构上的差异。两个公司不同的管理结构和决策流程导致了对这一键盘功能的分歧，反映了大型科技企业间协作时可能出现的组织文化冲突。

你不需要告知 Windows。在文件系统层面，所有文件都是二进制文件。本文解释了为什么无需专门告知操作系统正在写入二进制文件。

本文介绍了跨进程读写锁实现中处理所有者进程终止（废弃）问题的恢复机制。当持有锁的进程意外退出时，系统需要检测并清理废弃的锁状态，以确保其他进程能够继续正常访问共享资源。这是有限读者读写锁系列文章的第四部分。

本文是系列文章的第二部分，继续探讨在跨进程环境下实现支持有限读者的读写锁。针对多个进程同时争抢读写锁时可能出现的问题，提出了"轮流机制"的解决方案，确保各方有序访问共享资源，避免死锁与资源饥饿。

本文介绍了在跨进程读写锁中，如何确保独占获取（写操作）在与共享获取（读操作）竞争时能获得公平的机会。作为系列第三部分，重点讨论了公平性机制的设计与实现。

本文是《开发跨进程读写锁》系列的第一部分，重点介绍了如何使用信号量来限制同时读取共享资源的读者数量。通过分析信号量机制，作者为后续构建完整的跨进程读写锁奠定了基础。

无论从哪个角度看，向C函数传递过少的寄存器参数都会导致严重问题，而安腾（Itanium）架构使情况变得更糟。本文分析了不同处理器架构下此类错误的具体影响，展示了问题的严重性。

本文探讨了在 scope_exit RAII 类型中防御异常的必要性与复杂性。虽然通过特殊处理可以防止析构函数在异常传播期间再次抛出异常，但作者指出这种防御机制可能并不值得——它增加了代码的复杂性和运行时开销，而实际收益有限。

本文讨论了卸载程序将代码注入到 Windows 资源管理器（Explorer）进程中所引发的一种典型崩溃问题。作者将这种情形比喻为“站在楼梯上却不小心将其摧毁”，形象地说明了卸载程序在试图清理自身时，反而破坏了正在依赖的运行环境，导致系统不稳定甚至崩溃。文章提醒开发者注意这种潜在的危险做法。

这篇文章介绍了所谓的"分形页映射"技术，即通过页表自身将页表结构映射到内存地址空间中的方法。这种递归映射机制在操作系统内存管理中具有重要应用价值。

本文探讨了为什么在汇编编程中，使用XOR指令将寄存器与自身进行异或操作来清零成为最流行的做法，而不是使用SUB减法指令。虽然两者都能实现清零效果，但XOR在某些处理器架构上具有性能优势。

即使像素可能不对齐，代码仍必须使用对齐访问来处理24位每像素格式。在具有存储体切换显存的显卡上，这需要特殊的编程技巧来确保正确的内存访问。

当编译器抱怨你没有写的代码时，需要找出是谁写了它们。本文探讨了C++编译错误中看似无关的"非法使用->"错误信息背后的真正原因。