汇编语言

汇编语言和CPU以及内存,端口等硬件知识是连在一起的. 这也是为什么汇编语言没有通用性的原因. 下面简单讲讲基本知识(针对INTEL x86及其兼容机)
============================
x86汇编语言的指令,其操作对象是CPU上的寄存器,系统内存,或者立即数. 有些指令表面上没有操作数, 或者看上去缺少操作数, 其实该指令有内定的操作对象, 比如push指令, 一定是对SS:ESP指定的内存操作, 而cdq的操作对象一定是eax / edx.

在汇编语言中,寄存器用名字来访问. CPU 寄存器有好几类, 分别有不同的用处:

1. 通用寄存器:
EAX,EBX,ECX,EDX,ESI,EDI,EBP,ESP(这个虽然通用,但很少被用做除了堆栈指针外的用途)

这些32位可以被用作多种用途,但每一个都有"专长". EAX 是"累加器"(accumulator), 它是很多加法乘法指令的缺省寄存器. EBX 是"基地址"(base)寄存器, 在内存寻址时存放基地址. ECX 是计数器(counter), 是重复(REP)前缀指令和LOOP指令的内定计数器. EDX是...(忘了..哈哈)但它总是被用来放整数除法产生的余数. 这4个寄存器的低16位可以被单独访问,分别用AX,BX,CX和DX. AX又可以单独访问低8位(AL)和高8位(AH), BX,CX,DX也类似. 函数的返回值经常被放在EAX中.

ESI/EDI分别叫做"源/目标索引寄存器"(source/destination index),因为在很多字符串操作指令中, DS:ESI指向源串,而ES:EDI指向目标串.

EBP是"基址指针"(BASE POINTER), 它最经常被用作高级语言函数调用的"框架指针"(frame pointer). 在破解的时候,经常可以看见一个标准的函数起始代码:

push ebp ;保存当前ebp
mov ebp,esp ;EBP设为当前堆栈指针
sub esp, xxx ;预留xxx字节给函数临时变量.
...

这样一来,EBP 构成了该函数的一个框架, 在EBP上方分别是原来的EBP, 返回地址和参数. EBP下方则是临时变量. 函数返回时作 mov esp,ebp/pop ebp/ret 即可.

ESP 专门用作堆栈指针.

2. 段寄存器:
CS(Code Segment，代码段) 指定当前执行的代码段. EIP (Instruction pointer, 指令指针)则指向该段中一个具体的指令. CS:EIP指向哪个指令, CPU 就执行它. 一般只能用jmp, ret, jnz, call 等指令来改变程序流程,而不能直接对它们赋值.
DS(DATA SEGMENT, 数据段) 指定一个数据段. 注意:在当前的计算机系统中, 代码和数据没有本质差别, 都是一串二进制数, 区别只在于你如何用它. 例如, CS 制定的段总是被用作代码, 一般不能通过CS指定的地址去修改该段. 然而,你可以为同一个段申请一个数据段描述符"别名"而通过DS来访问/修改. 自修改代码的程序常如此做.
ES,FS,GS 是辅助的段寄存器, 指定附加的数据段.
SS(STACK SEGMENT)指定当前堆栈段. ESP 则指出该段中当前的堆栈顶. 所有push/pop 系列指令都只对SS:ESP指出的地址进行操作.

3. 标志寄存器(EFLAGS):

该寄存器有32位,组合了各个系统标志. EFLAGS一般不作为整体访问, 而只对单一的标志位感兴趣. 常用的标志有:

进位标志C(CARRY), 在加法产生进位或减法有借位时置1, 否则为0.
零标志Z(ZERO), 若运算结果为0则置1, 否则为0
符号位S(SIGN), 若运算结果的最高位置1, 则该位也置1.
溢出标志O(OVERFLOW), 若(带符号)运算结果超出可表示范围, 则置1.

JXX 系列指令就是根据这些标志来决定是否要跳转, 从而实现条件分枝. 要注意,很多JXX 指令是等价的, 对应相同的机器码. 例如, JE 和JZ 是一样的,都是当Z=1是跳转. 只有JMP 是无条件跳转. JXX 指令分为两组, 分别用于无符号操作和带符号操作. JXX 后面的"XX" 有如下字母:

无符号操作: 带符号操作:
A = "ABOVE", 表示"高于" G = "GREATER", 表示"大于"
B = "BELOW", 表示"低于" L = "LESS", 表示"小于"
C = "CARRY", 表示"进位"或"借位" O = "OVERFLOW", 表示"溢出"
S = "SIGN", 表示"负"
通用符号:
E = "EQUAL" 表示"等于", 等价于Z (ZERO)
N = "NOT" 表示"非", 即标志没有置位. 如JNZ "如果Z没有置位则跳转"
Z = "ZERO", 与E同.

如果仔细想一想,就会发现 JA = JNBE, JAE = JNB, JBE = JNA, JG = JNLE, JGE= JNL, JL= JNGE, ....

4. 端口

端口是直接和外部设备通讯的地方。外设接入系统后，系统就会把外设的数据接口映射到特定的端口地址空间，这样，从该端口读入数据就是从外设读入数据，而向外设写入数据就是向端口写入数据。当然这一切都必须遵循外设的工作方式。端口的地址空间与内存地址空间无关，系统总共提供对64K个8位端口的访问，编号0-65535. 相邻的8位端口可以组成成一个16位端口，相邻的16位端口可以组成一个32位端口。端口输入输出由指令IN,OUT,INS和OUTS实现，具体可参考汇编语言书籍。

汇编语言的准备知识--给初次接触汇编者(2)

汇编指令的操作数可以是内存中的数据, 如何让程序从内存中正确取得所需要的数据就是对内存的寻址.

INTEL 的CPU 可以工作在两种寻址模式:实模式和保护模式. 前者已经过时,就不讲了, WINDOWS 现在是32位保护模式的系统, PE 文件就基本是运行在一个32位线性地址空间, 所以这里就只介绍32位线性空间的寻址方式.

其实线性地址的概念是很直观的, 就想象一系列字节排成一长队,第一个字节编号为0, 第二个编号位1, .... 一直到4294967295(十六进制FFFFFFFF,这是32位二进制数所能表达的最大值了). 这已经有4GB的容量! 足够容纳一个程序所有的代码和数据. 当然, 这并不表示你的机器有那么多内存. 物理内存的管理和分配是很复杂的内容, 初学者不必在意, 总之, 从程序本身的角度看, 就好象是在那么大的内存中.

在INTEL系统中, 内存地址总是由"段选择符:有效地址"的方式给出.段选择符(SELECTOR)存放在某一个段寄存器中, 有效地址则可由不同的方式给出. 段选择符通过检索段描述符确定段的起始地址, 长度(又称段限制), 粒度, 存取权限, 访问性质等. 先不用深究这些, 只要知道段选择符可以确定段的性质就行了. 一旦由选择符确定了段, 有效地址相对于段的基地址开始算. 比如由选择符1A7选择的数据段, 其基地址是400000, 把1A7 装入DS中, 就确定使用该数据段. DS:0 就指向线性地址400000. DS:1F5278 就指向线性地址5E5278. 我们在一般情况下, 看不到也不需要看到段的起始地址, 只需要关心在该段中的有效地址就行了. 在32位系统中, 有效地址也是由32位数字表示, 就是说, 只要有一个段就足以涵盖4GB线性地址空间, 为什么还要有不同的段选择符呢? 正如前面所说的, 这是为了对数据进行不同性质的访问. 非法的访问将产生异常中断, 而这正是保护模式的核心内容, 是构造优先级和多任务系统的基础. 这里有涉及到很多深层的东西, 初学者先可不必理会.

有效地址的计算方式是: 基址+间址*比例因子+偏移量. 这些量都是指段内的相对于段起始地址的量度, 和段的起始地址没有关系. 比如, 基址=100000, 间址=400, 比例因子=4, 偏移量=20000, 则有效地址为:

100000+400*4+20000=100000+1000+20000=121000. 对应的线性地址是400000+121000=521000. (注意, 都是十六进制数).

基址可以放在任何32位通用寄存器中, 间址也可以放在除ESP外的任何一个通用寄存器中. 比例因子可以是1, 2, 4 或8. 偏移量是立即数. 如: [EBP+EDX*8+200]就是一个有效的有效地址表达式. 当然, 多数情况下用不着这么复杂, 间址,比例因子和偏移量不一定要出现.

内存的基本单位是字节(BYTE). 每个字节是8个二进制位, 所以每个字节能表示的最大的数是11111111, 即十进制的255. 一般来说, 用十六进制比较方便, 因为每4个二进制位刚好等于1个十六进制位, 11111111b = 0xFF. 内存中的字节是连续存放的, 两个字节构成一个字(WORD), 两个字构成一个双字(DWORD). 在INTEL架构中, 采用small endian格式, 即在内存中,高位字节在低位字节后面. 举例说明:十六进制数803E7D0C, 每两位是一个字节, 在内存中的形式是: 0C 7D 3E 80. 在32位寄存器中则是正常形式,如在EAX就是803E7D0C. 当我们的形式地址指向这个数的时候,实际上是指向第一个字节,即0C. 我们可以指定访问长度是字节, 字或者双字. 假设DS EDX]指向第一个字节0C:

mov AL, byte ptr DS EDX] ;把字节0C存入AL
mov AX, word ptr DS EDX] ;把字7D0C存入AX
mov EAX, dword ptr DS EDX] ;把双字803E7D0C存入EAX

在段的属性中,有一个就是缺省访问宽度.如果缺省访问宽度为双字(在32位系统中经常如此),那么要进行字节或字的访问,就必须用byte/word ptr显式地指明.

缺省段选择：如果指令中只有作为段内偏移的有效地址，而没有指明在哪一个段里的时候，有如下规则：

如果用ebp和esp作为基址或间址，则认为是在SS确定的段中；
其他情况，都认为是在DS确定的段中。

如果想打破这个规则，就必须使用段超越前缀。举例如下：

mov eax, dword ptr [edx] ;缺省使用DS,把DS EDX]指向的双字送入eax
mov ebx, dword ptr ES EDX] ;使用ES:段超越前缀，把ES EDX]指向的双字送入ebx

堆栈：

堆栈是一种数据结构，严格地应该叫做“栈”。“堆”是另一种类似但不同的结构。SS 和 ESP 是INTEL对栈这种数据结构的硬件支持。push/pop指令是专门针对栈结构的特定操作。SS指定一个段为栈段，ESP则指出当前的栈顶。push xxx 指令作如下操作：

把ESP的值减去4；
把xxx存入SS ESP]指向的内存单元。

这样，esp的值减小了4，并且SS ESP]指向新压入的xxx. 所以栈是“倒着长”的，从高地址向低地址方向扩展。pop yyy 指令做相反的操作，把SS ESP]指向的双字送到yyy指定的寄存器或内存单元，然后把esp的值加上4。这时，认为该值已被弹出，不再在栈上了，因为它虽然还暂时存在在原来的栈顶位置，但下一个push操作就会把它覆盖。因此，在栈段中地址低于esp的内存单元中的数据均被认为是未定义的。

最后,有一个要注意的事实是,汇编语言是面向机器的,指令和机器码基本上是一一对应的,所以它们的实现取决于硬件.有些看似合理的指令实际上是不存在的,比如:

mov DS edx], ds ecx] ;内存单元之间不能直接传送
mov DS, 1A7 ;段寄存器不能直接由立即数赋值
mov EIP, 3D4E7 ;不能对指令指针直接操作.

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
探索Windows的内部机制所需的基础 [转]

索Windows的内部机，分析Windows各种系统机能的实现方式，并不那么难。只要有一定的基础就可以开始这方面的学习。以我的学习经历来说，我觉得在开始深入学习Windows之前，最好有如下的基础：

1.       熟练使用C语言   你至少要对C中的指针了如指掌，知道如何使用指针访问数组。知道数组并不是仅可通过下标来访问的。如果你看过很多遍《C缺陷和陷阱》并认为这本书很棒。那就太好了。

2.       一定的汇编基础   了解基本的汇编语句，对x86架构的汇编指令有基本的了解。如果在学校认真学习过汇编语言这门课，那么就足够了。在深入学习Windows时，你会遇到不少汇编代码，很多时候你需要使用一些工具来反编译一些东西，此时你汇编水平的高低就直接有影响了。

3.       对Windows API很熟悉 可以直接用API开发小规模的程序，了解Windows的消息机制，至少要看过《Windows程序设计》（上、下），如果深入学习过《Windows核心编程》那就更好。

4.       掌握基本的数据结构   至少应该达到能很容易的用C实现一个双向链表吧？基本上掌握了《数据结构》这门课，就差不多了。否则，学习中遇到的很多复杂结构，将会使你陷入云雾里，不知如何下手。

5.       学习过《操作系统》 对处理器调度、虚拟内存、I/O设备管理有基本的认识。知道什么是中断，引入中断的目的对CPU的工作方式有基本了解。这门课算是总的理论基础课了。你对这门课的掌握程度将直接影响你的学习进度，尤其是你要看《Windows Internals 4th》这本书时。

6.       对面向对象有一定的了解  

上面是一些基本的硬性要求，下面的是一些软性要求：

1.       要经常问：为什么？   没有质疑的精神，探索从何而言？

2.       要有耐心   学习是一个较长的过程，探索Windows内部时，有时确实让人很有挫折感，这时千万不要急躁，耐心才能保证你终有所成。

3.       要细心     这个。。。。不用说了吧？

4.       要多思考   不要把书中内容当作金科玉律。

5.       要多总结   这样知识才能变成自己的。

当然，有一本好书，也是必须的。我推荐如下：

《Inside Windows 2000》或者《Windows Internals 4th》

《Undocumented Windows 2000 Secrets》

或许有人认为没有必要探索Windows的内部机制，这个问题仁者见仁、智者见智，不过我相信你如果对Windows的内部机制有很深的了解，那么你一定能写出更高效、更能利用系统优势的程序来。并且，当程序出现Bug时，我相信你更有把握解决它们。知其然，而不知其所以然的感觉，确实很糟J

上述仅是个人所见，不足之处还请多多指教。

IMaxSoft 发表于2005-05-27 9:39 AM
还有一点,熟练编写WDM驱动,熟练使用SoftIce,Windbg,
IDA等调试反汇编工具,深厚的汇编功底,HOHO

baiyuanfan 发表于2005-06-01 11:57 AM
IA32 ASM非常重要，还要大致知道C如何被编译为ASM

jg 发表于2005-06-07 4:49 PM
要看你想要在windows上面作甚么，如果是用户模式写一些小的开发，又根本不在意性能，我觉得没有必要了解细节，不如花时间在别的地方。但如果你需要写驱动，或者写服务器上的东东，就需要了解你所关心的细节。但我的体会是光靠看一两本书是根本没用的，真正写起东西来怎么都不灵，在微软不同的build之间的差别都很大，很都认为应该可以work的东西就是不行，在微软的文档里又找不到细节，难道真的要连上windbg一个一个的看数据结构。linux也有同样的问题，尽管你可以看代码，可是又有几个人有时间看完你需要了解的那部分代码呢？

Kendiv 发表于2005-06-07 6:05 PM
只要在Windows上开发涉及系统层的东西，我认为还是需要了解系统整体的运行机理的，要知道系统的各个组件之间有着千丝万缕的联系。在对整体有了一定的了解后，在根据具体需要进行深入挖掘。Windows个版本之间的差别肯定是存在的，有时即使打了个补丁，可能就会有很大不同了。但，这些只是表面而已，很多本质的东西还是一致的。要不然也不会有操作系统这门课了，即使Linux很多东西与Windows也是一致的。如果只是开发用户态的小东西，那么VB、Delphi就足够了。确实用不着如此深入。不过，我这里的东西不是给这方面的人准备的。这些是给那些永远喜欢问为什么的朋友准备的。

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
转帖]微软事务处理服务(MTS)介绍

　　微软事务处理服务(MTS)代表了一类新的产品，它使开发和布置高性能的、可变尺度的、可靠的分布式应用程序更加容易。这是通过将以组件为基础的开发和布置技术与事务处理控制器的可变尺度性、可靠性结合起来而实现的。

　　为什么使用微软事务处理服务？

　　微软事务处理服务被设计用于使的构造 高性能的、可变尺度的、可靠的internet和intranet应用程序更加容易。多年以前，我们就能构造这些应用程序了，但它所要求的才赋和投资超出了大多数公司的能力。

　　MTS以已被证实的事务处理方法为基础，但它的重要性超出了事务处理控制器的领域，它对分布式、以组件为基础的服务器应用程序定义了一个简单的 编程模式和执行环境。

　　应用程序由能够提供商业应用功能的微软ActiveX组件组合而成。这些组件似乎被开发用于单用户。通过在MTS环境下安装这些组件来执行它们，服务器应用程序能高性能的、可靠的自动改变尺度以支持同时存在的多客户。

　　MTS 被特别设计用于允许服务器应用程序在一个很大的用户范围内变化（从小的单用户系统到高容量的网络服务器）。它还具有通常只有高档的事务处理系统才具有的鲁棒性和完整性。

　　下面这部分对开发一个优秀的服务器应用程序的复杂性作一个简单的回顾。

　　我们从三个不同角度来讨论这个问题：

　　第一、它强调了一个网络服务器为提供合理水平服务所必须作的工作。

　　第二、它论述了当构造以组件为基础的应用程序所引起的问题。

　　第三、它描述了即使是在错误发生时，维持应用程序的完整的重要性。

　　MTS提供了一个应用程序编程模式，使得开发者避开了这些复杂之处，允许开发者将精力集中于程序的功能上，并降低了构造程序所需的费用和时间。

　　服务器基本结构：

　　服务器要有一个高级的基础。从零开始建造一个网络应用服务器不是一件容易的事。完成实际的商业功能，例如处理在线书库的订单，实际只是工作的一小部分。典型的服务器系统必须有一个高级基础来获取可接受的性能和尺度。

　　应用程序服务开发者必须亲自经常开发基本构件中的许多部分。举个例子，序调用提供了丰富的服务，系统开发者仍必须作下面的工作：

　　注册目录系统服务器；

　　管理服务器处理池和线程池；

　　最后，服务器需要为多用户请求提供的服务管理线程池，而不只是针对一个单用户。使多客户同时请求使用共享数据和资源的要求同步。这要求高级锁定协议能解释死锁、条件竞争、资源匮乏及其他性能上的问题。管理客户内容，包括数据库连接和数据结构的全视图。（目标视图）

　　客户缓冲状况以改善潜在慢速网络通行。

　　完成安全保障以确保商业功能和对象仅提供给被授权者。

　　完成管理和确认工具以允许服务器的远程安装和管理。

　　MTS提供了一个应用程序/服务器基本结构来满足上面的要求。

　　构造以组件为基础的应用程序：

　　从组件构造应用程序对开发者有极大的吸引力并且是面向对象计算的早期目标之一。由于它提供了一个自然的方法来封装商业功能，因而对开发服务器应用程序更具吸引力。

　　然而，组件工程程序比它原来显现出来的要困难。早期对象系统的一个根本弱点是缺乏共同的框架来允许开发者无论是在同一进程或是交叉进程，都能将不同部分创造的对象结合到一个完整的程序里。组件对象模型（COM）解决了这个问题。

　　然而，简单的用一个COM模型来从组件构造服务器应用程序是不够的。该组件必须使用共同的服务框架。那些自己构造服务器框架的开发者使用其他组的组件开发程序的机会就会很小。

　　MTS程序工程师和编程界面提供了一个共同的框架来构造以组件为基础的服务器应用程序。

　　保持程序的完整性：

　　非常重要的一点是，商业系统应能准确的维持商业状态。例如，一个在线书库必须可靠的跟踪订单。若不然，将会产生巨大的收入损失。现存的订单可能丢失或在取订单、填订单的时候有延时，不满意的用户可能会转到别处作生意。

　　维持商业系统的完整性从不容易，特别在发生错误以后。具有讽刺意义的是，即使计算机变的越来越可靠，系统作为一个整体变得更加不可靠。对提供internet和intranet连接到数十、数百、甚至可能数万个服务器上的无数桌式计算机来讲，错误是常事。

　　对分布式程序的要求使问题复杂化。商业事务，如订书，逐渐地卷入多个服务者，必须证实其信用，书必须船运，必须管理存货目录，并且客户必须有资金。这一切都使在多服务器上的多个数据库更新成为必须。分布式开发者必须预料到程序的某一部分能在其他部分发生错误后继续运行。这些防错方案是单个程序的好几倍。

　　商业程序经常被要求将多个工作协调为单个商业事务。一个在线书库绝对不能在没有处理恰当的订单前就去安排装运的日程，同时也不可能向用户收取费用而不通知其送货日期。协调这些工作使它们都发生或都不发生，若无特殊系统支持是非常困难的。

　　即使在发生错误时要确保程序最小单位的更新，是很不容易的。尤其当一个应用程序分布在多个数据库和系统上时。使用在设计上隐藏了其可完成性的多种组件造成了这个问题。

　　当多个用户获取同一组件时程序也必须能提供一致的行为。对同一本书同时的定单不应产生只送一本书给两个用户的情况。除非程序被正确书写，资源竞争最终将引起不一致性。这些问题很难解决并将花很多钱。并且随着程序增长和费用增多而更可能发生。这也是由于使用组件引起的。

　　MTS使用以组件为基础的编程完整事务使得你能开发出鲁棒，分布式的，以组件为基础的程序。

　　MTS工程师

　　这部分对MTS工程师主要元素作一简介

　　这些元素包括：

　　ActiveX组件，完成应用程序功能。

　　事务管理服务执行者，为程序组件运行服务。

　　服务处理，提供存放程序组件的代理处理环境。

　　资源管理者(RM)，管理程序的可耐阶段，例如包括相关数据库系统和事务性消息队列。

　　资源分配者，管理进程内组件非耐久性共享数据，例子包括数据库连接池，管理队列。

　　微软分布事务协调者，允许通过多个资源管理者，分配者和程序组件协调事务。

　　微软事务服务器组件：程序组件使商业行为模式化。这些组件了完整商业规则，提供视图和程序状态变化情况。考虑在线书库的例子。用在数据库系统中的记录代表商务的耐久状态，如挂起订单，方便的目录，可接受帐单。应用程序组件刷新状态以反映如新定单和目录发送的变化。

　　MTS程序组件是ActiveX处理中服务器（DDL）。通过使用Microsoft Visual Basic，Visual C++，Visual J++或任何与ActiveX相兼容的开发工具，你可以创造并实现这些组件。

　　ActiveX以COM为基础，包括：

　　界面概念，客户从对象请求服务的方法；

　　通过处理器和机器界限与透明对象的连接；

　　确认组件，动态装载和执行组件的机制；

　　对象能通过MTS工程师支持多界面，并提供给用户查询支持对象的特殊界面的方法。并允许组件提供不同水平的功能并逐渐引入新版本。

　　MTS扩展了COM以提供一个通用的服务器程序框架。除了上面提到的COM内在的特性外，MTS还处理服务器注册，进程,线程管理，内容管理，共享资源的管理和同步化，以及以组件为基础的安全性管理。

　　将事务引入到程序模板作为获得最小单元更新和在组件、数据库系统及网络边界达到一致性的机制。每个组件都有一个事务属性指出组件的事务性语义。这允许事务性内容被MTS自动管理。MTS使用户避免了复杂的服务事件，使用户可以专注于完成商业功能。由于在MTS下运行组件可充分利用事务服务程序，用户可以把程序当成各自独立的状态来编写程序。MTS处理同时事件，资源池，内容管理及其他系统水平的复杂的事件。事务系统，与数据库服务器和其他类型的资源管理协同工作，确保同时事务是强大的、一致的、有恰当的分离性，并且，一旦完成，变化是可耐久的。

　　应用程序作为ActiveX的组件来分配，称为包裹。包裹定义了错误分离和信任边界。

　　事务管理服务执行器：

　　事务管理服务执行器是一个动态连接库（DDL），它对事务管理服务组件提供运行时服务。这些服务包括线程管理和内容管理。这些动态连接库被加载到应用程序组件的宿主进程中，并且在后台透明的执行。

　　服务进程：

　　服务进程是应用程序组件执行的宿主系统进程，对数十、成百、上千个客户提供服务。你可以配置多个服务进程在一个计算机上执行。每个服务进程反映了一个分立的信任边界和错误绝缘域。

　　其他的进程环境也能让应用程序组件在其上运行。这使你可以分配应用程序以适合不同的分布、性能和错误绝缘要求。例如，你可以配置MTS组件直接加载到微软SQL服务器上或微软网络信息服务器（IIS）上。你还可以直接将它们配置到客户进程中去。

　　资源管理者：

　　资源管理者是一种系统服务，它管理耐久数据。服务器应用程序使用资源管理者维持应用程序的耐久状态，如方便的存货目录记录，到期订单以及可接受帐目。资源管理者于事务管理者协同工作，以保证应用程序的最小性和分立性。微软SQL服务器，耐久的消息队列和事务性的文件系统都是资源管理者的例子。

　　最小性保证了在一个特殊事务中所有的更新都能完成（并能持久）或者被放弃并回到原来的状态。一致性意味着一个事务是系统状态的正确转化，保存了状态变量。

　　分立使得同时事务不会得知其他事务的信息和未完成的结果，以免引起应用程序状态的不稳定。资源管理者应用以事务为基础的同步协议来分离活动事务管理程序未完成的工作。

　　耐久性意味着对已管理资源（如数据库记录）的更新，能不受错误的影响，包括通讯错误，进程错误和服务系统错误。事务管理的日志甚至能允许你在磁盘介质失效后恢复耐久状态。

　　最小性和分立性协同工作使得事务管理程序看起来是立刻发生的。事务管理程序的中间状态对外面来说是不可见的，并且产生了这样一个结果：或者所有的工作都完成了，或者没有一个完成了。这允许我们在编写应用程序组件时，可以把事务管理程序当作顺序发生而不考虑其同时性，这对应用程序开发者是一个非常大的简化。

　　MTS支持资源管理者来完成OLE事务管理协议或X/Open XA协议。有开发资源管理者的工具包。

一个资源分配者在一个进程内代表应用程序组件管理非耐久性的共享数据。资源分配者与资源管理者相似，但没有担保或耐久性。MTS提供两种资源分配者：

　　ODBC资源分配者

　　共享属性管理者

　　并提供了一个工具包来开发资源分配者

　　ODBC资源分配者：

　　ODBC资源分配者使用标准开放数据连接界面为事务服务器管理数据连接池。ODBC资源分配者维护数据库连接池，快速和有效的分配给对象连接。连接被自动列在对象的事务处理程序中。资源分配者能自动的回收和重用连接。ODBC资源分配者是一个动态连接库，它对用户透明的提供这种功能并且内构在MTS的特性里。

　　共享属性管理者：

　　共享特性管理者对定义的应用程序，进程宽度，属性（变量）进行同步管理。你可以使用它来维护一个Web页面冲浪计数器，常量数据的缓冲，或者提供高速缓冲来避免数据库的过热点。（例如产生唯一的接收成员）。

　　微软分布式事务管理协调者：

　　微软分布式事务管理协调者是一个系统服务，用于协调跨越多个资源管理者的事务。即使事务可能在分立的计算机上跨越了多个资源管理者，它也能当作最小事务来完成。

　　微软分布式事务管理协调者最早作为微软SQL服务器6.5版本的一部分发布，并且包含在MTS里。它完成了两阶段承诺协议来保证事务处理结果（完成的或抛弃的）在所有的资源管理者中是一致的。

　　微软分布式事务管理协调者确保最小性，不管是在错误（节点冲突、网络崩溃或资源管理者、应用程序的错误动作），条件竞争（事务管理程序开始工作而一个资源管理者正在放弃）还是可提供性（一个资源管理者装备了一个事务但没有返回）发生时。

　　微软分布式事务管理协调者支持符合OLE事务管理或X/Open XA协议的资源管理者。

　　结论：

　　微软事务管理服务器将改变人们开发商业应用程序的方法。组件基础技术、面向对象技术与针对分布式、在线事务处理的时间验证技术的结合将使得布置由被购买的通常构造的组件组成的应用程序更加容易。经济上的优点将产生商业组件的一个新市场。这种情况，反过来说，使得原来没有解决的问题得到商业上的解决。

　　微软事务处理服务已经分两阶段展开。初始时，分布式事务处理协调器在1996年4月作为微软SQL服务器版本3.5的一部分发布。它提供了通过相异数据存储库的分布式两阶段承诺。

　　在1996年11月，微软事务服务器发布。它提供了可靠的、可变尺度的、分布式的运行ActiveX组件所需的编程环境和运行时执行环境。

　　了解更多的信息：

　　查询微软事务管理服务器的最新信息，可到其Web站点（http://www.microsoft.com/transaction/）

　　也可以参考<<事务处理：概念和技术>> 作者：Jim Gray&Andreas Reuter ,Morgan Kaufmann出版社，1993年。

　　本文所包括的内容作为最新出版物代表了微软公司在所讨论问题上的最新观点。因为微软必须对市场情况作出反应，微软不承诺解释这些内容，也不保证在出版日期以后的内容的准确性。