再读windows核心编程

追本溯源，每一种开发语言，每一种编译器，实际上是在对操作系统开放出的API的调用，因为涉及到了操作系统API，我们在编写程序时就不得不去考虑其应用环境。

当然在WIndows下进行开发，就要遵循windows的规范，重读Windows核心编程，注意到了很多有趣的地方，是以前没有注意到，比如作者jeffry,在关于线程和进程调度的优先级一章的描述:

Microsoft没有在文档中完成描述调度程序的行为

Microsoft不允许应用程序充分利用调度程序的特性

Microsoft明确告知用户，调度算法会发生变化，应用软件程序员应该防御性的编程。

初看起来简直是霸王条款的三条啊，我要在WIndows下进行应用程序的调度，但却没有调度相关的描述文档，还不允许去利用现有系统的调度行为，还需要自己去做防御。

但Jeffry先生的一个简单的解释却道出了很多，因为这样的约定应用程序就不会被当前操作系统的调度所牵累，可以在后续的系统中持续兼容，无论MicroSoft还是开发者，都不会因为将来的不确定性所牵累。microsoft可以在此基础上持续优化其内核，改善调度算法，如果能发现更好的调度算法，当前的调度行为必然发生改变。开发人员不用去关注操作系统的调度原理。

反思软件的架构设计，有时候在急于追求项目的进度或开发人员能力所限或开发人员图省事，软件设计中的过渡地带很少，模块之间扁平化严重，没有自己的界限，全部耦合在一起，牵一发而动全身，做不出好的软件产品和框架。

对于框架开发者，很多时候最纠结的在于，框架能提供的调度的东西的度，这个度实在是有点难把握，如果框架提供的约束太多，框架整体升级对应用的影响会很大，遇到重大理念变更时，很难平稳过渡，搞不好需要整体应用翻版，如果框架提供的约束太宽泛，会造成框架的使用不伦不类，一半精耕一半撂荒的感觉。