好的资料可以给大家带来技术上面更多的想法，《深入解析Windows操作系统》是一本以Linux系统为基础讲解OS架构与硬件关系的图书，对于喜欢Linux的朋友可以考虑阅读该书，在《Unix操作系统设计》中由于以Unix V为版本讲解的Unix系统，多少有些许看得不尽人意的地方;而目前针对FreeBSD的资料比较少，所以如果大家想从整个系统的角度来分析一个类Unix系统的话，这本书将是一个好资料，而且还会帮你纠正很多写代码的弊病。　　如果说Intel出了汇编语言，那么《80x86汇编语言与计算机体系结构》则是告诉你汇编程序是怎么编写的，每个指令在何种情况下占用了几个字节，一个程序在编译、连接后的opcode(机器码)是如何产生的，作者会很细心的告诉你一个mov指令占用一个时钟周期，在数据传值上经常使用mov、xchg，还会告诉你mov指令占用的opcode字节。　　(一)需要理解的几个概念　　在开始针对Windows的机制分析前，需要注意一些基础概念，有了这些概念，然后结合工具的使用，会有利于对Windows机制的分析。　　API：Application Program Interface，应用程序接口，系统中有几千个API函数。　　Plat software Development Kit：平台开发套间，在开发VC程序时，更好的习惯是安装最新的SDK包，里面的内容绝对比你安装过时的MSDN多很多，同时还有很多例子代码告诉你Windows程序的规范是怎么写的。　　DDK：设备驱动开发包。　　进程的概念：　　进程只是一个容器而已，因为这个容器用来存放主线程，在Windows程序中，无论是main、WinMain函数创建的都不是进程，而是主线程，主线程才为一个进程内的主体。理解线程的概念，对于开发Windows程序有很大的帮助。进程创建后，根据其各种环境条件创建了主线程，主线程也分为两个部分，User Mode Thread(用户模式线程)和Kernel Mode Thread(内核模式线程)。对于主线程而言，我们可做的坏事情(从线程角度考虑，抛弃进程的各种环境条件)不是很多，当我们调用CreateThread函数创建一个线程，或者创建一个线程池时，我们可以做的坏事情就会相对较多，因为MS提供了一部分管理线程的函数，同时也公布了一组管理线程的内核数据结构，该数据结构为CONTEXT;从CONTEXT数据结构是依靠CPU类型来看，该结构的确是有些底层了;对于该结构的描述，在《Windows核心编程》有所阐述。通过初始化一个CONTEXT结构，通过GetThreadContext函数可以获取当前线程的CPU寄存器状态，通过SetThreadContext函数我们可以设置当前线程的CPU寄存器状态。不过这里有些麻烦的是，当我们使用GetThreadContext和SetThreadContext函数时，线程必须是不活动的，因为一个用户态可见的活动线程是异步执行的，可能你使用上述函数时得到的值与实际值有出入。前段时间在搞线程池时问过同事关于异步的问题，同事给我了很好的答案，通过一段时间的编写测试代码，对该处有了更深的认识。　　线程的概念：　　有必要把下面的内容单独出来，上面只是通过主线程的一些看法，以及CONTEXT结构的特殊性。既然谈及到CONTEXT结构，有个比较有意思的事情，我昨天早上起床背了几个单词后突然想起了这个结构，于是我把ntoskrnl.exe进行了逆向，在ntoskrnl.exe内也存在一个CONTEXT结构，而且与用户态的结构值完全相同，但这并不说明内核态会引用用户态的该结构，前面提及的该结构底层的说法只是说明该结构保存获得的内容比较底层而已。如果大家认真看过《Windows核心编程》中关于对该结构描述时，作者夸张的做法后，其实作者有些地方也不是很对的，当然每个人理解技术的情况不同，如果这里解释有误，还是需要大家的指点。　　提及CONTEXT结构，而且上面也提及可以通过Get(Set)ThreadContext函数实现对该结构的修改，那么我们是否可以实现通过对该结构的操作来实现用户态下线程的暂停和恢复运行?答案是可以，但是需要进行特殊的处理，因为线程是异步执行的，其堆栈环境也不象进程那样稳定，换句话说进程只要主线程在运行，那么其堆栈环境会稳定的存在;但是线程(指使用CreateThread创建的线程)与之不同，一旦线程返回结束，或者调用线程结束函数，则在线程创建时的堆栈会自动被内核清理掉。但是使用CONTEXT结构来管理线程的话，就需要对线程的运行机理非常的熟悉，否则很难实现对其管理。