NTSTATUS
  FltReadFile(
    IN PFLT_INSTANCE  InitiatingInstance,
    IN PFILE_OBJECT  FileObject,
    IN PLARGE_INTEGER  ByteOffset OPTIONAL,
    IN ULONG  Length,
    OUT PVOID  Buffer,
    IN FLT_IO_OPERATION_FLAGS  Flags,
    OUT PULONG  BytesRead OPTIONAL,
    IN PFLT_COMPLETED_ASYNC_IO_CALLBACK  CallbackRoutine OPTIONAL,
    IN PVOID  CallbackContext OPTIONAL
    ); 

参数

InitiatingInstance

Opaque instance pointer for the minifilter driver instance that is initiating the read request. This parameter is required and cannot be NULL.

FileObject

Pointer to a file object for the file that the data is to be read from. This file object must be currently open. Calling FltReadFile when the file object is not yet open or is no longer open (for example, in a pre-create or post-cleanup callback routine) causes the system to ASSERT on a checked build. This parameter is required and cannot be NULL.

ByteOffset

Pointer to a caller-allocated variable that specifies the starting byte offset within the file where the read operation is to begin.If this offset is supplied, or if the FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET flag is specified in the Flags parameter, FltReadFile does not update the file object’s CurrentByteOffset field.If the file object that FileObject points to was opened for synchronous I/O, the caller of FltReadFile can specify that the current file position offset be used instead of an explicit ByteOffset value by setting this parameter to NULL. If the current file position is used, FltReadFile updates the file object’s CurrentByteOffset field by adding the number of bytes read when it completes the read operation.

If the file object that FileObject points to was opened for asynchronous I/O, this parameter is required and cannot be NULL.

Length

Size, in bytes, of the buffer that the Buffer parameter points to.

Buffer

Pointer to a caller-allocated buffer that receives the data that is read from the file.

Flags

Bitmask of flags specifying the type of read operation to be performed.

标志	含义
FLTFL_IO_OPERATION_DO_NOT_UPDATE_BYTE_OFFSET	Minifilter drivers can set this flag to specify that FltReadFile should not update the file object’s CurrentByteOffset field.
FLTFL_IO_OPERATION_NON_CACHED	Minifilter drivers can set this flag to specify a noncached read, even if the file object was not opened with FILE_NO_INTERMEDIATE_BUFFERING.
FLTFL_IO_OPERATION_PAGING	Minifilter drivers can set this flag to specify a paging read.

 

BytesRead

Pointer to a caller-allocated variable that receives the number of bytes read from the file. If CallbackRoutine is not NULL, this parameter is ignored. Otherwise, this parameter is optional and can be NULL.

CallbackRoutine

Pointer to a PFLT_COMPLETED_ASYNC_IO_CALLBACK-typed callback routine to call when the read operation is complete. This parameter is optional and can be NULL.

CallbackContext

Context pointer to be passed to the CallbackRoutine if one is present. This parameter is optional and can be NULL. If CallbackRoutine is NULL, this parameter is ignored. 

返回值

FltReadFile returns the NTSTATUS value that was returned by the file system.

注释

微过滤器调用 FltReadFile 从一个打开的文件中读取数据。

FltReadFile 创建一个读请求并发送到微过滤器驱动挂载的进程后到文件系统。指定的进程之上的挂载进程则收不到读请求。

FltReadFile 在下列条件成立时，准备非缓存I/O：

• 调用者在参数 Flags 中设置了 FLTFL_IO_OPERATION_NON_CACHED 标志；
• 文件对象使用非缓存I/O打开的。通常是在调用 FltCreateFile, FltCreateFileEx, 或 ZwCreateFile 时，在参数CreateOptions 标志中指定了FILE_NO_INTERMEDIATE_BUFFERING 。 

Noncached I/O imposes the following restrictions on the parameter values passed to FltReadFile:

• The buffer that the Buffer parameter points to must be aligned in accordance with the alignment requirement of the underlying storage device. To allocate such an aligned buffer, call FltAllocatePoolAlignedWithTag.
• The byte offset that the ByteOffset parameter points to must be a nonnegative multiple of the volume’s sector size.
• The length specified in the Length parameter must be a nonnegative multiple of the volume’s sector size.

If an attempt is made to read beyond the end of the file, FltReadFile returns an error.

If the value of the CallbackRoutine parameter is not NULL, the read operation is performed asynchronously.

If the value of the CallbackRoutine parameter is NULL, the read operation is performed synchronously. That is, FltReadFile waits until the read operation is complete before returning. This is true even if the file object that FileObject points to was opened for asynchronous I/O.

If multiple threads call FltReadFile for the same file object, and the file object was opened for synchronous I/O, the Filter Manager does not attempt to serialize I/O on the file. In this respect, FltReadFile differs from ZwReadFile.

Requirements

IRQL: PASSIVE_LEVEL

Headers: Declared in fltkernel.h. Include fltkernel.h.

• 文件(Files，Vista及后续操作系统)
• 实例
• 卷
• 流
• 流句柄（File objects）
• Transactions(Files，Vista及后续操作系统)

除了卷上下文必须在非分页的内存池上分配，其他的既可以在非分页也可以在分页内存池中分配。

过滤管理器在他们挂载的对象删除后、微过滤器驱动实例从卷上解挂载或微过滤器卸载，自动删除相关的上下文。

注册上下文类型

当微过滤器驱动在DriverEntry中调用 FsRegisterFilter时，必须注册好每个要使用的上下文类型。

要注册上下文类型，微过滤器驱动创建一个类型为 FLT_CONTEXT_REGISTRATION 的变长数组。保持在 FLT_REGISTRATION 结构的 ContextRegistration 域中，传递到 FltRegisterFilter 函数的 Registration 参数。数组中的成员的顺序没有关系，但最后一个成员必须是 {FLT_CONTEXT_END}。

对于微过滤器驱动使用到的每一个上下文类型，FLT_CONTEXT_REGISTRATION 结构必须至少提供一个上下文定义。每一个FLT_CONTEXT_REGISTRATION结构定义了上下文的类型、大小和其他信息。

微过滤器驱动调用FltAllocateContext创建一个新的上下文，过滤管理器使用size参数

对于固定大小的上下文，FLT_CONTEXT_REGISTRATION结构的Size成员指定了字节大小，上下文的大小最大为MAXUSHORT(64KB)。0也是一个有效的值。过滤管理器用旁视列表分配固定大小的上下文。

对于不定大小的上下文，Size成员必须设置为FLT_VARIABLE_SIZED_CONTEXTS。过滤管理器直接从分页或非分页的内存池中分配不定长的上下文。

FLT_CONTEXT_REGISTRATION结构的Flags成员，可以指定FLTFL_CONTEXT_REGISTRATION_NO_EXACT_SIZE_MATCH。如果微过滤器驱动使用定长的上下文，并且指定了这个标志，上下文的大小大于等于请求的长度的话，过滤管理器从旁视列表里分配内存。否则上下文大小必须等于请求大小。

对于一个给定的上下文类型，微过滤器驱动可以支持3种固定大小（每一个大小不同）的上下文定义和1种变长定义。【更多信息，参见FLT_CONTEXT_REGISTRATION】

微过滤器驱动支持可选上下文释放前的清理回调例程。【参见 PFLT_CONTEXT_CLEANUP_CALLBACK】

微过滤器驱动可以定义一个他自己的分配、释放回调例程。【参见PFLT_CONTEXT_ALLOCATE_CALLBACK 和 PFLT_CONTEXT_FREE_CALLBACK】。

下面是从CTX示例中的部分代码，展示了一个用于注册实例、文件、流和文件对象（流句柄）的FLT_CONTEXT_REGISTRATION结构数组。

#include 
#include 
#include 
#include 
#include 
#pragma comment(lib, "Setupapi.lib")

int main( int argc, char *argv[ ], char *envp[ ] )
{
    HDEVINFO hDevInfo;
    SP_DEVINFO_DATA DeviceInfoData;
    DWORD i;

    // Create a HDEVINFO with all present devices.
    hDevInfo = SetupDiGetClassDevs(NULL,
        0, // Enumerator
        0,
        DIGCF_PRESENT | DIGCF_ALLCLASSES );

    if (hDevInfo == INVALID_HANDLE_VALUE)
    {
        // Insert error handling here.
        return 1;
    }

    // Enumerate through all devices in Set.

    DeviceInfoData.cbSize = sizeof(SP_DEVINFO_DATA);
    for (i=0;SetupDiEnumDeviceInfo(hDevInfo,i,
        &DeviceInfoData);i++)
    {
        DWORD DataT;
        LPTSTR buffer = NULL;
        DWORD buffersize = 0;

        //
        // Call function with null to begin with,
        // then use the returned buffer size
        // to Alloc the buffer. Keep calling until
        // success or an unknown failure.
        //
        while (!SetupDiGetDeviceRegistryProperty(
            hDevInfo,
            &DeviceInfoData,
            SPDRP_DEVICEDESC,
            &DataT,
            (PBYTE)buffer,
            buffersize,
            &buffersize))
        {
            if (GetLastError() ==
                ERROR_INSUFFICIENT_BUFFER)
            {
                // Change the buffer size.
                if (buffer)
     LocalFree(buffer);
                buffer = (char *)LocalAlloc(LPTR,buffersize);
            }
            else
            {
                // Insert error handling here.
                break;
            }
        }

        printf("Result:[%s]\n",buffer);

        if (buffer) LocalFree(buffer);
    }

    if ( GetLastError()!=NO_ERROR &&
         GetLastError()!=ERROR_NO_MORE_ITEMS )
    {
        // Insert error handling here.
        return 1;
    }

    //  Cleanup
    SetupDiDestroyDeviceInfoList(hDevInfo);

    return 0;
}

    从网上查到一段说明，可以说是迄今最后的解释，在家里看了N天，似同天书。

晕晕乎乎中，似乎有所顿悟，何不用一个具体的类比，也解释一下IRP到底是怎么回事，所以喝了二两二锅头，斗胆把上面的10段话作如下的翻译，有翻译不妥当之处，望大大们指正：

本文仅用于学习交流，不负版权责任。翻译者楚狂人，有问题可与我联系，qq16191935。MSN walled_river@hotmail.com.

我以前不大明白Windows的文件系统和缓冲管理器之间的关系。仅仅知道Cc开头的系列调用是缓冲管理器提供的，文件系统中可以调用。也知道缓冲对于文件系统的意义，在于缓冲读写操作，使磁盘得到高效的利用。

为了翻译了这些资料，我也大致明白了文件系统和缓冲管理器之间的互动。windows的文件系统和缓冲管理器之间是相互调用的关系，双向沟通。总的来说，是缓冲管理器提供一些调用给文件系统，文件系统注册一些回调函数给缓冲管理器，而且缓冲管理器会发IRP给文件系统来处理。

首先文件系统如果想要实现缓冲读写，那么肯定要调用缓冲管理器提供的调用。（如对于缓冲读，不直接自己读磁盘，而是调用CcCopyRead),但是缓冲管理器自然还是要通过文件系统来实际读磁盘。因此缓冲管理器会发出IRP来给文件系统进行处理。这样，文件系统就要分别缓冲管理器发来的请求和用户进程发来的请求分别处理了。

把不同的请求放在同一个例程中处理，这正是设计上最令人恼火的地方。不过理解了这一点之后，你也就大致明白缓冲管理器和文件系统是如何交互的了。

NT 文件系统缓冲管理器

本文中,我们的同缓冲管理器的运行例程的一个基础描述.此外,给出了一些例程的使用例子.也参考了MS IFS 中能找到的代码.

缓冲管理器概述

缓冲管理器是一个纯软件组件.和Windows NT的内存管理器紧密的结合为一个整体.同时使文件系统数据的缓冲和虚拟内存管理系统也结合在一起.一些操作系统单独实现他们的文件系统,所以他们有不同的数据缓冲方式.但由于物理内存的有限性,这样的缓冲一样必须合理的管理.而且内存被这样的缓冲用了,就不能在系统中再做其他的用途了.

所以Window NT 缓冲管理器的一个关键优点,就是允许我们在文件系统缓冲和程序运行使用物理内存之间保持一个平衡.当一个应用正在消耗内存,用来进行文件数据缓冲的内存可能被缩减到接近0.结果系统让物理内存得到了更好的使用,最终提供了更好的性能.

文件系统还有一个使用Cache管理器的关键原因.一个文件可能被标准的文件系统接口访问.比如读和写,也有可能通过内存管理器被做为内存映射文件访问.有时两种访问方式被用在同一个文件上.这是Cache管理器提供一个机制,建立这两种访问方式之间的桥梁,以确保数据的可靠性.

Cache管理器数据结构

文件系统和Cache管理器之间的接口是一种过程上的接口.所有的Cache管理器用到的数据结构,有必要通过一个文件联系起来.但是实际上这些内部接口对文件系统是透明的.在这里我们描述这些文件系统和Cahce管理器共享的关键的数据结构.

缓冲控制块(BCB,Buffer Control Block)

如果一个文件的一部分被映射到一个系统内存地址,Cahce管理器内部使用缓冲控制块来记录.有时文件系统进行某些临界操作的时候,需要在内存中锁定一些数据.所以这个结构必须暴露给文件系统使用:

缓冲控制块的大部分是部可见的.开头的一部分暴露给文件系统:

typedef struct _PUBLIC_BCB {
 CSHORT NodeTypeCode;
 CSHORT NodeByteSize;
 ULONG MappedLength;
 LARGE_INTEGER MappedFileOffset;
} PUBLIC_BCB,*PPUBLIC_BCB;

开始的两个域是Windows数据结构的标准域,说明数据结构的类型和长度.后边的两个域是文件系统感兴趣的,说明了这个文件被这个特殊的缓冲控制块所管理的内容范围.

文件大小信息

文件系统和内存管理器都维护文件大小的信息.当文件系统建立了一个文件的映射,它记录了文件的当前大小.以后的任何改动同样被提交给Cache管理器.

Cache管理器用三个值用来表示文件的大小:

typedef struct _CC_FILE_SIZES {
 LARGE_INTEGER AllocationSize;
 LARGE_INTEGER FileSize;
 LARGE_INTEGER ValidDataLength;
} CC_FILE_SIZES,*PCC_FILE_SIZES;

这些域的名字容易混淆.比如AllocationSize不是说给这个文件分配实际的物理空间,而是当前已经分配的空间中能容纳的数据总量.对一般的文件系统来说,上边两个数据当然应该是一样的.但是,对一个支持数据压缩或者扩展的文件系统而言,这个值表示当前控件中所能容纳的数据量(而不是空间大小).

AllocationSize被内存管理器用来得到section object.section object被用来觉得一个文件是如何映射到内存的,所以AllocationSize总是至少和文件一样大.缓冲管理器和内存管理起没有考虑当文件系统把AllocationSize设置得比file size小的情况.系统会因数据结构的混乱而崩溃.

FileSize表示了文件数据中最后一个有效的字节的位置,一般是文件结束标记.

缓冲管理器回调

文件系统和内存管理器之间的互动是通过一系列的回调实现的.这些回调函数被注册给Cache管理器之后被Cahce管理器用来确保数据结构在一个文件系统操作之前被\”锁定\”.

Windows NT假设资源如何被文件系统,Cahce管理器和内存管理器使用有一个严格的顺序.这个顺序确保死缩不会发生.反之则可能死锁.一般来说,文件系统首先得到资源.然后是Cache管理器,最后是内存管理器.

因此,这些回调被内存管理器用来维护它的层级:这些回调有:

typedef BOOLEAN (*PACQUIRE_FOR_LAZY_WRITE) ( IN PVOID Context, IN BOOLEAN Wait );
typedef VOID (*PRELEASE_FROM_LAZY_WRITE) ( IN PVOID Context );
typedef BOOLEAN (*PACQUIRE_FOR_READ_AHEAD) ( IN PVOID Context, IN BOOLEAN Wait, );
typedef VOID (*PRELEASE_FROM_READ_AHEAD ( IN PVOID Context ); 

typedef struct _CAHHE_MANAGER_CLALLBACKES {
 PACQUIRE_FOR_LAZY_WRITE AcquireForLazyWrite;
 PRELEASE_FROM_LAZY_WRITE ReleaseFromLazyWrite;
 PACQUIRE_FOR_READ_AHEAD AcquireForReadAhead;
 PRELEASE_FROM_READ_AHEAD ReleaseFromReadAhead; 

} CACHE_MANAGER_CALLBACKS,*PCACHE_MANAGER_CLALLBACKS;

注意这些回调分别被缓冲管理器的两个部分使用.首先是延迟写,负责把脏的(修改过的)缓冲数据写回文件系统.另一种是预读,预先的读取文件,给用户调用的读返回信息.

首先,在设计上很重要的是要理解你的文件系统应该避免那些情况,而哪些是不需要避免的.比如说,没有理由把用户应用的缓冲读操作和缓冲管理器的延迟写序列化.它们互无影响.但是,你需要避免用户调用的非缓冲写操作改变文件的长度和缓冲管理器延迟写冲突.

NT的文件系统使用两个资源结构来实现这个.所有这些资源可以被不同的操作系统组件来使用,通过使用共同的头,铁别是头中的Resource域和PageingIoResource域.缓冲管理器并不直接去获取这些资源,它通过调用文件系统中的回调函数来获取这些必要的资源.

请注意这些回调例程必须由你的文件系统提供,他们不是可选的.如果你不能提供,那么系统会崩溃.

微软的IFSKit中每个文件系统的例子都含有这些例程.比如延迟写的位置入下:

其他的例程基本上可以在同一个文件中找到.

下面的代码是一个回调例程的例子:

static BOOLEAN OwAcquireForLazyWrite(PVOID Conetext,BOOLEAN Wait)
{
POW_FCB fcb = (POW_FCB)Context;
BOOLEAN result;

// 打开文件上的锁
result = OwAcquireResourceExclusiveExp(&fcb->Resource,Wait);
if(!result) {
// 我们没有能获得资源
return result;
}

// 我们得到了资源,我们必须:
// (1)保存当前线程的线程id(用于释放)
// (2)设置顶级irp一个假的值.
// 无论如何,当前线程id在设置之前应该为0(必须是没有使用的)

OwAssert(!fcb->ResourceThread);
fcb->ResourceThread = OwGetCurrentResourceThread();
return (TRUE);
}

CcCanIWrite

因为一个应用程序可能修改内存中的数据的速度超过写磁盘到数据上的能力,导致虚拟内存系统可能被数据所\”饱和\”.这可能导致虚拟系统发生内存枯竭的情况.为了避免这点,文件系统必须和虚拟系统合作探测这种条件.缓冲管理器提供的一个关键操作之一就是CcCanIWrite,原型如下:

NTKERNELAPI BOOLEAN CcCanIWrite (
IN PFILE_OBJECT FileObject,
IN ULONG BytesToWrite,
IN BOOLEAN Wait,
IN BOOLEAN Retrying
);

如果返回了FALSE,那么文件系统必须延迟脏页面的写入来避免内存枯竭.典型的内存枯竭症状是一些调用返回NO_PAGES_AVAILABLE.

文件系统必须排列这些写操作的重试并发送.文件系统可以通过内部的发送机制来发送,也可以使用这个例程.

CcDeferWrite

你的文件系统可以调用FsRtlCopyWirte,这样就不必直接调缓冲管理器了.这样内部的延迟写实际上是用这个例程实现延迟写的.

CcCopyRead

只要一个文件系统建立了一个缓冲(通过CcInitializeCacheMap调用),它就可以使用FsRtl例程(比如FsRtlCopyRead)或者这个例程.一般FsRtlCopyRead用来实现Fast IO的读,而这个例程一般用来实现IRP_MJ_READ,原型如下:

NTKERNELAPI BOOLEAN CcCopyRead (
IN PFILE_OBJECT FileObject,
IN PLARGE_INTERGER FileOffset,
IN ULONG Length,
IN BOOLEAN Wait,
OUT PVOID Buffer,
OUT PIO_STATUS_BLOCK IoStatus
);

FileObject含有一个指向SectionObjectPointer的指针.当数据从缓冲拷贝到用户缓冲区间(也就是这里的Buffer所指的区域),SectionObjectPointer是被缓冲管理器所使用.当然这里假设缓冲已经实现初始化过了.

Wait说明调用这是否希望阻塞一段不定长的时间.比如可能要等待获取一个锁.这个参数应该被看成一个\”提示\”而不是一个\”确保\”.比如说,如果一个磁盘io有必要结束这个操作,这个操作可能继续运行.即使Wait的值是FALSE.

Buffer是调用者提供的缓冲.它不一定是一个有效的缓冲.失败的情况下,这个调用会抛出一个异常.一个文件系统驱动应该捕获这个异常并返回一个错误给应用程序.

IoStatus用来收集操作的完成状态,以及有多少个字节被成功的读取了.

请注意缓冲管理器的这个调用可能导致分页交换.这可能导致文件系统驱动处理实际的分页交换读写的操作的例程重入.

(译者注:假设文件系统中的读处理例程中调用了CcCopyRead从缓冲中读,这可能导致缓冲进行页面交换来读取硬盘.而读取硬盘的操作又是文件系统的读处理例程进行的,因此这个读处理例程是可能重入的.).

CcCopyWrite

当一个文件系统已经初始化了一个缓冲(使用CcInitializeCachedMap调用),它可以使用FsRtl例程(FsRtlCopyWrite)或者这个例程.一般的,FsRtlCopyWrite用来实现FastIo写.而这个例程用来实现普通的IRP_MJ_WRITE,原型如下:

NTKERNELAPI BOOLEAN CcCopyWrite (
IN PFILE_OBJECT FileObject,
IN PLARGE_INTEGER FileOffset,
IN ULONG Length,
IN BOOLEAN Wait,
IN PVOID Buffer
);

参数同上一函数.

请注意这个操作可能导致一个缓冲页面的部分内容被改写.这种情况下,这个页面的内容首先从磁盘上读出,然后被修改.因此,文件系统用来处理文件被修改导致的页面失败的例程有可能被重入.

CcDeferWrite

你的文件系统必须限制数据写入的最大流量.为了简化这个实现,缓冲管理器提供一个简单的机制来把这些写操作排队,直到虚拟内存系统能容纳它们.当CcCanIWrite调用返回失败的时候,这些由你的文件系统所注册的回调函数来完成.

这个回调函数的原型为:

Typedef VOID (*PCC_POST_DEFERRED_WRITE) (
IN PVOID Context1,
IN PVOID Context2
);

这些上下文指针由你的文件系统使用,座位建立延迟写过程的一部分.CcDeferWrite的原型如下:

NTKERNELAPI VOID CcDeferWrite (
IN PFILE_OBJECT FileObject,
IN PCC_POST_DEFERRED_WRITE PostRoutine,
IN PVOID Context1,
IN PVOID Context2,
IN ULONG BytesToWrite,
IN BOOLEAN Retrying);

FileObject标明要写的文件.

PostRoutine是文件系统驱动提供的回调函数,当虚拟内存系统已经发生了改变,附加的写操作可以被允许执行了,缓冲管理器会调用这个回调.

Context1和Context2指正是文件系统驱动所定义的.当写文件被允许的时候传给上面的回调函数.

BytesToWrite参数说明要写的字节数.虚拟内存系统用这个信息判断这个操作是否安全的(基于可用的页).

Retrying参数表示这是第一次尝试(Retrying是FALSE)还是一次延后的尝试(Retrying是TRUE).

CcGetDirtyPages

这个例程列出来仅仅为了完整性.这个用于文件系统利用windows nt的内部日志机制.文件系统中一般不使用.原型如下:

NTKERNELAPI LARGE_INTEGER CcGetDirtyPages (
IN PVOID LogHandle,
IN PDIRTY_PAGE_ROUTINE DirtyPageRoutine,
IN PVOID Context1,
IN PVOID Context2
);

CcGetFileObjectFromBcb

一个私有的缓存控制块包含一个FileObject的指针.虚拟内存系统用此来跟踪文件缓冲的信息.FileObject因此可以从一个BCB中获得.这是一个必要的调用.原型如下:

NTKERNELAPI PFILE_OBJECT CcGetFileObjectFromBcb (
IN PVOID Bcb
);

CcGetFileObjectFromSectionPtrs

一个文件建立缓冲时,缓冲管理器使用FileObject作为参数调用CcInitializeCacheMap来生成一个新的section object.这个对象用于缓冲文件数据.所以当缓冲管理器得到了这个文件的缓冲数据,原来的FileObject被虚拟内存系统用于各种不同的IO操作.

给定的任意一个FileObject的SectionObjectPointer,这个例程可以告诉文件系统实际被虚拟内存系统所使用的实际file object.原型如下:

NTKERNELAPI PFILE_OBJECT CcGetFileObjectFromSectionPtrs (
IN PSECTION_OBJECT_POINTERS SectionObjectPointer
);

WINDOWS文件过滤系统驱动开发的两个经典例子，Filemon与SFilter，初学者在经过一定的理论积累后，对此两个例子代码的研究分析，会是步入驱动开发殿堂的重要一步，相信一定的理论积累以及贯穿剖析理解此两个例程后，就有能力开始进行文件过滤系统驱动开发的实际工作了。
对于SFilter例子的讲解，楚狂人的教程已经比较流行，而Filemon例子也许因框架结构相对明晰，易于剖析理解，无人贴出教程，本人在剖析Filemon的过程中积累的一些笔记资料，陆续贴出希望对初学者有所帮助，并通过和大家的交流而互相提高。

Filemon学习笔记 第一篇：

Filemon的大致架构为，在此驱动程序中，创建了两类设备对象。
一类设备对象用于和Filemon对应的exe程序通信，以接收用户输入信息，比如挂接或监控哪个分区，是否要挂接，是否要监控，监控何种操作等。此设备对象只创建了一个，在驱动程序的入口函数DriverEntry中。此类设备对象一般称为控制设备对象，并有名字，以方便应用层与其通信操作。
第二类设备对象用于挂接到所须监控的分区，比如c：，d：或e：，f：，以便拦截到引应用层对该分区所执行的读，写等操作。此类设备对象为安全起见，一般不予命名，可根据须监控多少分区而创建一个或多个。

驱动入口函数大致如下：

NTSTATUS
DriverEntry(
    IN PDRIVER_OBJECT DriverObject,
    IN PUNICODE_STRING RegistryPath
    )
{
    NTSTATUS                ntStatus;
    PDEVICE_OBJECT          guiDevice;
    WCHAR                   deviceNameBuffer[]  = L"\\Device\\Filemon";
    UNICODE_STRING          deviceNameUnicodeString;
    WCHAR                   deviceLinkBuffer[]  = L"\\DosDevices\\Filemon";
    UNICODE_STRING          deviceLinkUnicodeString;
    ULONG                   i;

    DbgPrint (("Filemon.SYS: entering DriverEntry\n"));
    FilemonDriver = DriverObject;

    //
    // Setup the device name
    //
    RtlInitUnicodeString (&deviceNameUnicodeString,
                          deviceNameBuffer );

    //
    // Create the device used for GUI communications
    //此设备对象用来和用户交互信息
    ntStatus = IoCreateDevice ( DriverObject,
                                sizeof(HOOK_EXTENSION),
                                &deviceNameUnicodeString,
                                FILE_DEVICE_FILEMON,
                                0,
                                TRUE,
                                &guiDevice );

    //
    // If successful, make a symbolic link that allows for the device
    // object's access from Win32 programs
    //
    if(NT_SUCCESS(ntStatus)) {

        //
        // Mark this as our GUI device
        //
        ((PHOOK_EXTENSION) guiDevice->DeviceExtension)->Type = GUIINTERFACE;

        //
        // Create a symbolic link that the GUI can specify to gain access
        // to this driver/device
        //
        RtlInitUnicodeString (&deviceLinkUnicodeString,
                              deviceLinkBuffer );
        ntStatus = IoCreateSymbolicLink (&deviceLinkUnicodeString,
                                         &deviceNameUnicodeString );
        if(!NT_SUCCESS(ntStatus)) {

            DbgPrint (("Filemon.SYS: IoCreateSymbolicLink failed\n"));
            IoDeleteDevice( guiDevice );
            return ntStatus;
        }

        //
        // Create dispatch points for all routines that must be handled.
        // All entry points are registered since we might filter a
        // file system that processes all of them.
        //
        for( i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++ ) {

            DriverObject->MajorFunction[i] = FilemonDispatch;
        }
#if DBG
        //
        // Driver unload is only set if we are debugging Filemon. This is
        // because unloading a filter is not really safe - threads could
        // be in our fastio routines (or about to enter them), for example,
        // and there is no way to tell. When debugging, we can risk the
        // occasional unload crash as a trade-off for not having to
        // reboot as often.
        //
        // DriverObject->DriverUnload = FilemonUnload;
#endif // DBG

        //
        // Set up the Fast I/O dispatch table
        //
        DriverObject->FastIoDispatch = &FastIOHook;

    } else {

        //
        // If something went wrong, cleanup the device object and don't load
        //
        DbgPrint(("Filemon: Failed to create our device!\n"));
        return ntStatus;
    }

    //
    // Initialize the name hash table
    //
    for(i = 0; i < NUMHASH; i++ ) HashTable[i] = NULL;

    //
    // Find the process name offset
    //
    ProcessNameOffset = FilemonGetProcessNameOffset();//为了得到当前进程名字

    //
    // Initialize the synchronization objects
    //
#if DBG
    KeInitializeSpinLock( &CountMutex );
#endif
    ExInitializeFastMutex( &LogMutex );
    ExInitializeResourceLite( &FilterResource );
    ExInitializeResourceLite( &HashResource );

    //
    // Initialize a lookaside for file names
    //
    ExInitializeNPagedLookasideList( &FullPathLookaside, NULL, NULL,
				     0, MAXPATHLEN, 'mliF', 256 );

    //
    // Allocate the first output buffer
    //
    CurrentLog = ExAllocatePool( NonPagedPool, sizeof(*CurrentLog) );
    if( !CurrentLog ) {

        //
        // Oops - we can't do anything without at least one buffer
        //
        IoDeleteSymbolicLink( &deviceLinkUnicodeString );
        IoDeleteDevice( guiDevice );
        return STATUS_INSUFFICIENT_RESOURCES;
    }

    //
    // Set the buffer pointer to the start of the buffer just allocated
    //
    CurrentLog->Len  = 0;
    CurrentLog->Next = NULL;
    NumLog = 1;

    return STATUS_SUCCESS;
}

在此驱动入口点函数中，主要做了生成新的设备对象，此设备对象用来和应用层信息交互，比如应用层向驱动传递需要挂接或者监控的分区盘符，或者是否挂接盘符，是否监控操作等。
上面创建设备对象的代码为：

ntStatus = IoCreateDevice ( DriverObject,
                                sizeof(HOOK_EXTENSION),
                                &deviceNameUnicodeString,
                                FILE_DEVICE_FILEMON,
                                0,
                                TRUE,
                                &guiDevice );

    //
    // If successful, make a symbolic link that allows for the device
    // object's access from Win32 programs
    //
    if(NT_SUCCESS(ntStatus)) {

        //
        // Mark this as our GUI device
        //
        ((PHOOK_EXTENSION) guiDevice->DeviceExtension)->Type = GUIINTERFACE;

        //
        // Create a symbolic link that the GUI can specify to gain access
        // to this driver/device
        //
        RtlInitUnicodeString (&deviceLinkUnicodeString,
                              deviceLinkBuffer );
        ntStatus = IoCreateSymbolicLink (&deviceLinkUnicodeString,
                                         &deviceNameUnicodeString );
        if(!NT_SUCCESS(ntStatus)) {

            DbgPrint (("Filemon.SYS: IoCreateSymbolicLink failed\n"));
            IoDeleteDevice( guiDevice );
            return ntStatus;
        }

上面代码完成的功能为创建了用于与应用层交互的控制设备对象，名字在参数&deviceNameUnicodeString,中。设备对象创建成功后又调用IoCreateSymbolicLink创建了一个符号连接，以便于应用层交互。 在入口点函数DriverEntry代码中，还有一处代码： ProcessNameOffset = FilemonGetProcessNameOffset();//为了得到当前进程名字。此函数体如下：

ULONG
FilemonGetProcessNameOffset(
    VOID
    )
{
    PEPROCESS       curproc;
    int             i;

    curproc = PsGetCurrentProcess();//调用PsGetCurrentProcess取得KPEB基址

    //然后搜索KPEB，得到ProcessName相对KPEB的偏移量
    // Scan for 12KB, hoping the KPEB never grows that big!
    //
    for( i = 0; i < 3*PAGE_SIZE; i++ ) {

        if( !strncmp( SYSNAME, (PCHAR) curproc + i, strlen(SYSNAME) )) {

            return i;
        }
    }

    //
    // Name not found - oh, well
    //
    return 0;

这个函数通过查找KPEB (Kernel Process Environment Block)，取得进程名，GetProcessNameOffset主要是调用PsGetCurrentProcess取得KPEB基址，然后搜索KPEB，得到ProcessName相对KPEB的偏移量，存放在全局变量ProcessNameOffset中，得到此偏移量的作用是：无论当前进程为哪个，其名字在KPEB中的偏移量不变，所以都可以通过此偏移量得到。而在入口点函数DriverEntry执行时，当前进程必为系统进程，所以在此函数中方便地根据系统进程名SYSNAME（#define SYSNAME “System”）得到此偏移量。

分发函数剖析：
在入口点函数中，通过代码：

for( i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++ ) {

            DriverObject->MajorFunction[i] = FilemonDispatch;
}

简单地把各个分发例程设置成了FilemonDispatch; 然后我们追踪其函数体：

NTSTATUS
FilemonDispatch(
    IN PDEVICE_OBJECT DeviceObject,
    IN PIRP Irp
    )
{
    //
    // Determine if its a request from the GUI to us, or one that is
    // directed at a file system driver that we've hooked
    //
    if( ((PHOOK_EXTENSION) DeviceObject->DeviceExtension)->Type == GUIINTERFACE ) {

        return FilemonDeviceRoutine( DeviceObject, Irp );

    } else {

        return FilemonHookRoutine( DeviceObject, Irp );
    }
}

函数体先判断需要处理IRP包的设备对象的类型，看是属于控制设备对象，还是属于用于挂接并监控文件读写操作的过滤设备对象。如果是属于后者 则进入：FilemonHookRoutine( DeviceObject, Irp )
此函数是拦截文件操作的中心，在其中获得了被操作的文件名字，并且根据操作类型，在
switch( currentIrpStack->MajorFunction ) {
}
中针对不同的MajorFunction，打印出相关操作信息。
因此函数体太长 不再全部列出。
其函数体总体框架为：得到被操作的文件名字，打印相关操作信息，然后下发IRP到底层驱动。
在下发IRP到底层驱动处理前，本层驱动必须负责设置下层IO堆栈的内容。这样下一层驱动调用IoGetCurrentIrpStackLocation()时能得到相应的数据。
设置下层IO堆栈的内容，一般用两个函数来实现：
IoCopyCurrentIrpStackLocationToNext( Irp )
此函数一般用在本驱动设置了完成例程时调用，把本层IO _STACK_LOCATION 中的参数copy到下层，但与完成例程相关的参数信息例外。因为本驱动设置的完成例程只对本层驱动有效。
IoSkipCurrentIrpStackLocationToNext(Irp)
此函数的作用是：直接把本层驱动IO堆栈的内容设置为下层驱动IO堆栈指针的指向。因两层驱动IO堆栈的内容完全一致，省却copy过程。

而在Filemon的处理中，它用了一个特别的办法，没有调用此两个函数，FilemonHookRoutine函数体里面有三句代码：

PIO_STACK_LOCATION  currentIrpStack = IoGetCurrentIrpStackLocation(Irp);
PIO_STACK_LOCATION  nextIrpStack    = IoGetNextIrpStackLocation(Irp);

*nextIrpStack = *currentIrpStack;//此步设置了下层驱动的IO_STACK_LOCATION
直接设置了下层驱动IO堆栈的值。

在FilemonHookRoutine函数里，用一个宏实现了复杂的获得拦截到的被操作文件的名字：

if( FilterOn && hookExt->Hooked ) {

        GETPATHNAME( createPath );
}

GETPATHNAME( createPath )宏展开为：

#define GETPATHNAME(_IsCreate)                                                  \
        fullPathName = ExAllocateFromNPagedLookasideList( &FullPathLookaside ); \
        if( fullPathName ) {                                                    \
            FilemonGetFullPath( _IsCreate, FileObject, hookExt, fullPathName ); \
        } else {                                                                \
            fullPathName = InsufficientResources;                               \
        }

在函数：FilemonGetFullPath( _IsCreate, FileObject, hookExt, fullPathName )中实现了获得被操作的文件名字，此函数代码较多，判断条件复杂，理解起来比较麻烦，下面重点讲解。
对函数FilemonGetFullPath的理解关键在于理顺结构，
此函数的功能就是获得文件名字，获得文件名字一般在三种状态下：
一：在打开文件请求中，但在打开文件前。
二：在打开文件请求中，但在打开文件后，通过在本层驱动中设置完成例程。在完成例程中获得。
三：在过滤到读写等操作时。
而在此函数中，它包含了第一种和第三种方法，通过一些烦琐的条件判断，先判断出目前是处于什么状态中，然后根据不同状态采取不同方法。

先分析当在第一种条件下，此函数的处理方法，可以精炼为如下：

VOID
FilemonGetFullPath(
    BOOLEAN createPath,
    PFILE_OBJECT fileObject,
    PHOOK_EXTENSION hookExt,
    PCHAR fullPathName
    )
{
	ULONG               pathLen, prefixLen, slashes;
    PCHAR               pathOffset, ptr;
    BOOLEAN             gotPath;
    PFILE_OBJECT        relatedFileObject;

    ANSI_STRING         fileName;
    ANSI_STRING         relatedName;

    UNICODE_STRING      fullUniName;

	prefixLen = 2; // "C:"

	if( !fileObject ) { 

        sprintf( fullPathName, "%C:", hookExt->LogicalDrive );
        return;
    }

    //
    // Initialize variables
    //
    fileName.Buffer = NULL;
    relatedName.Buffer = NULL;
    gotPath = FALSE;

	if( !fileObject->FileName.Buffer)
	{
		sprintf( fullPathName, "%C:", hookExt->LogicalDrive);
		return;
	}else
		DbgPrint("fileOjec->FileName:%s",fileObject->FileName);

	 if( !NT_SUCCESS( RtlUnicodeStringToAnsiString( &fileName, &fileObject->FileName, TRUE ))) {

            sprintf( fullPathName, "%C: <Out of Memory>", hookExt->LogicalDrive );
            return;
        }

        pathLen = fileName.Length + prefixLen;
        relatedFileObject = fileObject->RelatedFileObject;

		  //
        // Only look at related file object if this is a relative name
        //
        if( fileObject->FileName.Buffer[0] != L'\\' &&
            relatedFileObject && relatedFileObject->FileName.Length ) {
			DbgPrint("relatedFileObject filename : %s",relatedFileObject->FileName);

			if( !NT_SUCCESS( RtlUnicodeStringToAnsiString( &relatedName, &relatedFileObject->FileName, TRUE ))) {

                sprintf( fullPathName, "%C: <Out of Memory>", hookExt->LogicalDrive );
                RtlFreeAnsiString( &fileName );
                return;
            }
            pathLen += relatedName.Length+1;
        }

		if( fileObject->DeviceObject->DeviceType != FILE_DEVICE_NETWORK_FILE_SYSTEM ) {

            sprintf( fullPathName, "%C:", hookExt->LogicalDrive );
        }

		 if( pathLen >= MAXPATHLEN ) {

            strcat( fullPathName, " <Name Too Long>" );

        } else {

            //
            // Now we can build the path name
            //
            fullPathName[ pathLen ] = 0;

            pathOffset = fullPathName + pathLen - fileName.Length;
            memcpy( pathOffset, fileName.Buffer, fileName.Length + 1 );

            if( fileObject->FileName.Buffer[0] != L'\\' &&
                relatedFileObject && relatedFileObject->FileName.Length ) {

                //
                // Copy the component, adding a slash separator
                //
                *(pathOffset - 1) = '\\';
                pathOffset -= relatedName.Length + 1;

                memcpy( pathOffset, relatedName.Buffer, relatedName.Length );

                //
                // If we've got to slashes at the front zap one
                //
                if( pathLen > 3 && fullPathName[2] == '\\' && fullPathName[3] == '\\' )  {

                    strcpy( fullPathName + 2, fullPathName + 3 );
                }
            }
        }  

}

上面的精简后的函数代码为只考虑目前处于第一种情况，即打开文件请求中，但文件尚未打开时。
在此时，文件的名字信息存储在文件对象fileObject->FileName,与fileObject->RelatedFileObject->FileName, FileObject->FileName 是RelatedObject 的相对路径，通过对两者的解析组合出文件名字。

而在FilemonGetFullPath 函数体中的另一段代码：

FilemonGetFullPath
{
…………………..
…………………..
…………………..
if( !gotPath && !createPath ) {

        fileNameInfo = (PFILE_NAME_INFORMATION) ExAllocatePool( NonPagedPool,
                                                                MAXPATHLEN*sizeof(WCHAR) );

        if( fileNameInfo &&
            FilemonQueryFile(hookExt->FileSystem, fileObject, FileNameInformation,
                             fileNameInfo, (MAXPATHLEN - prefixLen - 1)*sizeof(WCHAR) )) {

            fullUniName.Length = (SHORT) fileNameInfo->FileNameLength;
            fullUniName.Buffer = fileNameInfo->FileName;
            if( NT_SUCCESS( RtlUnicodeStringToAnsiString( &fileName, &fullUniName, TRUE ))) { 

                fullPathName[ fileName.Length + prefixLen ] = 0;

                if( hookExt->Type == NPFS ) {

                    strcpy( fullPathName, NAMED_PIPE_PREFIX );

                } else if( hookExt->Type == MSFS ) {

                    strcpy( fullPathName, MAIL_SLOT_PREFIX );

                } else if( fileObject->DeviceObject->DeviceType != FILE_DEVICE_NETWORK_FILE_SYSTEM ) {

                    sprintf( fullPathName, "%C:", hookExt->LogicalDrive );

                } else {

                    //
                    // No prefix for network devices
                    //
                }

                memcpy( &fullPathName[prefixLen], fileName.Buffer, fileName.Length );
                gotPath = TRUE;
                RtlFreeAnsiString( &fileName );
                fileName.Buffer = NULL;
            }
        }
        if( fileNameInfo ) ExFreePool( fileNameInfo );
}
…………………
…………………
…………………
}

上面这段代码是处理另外一种情况，即是在其他读写请求中，自己根据拦截到的fileObject构建IRP，下发到底层，以此来查询文件名信息。整个过程还是易于理解的。

在理清这两种脉络后，再剖析此整个函数，就很容易理解整个函数代码了。
代码中对 MajorFunction == IRP_MJ_CREATE_NAMED_PIPE
MajorFunction == IRP_MJ_CREATE_MAILSLOT 的判断是为了辨别对拦截到的进程间的两种通信方式：命名管道与邮槽的处理。

周末来了，祝大家周末愉快。余下的整理后再帖，希望和大家多交流。

连城碧 QQ 276265852 MSN：haochao0000@hotmail.com

　　 2.80386处理器的寻址方式
　　 在实式模式下，80386处理器的最大寻址空间仍然为1M，和8086/8088相似。即段地址*10H+段内偏移地址，从而形成20位地址。此种模式下，段基址是16的倍数，长度最大不超过64K。
　　 在保护模式下，80386处理器可以使用所有的物理内存。段基址可以是32位，也可以不是16的倍数，同时它的最大长度为4G，这与8086完全不同，在形成逻辑地址时用段基址直接加上段内偏移地址，而并不将段基址左移4位(乘以16)。通常情况下，除了访问堆栈外，默认的段都为DS，有跨段前缀就另当别论了。在以BP，EBP，ESP作为基址寄存器时，这时默认的段寄存器应该是SS，举几个简单的例子：
　　 MOV EAX,[SI];这里的段寄存器是DS
　　 MOV EAX,FS:[ESI];这里的段寄存器是FS，因为指令中使用跨段前缀显示指定了
　　 MOV EAX,[BP];这里的段寄存器是SS，因为指令中使用了BP作为基址寄存器
　　 MOV EAX,GS:[BP];这里段寄存器是GS，因为指令中使用跨段前缀显示指定了
　　 80386中32位数的操作的顺序是“高高低低”，即是说高16-》高16，高8-》高8，低16-》低16，低8-》低8,这和8086相似。同时80386微处理器兼容所有8086的寻址方式，而且对8086的寻址方式有很大的改进和扩展。在8086下，只允许BP，BX，SI，DI作为寻址寄存器，但在80386下，8个通用寄存器都可以作为寻址寄存器。不过有一点要注意的是在基址变址寄存器寻址方式或相对基址变址寻址方式中，段寄存器由基址寄存器来确定，而不是由变址寄存器来确定，同时除ESP外其它的7个通用寄存器都可以作为变址寄存器，用代码来表示就是：
　　 MOV EAX,[EBP+ESP+2];这条指令是错误的，因为不可以用ESP作为变址寄存器
　　 MOV EAX,[EBP+ESI+10H];这里的段寄存器应该有基址寄存器来决定。基址寄存器是BP，那么这里的段寄存就是SS
　　 MOV EAX,GS:[EBP+EDI+100H];不用看了，这里的段寄存器应该是GS，因为指令通过跨段前缀显示指定了
　　 80386支持的基地址+变址+位移量寻址进一步满足了高级语言支持的数据类型。对于C语言来讲，普通变量，数组，结构体，结构体的数组，数组的构体我们既可存放在栈中(静态定义-static definition)，也可以存放在堆中(动态定义-dynamic definition),用ASM也一样可以实现。基址变址寄存器提供了两个可以改变的部分，而位移量则是静态的。看下面的例子：
　　 //Variables in C Programming-Language,the corresponding ASM will list below
　　 void main()
　　 {
　　 int a;//普通的变量，用ASM寻址时直接用DS:[一位移量]，如DS:[2000],属于直接寻址方式
　　 int array[24];//数组，用ASM寻址时用DS:[BX+SI*4],4表示整型的长度，属于基址变址寻址方式
　　 struct abc
　　 {
　　 int a,b,c;
　　 float d;
　　 };
　　 struct abc aa;//结构体,用ASM寻址时DS:[BX+Shift],Shift代表位移量，属于寄存器相对寻址方式
　　 struct abc aa[100];//结构体数组，用ASM寻址时用DS:[BX+SI*sizeof(abc)+Shift]，属于相对基址变址寻址方式
　　 struct cde
　　 {
　　 int array[100];
　　 float e,f,g;
　　 };
　　 struct cde ccc;//数组结构体,用ASM寻址时用DS:[BX+SI*4+Shift]，属于相对基址变址寻址方式
　　 }
　　 80386与8086的寻址方式差不多完全一样，只不过80386的寻址方式更灵活，它的操作数有32位，16位，8位。
　　 让我们再重温一下8086的寻址方式：
　　 a.立即寻址，所谓立即寻址就是操作数就在指令中，比如说：MOV AX,5678H
　　 b.直接寻址，即直接包含操作数的有效地址EA，比如说MOV AX,[1234]
　　 c.寄存器间址寻址,用寄存器的内容来作为操作数的有效地址,比如说SI=1234,MOV AX,[SI]，8086下可用的寄存器只有4个：BX，BP，SI，DI，80386下8个通用的寄存器都可以使用。
　　 d.寄存器相对寻址，即在寄存器间址寻址方式的基础上再加一个位移量，位移量可以是8位也可以是16位，比如说MOV AX，[BX+90H]。
　　 e.基址变址寻址，即操作数的有效地址由一基址寄存器和一变址寄存器产生，如MOV AX,[BX+SI]。那么在8086下，只有SI，DI可以作为变址寄存器，在80386下除ESP外的其它7个通用寄存器都可以作为变址寄存器,比如说MOV AX,[BX+SI]。
　　 f.相对基址变址寻址，在e寻址方式的基础上加上一位移量，比如说MOV AX,[BX+SI+100H]。
　　 在8086下，我们如进行字节或字操作，往往要加上伪指令WORD PTR或BYTE PTR。在80386下不用显示指定，处理器会自动处理，当发现目的操作为8位时，处理器就会进行8位操作，同理当发现目的操作为16位，处理器就会进行16位操作，80386下以目的操作数的长度为准，以下几条简单的传送指令：
　　 MOV AL,CS:[EAX];8位操作，段寄存器是CS，寻址方式是寄存器间址寻址
　　 MOV AL,ES:[BX];8位操作，段寄存器是ES，寻址方式是寄存器间址寻址
　　 MOV EDX,[EDX+EBX+1234H];32位操作，段寄存器是DS，寻址方式是相对基址变址寻址
　　 MOV AX,[EBX+ESI*4];16位操作，段寄存器是DS，寻址方式是基址变址寻址
　　 MOV BH,ES:[EBX+EDI+900H];8位操作，段寄存器是ES，寻址方式是相对基址变址寻址
　　 MOV DL,[EBP+ESI+1900H];8位操作，段寄存是SS，因为用了EBP作为基址寄存器。寻址方式是相对基址变址寻址

　　 80386的指令集包含了8086/8088，80186，80286的指令集，可以分为几个大类：数据传送指令，算术运算/逻辑运算指令，移位指令，控制转移指令，串操作指令，高级语言支持的指令，条件字节设置指令，位操作指令，处理器控制指令和保护方式指令。高级语言支持指令始于80186，保护方式指令始于80286，条件字节设置指令和位操作指令是80386新增的。
　　 本篇主要介绍数据传送指令,数据传送指令可以分为：通用数据传送，累加器专用传送，地址传送，标志传送，分别介绍如下：
　　 A.数值传送指令MOV,MOVZX,MOVSX,XCHG,PUSH,PUSHA,PUSHAD,POPA,POPAD,
　　 a.MOV，指令和8086相似，不过它支持32位操作。
　　 b.MOVZX，零扩展传送，格式–MOVZX DST,SRC,表示将源操作送给目的操作数，目的操作数空出的部分用0填补。
　　 c.MOVSX，符号扩展传送，格式–MOVSX DST,SRC,表示将源操作送给目的操作数，目的操作数空出的部分用SRC的符号位来填补,举个简单的例子来演示：
　　 MOV DL,90H;
　　 MOVSX AX,DL;AX=FF90H
　　 MOVZX AX,DL;AX=0090H
　　 MOVSX ESI,DL;ESI=FFFFFF90H
　　 MOVZX ESI,DL;ESI=00000090H
　　 事实上在8086中也有两条指令CBW，CWD可以对操作数进行扩展。MOVSX可以对有符号数进行扩展，MOVZX可以对无符号数进行扩展,看看CBW，CWD的用法:
　　 CBW将字节数据扩展成字，符号位扩展到AH中
　　 CWD将字数据扩展成双字，符号位放到DX中
　　 MOV AL,70H;
　　 CBW;//AX=0070
　　 CWD;//DX=0000,AX=0070
　　 d.XCHG，功能和8080相同，不过它支持8位，16位，32位操作,下面的语句均是合法的。
　　 XCHG AH,AL
　　 XCHG AX,AL
　　 XCHG ESI,EDI
　　 XCHG ESI,[EBX+EDI+1000H]
　　 e.PUSH，和8086不同的是，它支持立即数入栈，8位入栈,当然还有32位入栈，下面的语句均是合法的。
　　 PUSH AL
　　 PUSH BH
　　 PUSH 100H
　　 PUSH EAX
　　 PUSH EBX
　　 PUSH DWORD PTR [EAX]
　　 f.POP，功能和用法和8086一样。
　　 g.PUSHA，将8个通用寄存器全部进栈,进栈顺序为:AX，CX，DX，BX，SP，BP，SI，DI,然后SP指针寄存减16，不过SP入栈的内容是PUSHA指令执行前的内容。
　　 h.POPA，8个通用寄存器全部出栈，堆栈指针寄存器不是堆栈中弹出的内容，而是加16而得到的,虽然这样得到的值和从堆栈中弹出来的内容一样，但物理意义不一样。
　　 i.PUSHAD，将8个32位通用寄存器全部入栈，入栈顺序EAX，ECX，EDX，EBX，ESP，EBP，ESI，EDI，ESP的内容是执行指令PUSHAD之前的内容
　　 j.POPAD，8个32位通寄存器全部出栈，ESP的内容参见h
　　
　　 B.地址传送指令LEA,LDS,LES,LFS,LGS,LSS
　　 a.LEA，取有效地址，功能，用法与8086相同，不过它支持32位操作。规则：目的操作必须是16位或32位通用寄存器，当目的操作数是16位时，那么只装入有效地址的低16位。事实上LEA指令相当于伪指令OFFSET，看例子：
　　 MOV EAX,12345678H
　　 MOV EBX,56784321H
　　 LEA ECX,[EAX+EBX];ECX=99999999H
　　 b.LDS，装入指针,功能，用法与8086相同，不过它支持32位操作。格式：LDS REG,OPRD。规则，目的寄存器必须是16位或32位的通用寄存器，OPRD必须是内存单元，不可以是立即数。如果目的寄存器是16位，那么源操作数OPRD含32位指针；如果目的寄存器是32位，那么源操作数有48位指针。该指令将目的操作数OPRD所指向的内存单存的4个或6个连续字节的内容送给助记符指令中指定的DS段寄存器和指令中目的寄存器。比如：
　　 LDS EAX,[1000H];这表明将偏移地址为1000，1001H这两个字节单元的内容送给段寄存器DS，将偏移地址1002，1003，1004，1005四个字节单元的内容送往EAX。
　　 LDS AX,[1000H];这表明将偏移地址为1000，1001H这两个字节单元的内容送给段寄存器DS，将偏移地址1002，1003H两个字节单元的内容送往EAX。
　　 c.LES，同LDS,不过段寄存器是ES。
　　 d.LFS，同LDS,不过段寄存器是FS。
　　 e.LGS，同LDS,不过段寄存器是GS。
　　 h.LSS，同LDS,不过段寄存器是SS。
　　
　　 C.标志传送指令LAHF,SAHF,PUSHF,PUSHFD,POPF,POPFD
　　 a.LAHF，将标志寄存器的低8位送至AH中，包括SF，ZF，ZF，PF，CF。
　　 b.SAHF，与i的过程恰好相反
　　 c.PUSHF，将标志寄存器的EFLAGS低16位内容入栈，和8086相同
　　 d.PUSHFD，将标志寄存器EFLAGS的内容入栈
　　 e.POPF，将栈顶的一个字弹出，并将它送到标志寄存器EFLAGS的低16位
　　 f.POPFD，将栈顶的两个字弹出，并将它送到标志寄存器EFLAGS
　　
　　 D.累加器传送指令IN,OUT,XLAT
　　 a.IN，和8086相同，但可以输入一个双字节，同样如果端口的范围位于00H-FFH，可以直接用，如果超出这个范围，则先要将端口号送至DX，下面的语句是合法的:
　　 IN AL,20H;从20H端口读入一个字节
　　 IN AX,20H;从20H端口读入一个字
　　 MOV DX,0378H
　　 IN EAX,DX;从20H端口读两个字节
　　 b.OUT，和8086相同，但可以输出一个双字节，同样如果端口的范围位于00H-FFH，可以直接用，如果超出这个范围，则先要将端口号送至DX，下面的语句是合法的:
　　 OUT 20H,AL;从20H端口输出一个字节
　　 IN 20H,AX;从20H端口输出一个字
　　 MOV DX,0378H
　　 IN EAX,DX;从20H端口输出两个字
　　 c.XLAT,查表指令，功能和用法与8086相同，不过基址寄存器用的是EBX，来看看XLAT的实现过程：XLAT以BX作为基址寄存器，以AL作为变址寄存进器对指定的缓冲区进行查表，将AL指定位置的内容送往AL，比如说我们在MS-DOS方式写一个小程序：
　　 C:\>Debug
　　 -A100
　　 MOV BX,0120
　　 SUB AL,AL
　　 MOV DL,AL
　　 MOV AH,2
　　 INT 21
　　 MOV AH,4C
　　 INT 21
　　 INT 20
　　-E120 ‘ABCDEFGHIJKLLMMDDKDJDK’
　　=G100
　　 屏幕上会显示A,如果AL=3，那么屏幕会显示D
　　 以上所有的指令均不影响EFLAGS的各标志位。

　　算术运算指令，逻辑运算指令，移位指令
　　 AA.算术运算指令
　　 A.加减法运算ADD,ADC,INC,SUB,SBB,DEC,CMP,NEG
　　 a.ADD,和8086功能，用法相同，不过支持32位操作，下面的语句都是合法的。
　　 ADD ESI，EDI
　　 ADD EAX，DWORD PTR ［1000H］
　　 b.ADC，带进位的加法指令，即OPRDS＋OPRDD＋CF，其中OPRDS代表源操作数，OPRDD代表目的操作，CF代表进位标志位，功能和用法与8086相同，支持32位操作。
　　 c.SUB，和8086相同，支持32位操作。
　　 d.SBB，带进位的减法指令，即OPRDD－OPRDS－CF，其中OPRDS代表源操作数，OPRDD代表目的操作数，CF代表进位标志位，功能和用法与8086相同，支持32位操作。
　　 e.DEC，减1操作，功能和用法与8086相同，支持32位操作。
　　 f.CMP，比较操作，功能和用法与8086相同，支持32位操作。
　　 g.NEG，求补操作，功能和用法与8086相同，支持32位操作。
　　 h.INC 加1操作，功能和用法与8086相同，支持32位操作。
　　
　　 B.乘除法指令MUL,DIV,IMUL,IDIV
　　 a.MUL，无符号数乘法指令，和8086功能用法一样，即指令中只给出一个操作，被乘数已默认，如果指令给出的操作数是32位的话，被乘数默认为EAX，那么乘积将存放在EDX：EAX中，其中EDX存放高32位，EAX存放低32位，如果此时EDX＝0，即高32位为0的话，那么OF＝0，CF＝0，否则被置1。如果指令给出的操数作是16位的话，被乘数默认为AX那么乘积将放在DX：AX中，其中DX中将存放高16位，AX中存放低16位。如果指令给出的操作数是8位的话，被乘数默认为AL，那么乘积将放在AX，AH中存放高8位，AL中存放低8位。
　　 b.DIV，无符号数的除法指令，和8086一样，指令给出一个操作数，被除数已默认。如果指令中给出的操作数为32，那么被除数将是EDX：EAX， 最终的商将存放在EAX， 余数将存放在EDX中。如果指令给出操作数为16位，那么被除数为EAX，最终得到的商放在AX，余数放在EAX的高16位。如果指令中给出的操作数为8位，那么被除数是16位，最终得到的商将放在AL中，余数放在AH中。
　　 c.IMUL，有符号数的乘法指令，除了具有8086的用法外，有新的形式：
　　 c1.IMUL DST,SRC;将源操作数SRC与目的操作DST相乘，并将结果送往DST。
　　 c2.IMUL DST,SRC1,SRC2;将源操作数SRC1与源操作数SRC2相乘，并将结果送往DST。
　　 使用这种形式必须遵守的规则，形式c1指令中目的操作数必须是16位或32位通寄存器，源操作数的长度必须与目的操作的长度一样（8位立即数除外，即00H－FFH或80H－7FH)，源操作数可以是通用寄存器，也可以是存储单元或立即数。形式c2指令中的源操作数SRC1可以是通用寄存器也可以是存储单元，源操作数SRC2必须是立即数，DST必须是16位或32位通用寄存器。呵呵，对于这些规则无需去问为什么，这是硬件的特性决定的，如果一定要问为什么，那只能问INTEL公司的硬件工程师了:)。同时，有一点要注意的是：这两种形式的指令，目的寄存器的长度与源操作数长度一样（8位立即数除外），这样的话，该指令事实上对有符号数和无符号数是一样的，因为乘积的低位部分均存储在目的寄存器中，而高位部分在这两种形式的指令中不予以存储。
　　 d.IDIV，有符号数的除法指令，用法和8086相同，不过支持32位操作。
　　 C.符号扩展指令CBW，CWD，CWDE，CDQ
　　 a.CBW，前面已介绍，在第三篇。
　　 b.CWD，前面已介绍，在第三篇。
　　 c.CWDE，是80386新增的指令。格式：CWDE。功能：将AX的符号位扩展到EAX的高16位中。
　　 d.CDQ，是80386新增的指令。格式：CDQ。功能，将EAX的符号位扩展到EDX中。
　　 e.以上四条指令均不影响标志位。
　　 f.举例说明：
　　 ;If AX=1234H,EAX=99991234H
　　 CBW;After processing the instruction,AX=1234,DX=0000H
　　 CDQ;After processing the instruction,EAX=99991234H,EDX=FFFFFFFFH
　　 BB.逻辑运算指令和移位指令NOT,AND,OR,XOR,TEST,SAL,SAR,SHL,SHR,ROL,ROR,RCL,RCR,SHLD,SHRD
　　 a.NOT,AND,OR,XOR,TEST这些指令的功能和用法与8086完全相同，不过它们支持32位操作。
　　 b.TEST，测试指令，该指令测试的结果并不回送到目的操作数和源操数。之所以要使用这条的指令，主要是因为根据TEST指令得到的结果，进行程序的条件转移。
　　 c.SAL，算术左移，功能和8086一样，但在8086中，如果在移位的位数超过1位，那么一定要移位的位数放在CX寄存器中。在80386中，可以不用这样做，其它的移位指令也一样。除了这一点以外，用法和8086一样，当然也支持32位操作。以下的语句均是合法的。
　　 SHL AL,5;这在8086中是非法，但在80386中是合法的
　　 SHL WORD PTR [SI],3
　　 d.SAR，算术右移，将操作数右移指定的位数，但左边的符号位保持不变，移出的最低位进入CF标志位。
　　 e.SHL，逻辑左移，用法和功能与SAL一样。
　　 f.SHR，逻辑右移，将操作右移指定的位数，同时每移一位，左边用0补充，移出的最低位进入CF标志位。
　　 g.说明：在80386中，实际移位的位数是指令中移位位数的低5位，也就是说移位位数的范围在0-31或0－1FH，CF标志位总是保留着目的操作数最后被移出位的值。当移位位数大于操作数的长度时，CF被置0。如果移位位数为1，移位前后的结果的符号位都是一样，那么很明显的是该操作数经移位后没有移出，此时OF＝0。这四条指令的移位示意图(我画的是16位操作数的移位示意图，8位和32依此类推),SAL,SHL相当于乘法；SAR，SHR相当于除法。
　　 SAL:
　　 |——————————————————————————————-|
　　 |CF|<-|bit15|bit14|bit13|bit12|bit11|bit10|bit9|bit8|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|
　　 |– —————————————————————————————-|
　　 SHL:
　　 |——————————————————————————————-|
　　 |CF|<-|bit15|bit14|bit13|bit12|bit11|bit10|bit9|bit8|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|
　　 |— —————————————————————————————|
　　 SAR:
　　 |——————————————————————————————–|
　　 |-|bit15|bit14|bit13|bit12|bit11|bit10|bit9|bit8|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|->|CF||
　　 | |—|—————————————————————————————-|
　　 | ^
　　 |—–|最高位保持不变
　　 SHR:
　　 |——————————————————————————————–|
　　 0->|bit15|bit14|bit13|bit12|bit11|bit10|bit9|bit8|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|->|CF||
　　 |——————————————————————————————–|
　　 h.ROL，循环左移，支持32位操作数，用法和8086一样。
　　 i.ROR，循环右移，支持32位操作数，用法和8086一样。
　　 j.RCL，带进位的循环左移，支持32位操作数，用法和8086一样。
　　 k.RCR，带进位的循环右移，支持32位操作数，用法和8086一样。
　　 l.ROL,ROR,RCL,RCR的移位示意图(仍然以16位操作数来画，8位/32位依次类推):
　　 ROL:
　　 |————————————————————————————————–|
　　 |<-|bit15|bit14|bit13|bit12|bit11|bit10|bit9|bit8|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|<——–|
　　 |————————————————————————————————–|
　　 |————————————————————————————————–|
　　 ROR:
　　 |——————————————————————————————-|
　　 |->|bit15|bit14|bit13|bit12|bit11|bit10|bit9|bit8|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|->|
　　 |——————————————————————————————-|
　　 |——————————————————————————————-|
　　RCL:
　　 |————————————————————————————————-|
　　 |<-|CF|<-|bit15|bit14|bit13|bit12|bit11|bit10|bit9|bit8|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|<-|
　　 |————————————————————————————————-|
　　 |————————————————————————————————-|
　　 RCR:
　　 |————————————————————————————————-|
　　 |->|CF|<-|bit15|bit14|bit13|bit12|bit11|bit10|bit9|bit8|bit7|bit6|bit5|bit4|bit3|bit2|bit1|bit0|->|
　　 |—- ——————————————————————————————–|
　　 |————————————————————————————————-|
　　 m.SHLD，80386新增的双精度左位指令，指令格式：SHLD OPRD1,OPRD2,M
　　 n.SHRD，80386新增的双精度右移指令，指令格式：SHRD,OPRD1,OPRD2,M
　　 o.m,n这两条指令的使用规则是：源操作数OPRD1可以是16位或32位通用寄存器或者16位存储单元或者32位存储单元，源操作数OPRD2必须是16位或32位通寄存器，M表示移位次数，可以是CL寄存器，也可以是8位立即数。功能：SHLD是将源操作数OPRD1移M位，空出的位用OPRD2高端的M位来填补，源操作数OPRD2的内容不变，最后移出的位放在CF中；SHRD将源操作数OPRD1移M位，空出的位用OPRD2低端M位来填补，源操作数OPRD2保持不变，最后移出的位放在CF中，对于这两条指令，当移位位数仅为1的话，移出和移后的符号位不变的话，那么OF＝0，如果符号位不一样的话，那OF＝1。
　　 p.这两条指令是80386新增的指令，举两个简单的例子加以说明：
　　 p1.SHLD:
　　 MOV AX,8321H
　　 MOV DX,5678H
　　 SHLD AX,DX,1
　　 SHLD AX,DX,2
　　 分析一下该指令的详细执行过程(用示意图, 第一个图画的就是AX的内容)：
　　 AX=8321h
　　 |——————————-|
　　 |1|0|0|0|0|0|1|1|0|0|1|0|0|0|0|1|
　　 |——————————-|
　　 根据指令SHLD AX,DX,1，先左移一位,得到AX=0642H:
　　 |——————————-|
　　 |0|0|0|0|0|1|1|0|0|1|0|0|0|0|1|0| CF＝1
　　 |——————————-|
　　 经过上一步的移位后，AX的最后一位(即bit0)空出来，其值为0；根据指令的用法将用DX的第15位填充,填充后AX的内容为：
　　 |——————————-|
　　 |0|0|0|0|0|1|1|0|0|1|0|0|0|0|1|0|
　　 |——————————-|
　　 同时由于移位后AX的符号位与移位前AX的符号位不同，所以在移位过程中产生了溢出，OF＝1，最后结果AX＝0642H。
　　 同理,SHLD AX,DX,2，执行完这条指令后，最后结果为AX=0644H
　　 p2.SHRD:
　　 MOV EAX,12345678H
　　 MOV EDX,99994599H
　　 SHRD AX,DX,1
　　 SHRD AX,DX,2
　　 分析一下该指令的详细执行过程(用示意图，第一个图画的是EAX的内容):
　　 EAX=12345678H
　　 |—————————————————————|
　　 |0|0|0|1|0|0|1|0|0|0|1|1|0|1|0|0|0|1|0|1|0|1|1|0|0|1|1|1|1|0|0|0|
　　 |—————————————————————|
　　 根据指令SHRD AX,DX,1，将AX右移一位得到EAX=091A2B3EH：
　　 |—————————————————————|
　　 |0|0|0|0|1|0|0|1|0|0|0|1|1|0|1|0|0|0|1|0|1|0|1|1|0|0|1|1|1|1|1|0|
　　 |—————————————————————|
　　 经过上一步的移位后，EAX的最高位（第31位）空出来用0填充，根据指令的用法，最EDX的第0位来填充，填充后EAX的内容为：
　　 |—————————————————————|
　　 |1|0|0|0|1|0|0|1|0|0|0|1|1|0|1|0|0|0|1|0|0|1|1|0|0|1|1|1|1|0|0|0|
　　 |—————————————————————|
　　 即EAX=891A2B3EH,CF=0,OF=0
　　 同理，指令SHRD AX,DX,2，执行完这条件指令后，最后结果为EAX=048D159C,CF=0,OF=0

　　控制转移指令，串操作指令
　　 80386控制转移指令包括：转移指令，循环指令，过程调用和返回指令。
　　 A.转移指令包括无条件转移指令JMP和条件转移指令，无条件转移指令分为段内直接转移，段内间接转移，段间直接转移，段间间接转移。由于80386有保护模式和实模式，在实模式下，段内转移的范围在-128~127，段间转移最大范围为64K。在保护模式需要用48位指针，即CS:EIP(16位＋32位)。条件转移指令有很多包括JCXZ，JECXZ，JBE，JAE，JA，JB等，其用法和8086相似。
　　
　　 B.循环指令LOOP，LOOPZ，LOO0PE，LOOPNZ，LOOPNE,TASM支持助记符LOOP，LOOPWE，LOOPWZ，LOOPWNZ，LOOPWNE，LOOPD，LOOPWD，LOOPDE，LOOPDNE，LOOPDNZ。以CX作为计数器时，就可用LOOP，LOOPWE，LOOPWZ，LOOPWNZ，LOOPWNE；在以ECX作为计数器时，以LOOPD，LOOPDE，LOOPDZ，LOOPDNZ，LOOPDNE，下面的一段例子可以说明问题：
　　 ABC PROC
　　 MOV CX,100H
　　 AA:
　　 ;ADD YOUR CODES HERE
　　 LOOP AA
　　 ABC END
　　 C.过程调用和返回调用CALL,RET
　　 这两个指令与8086的用法相同，但由于80386下有实模式和保护模式下。在实模式下，无论是段内调用还是段间调用均采用32位指针，即CS:IP，它们的用法与8086下相同。在保护模式下，段间调用和段内调用均用48位指针，即ECS:IP。RET用于返回，具体实现过程会比较复杂，在介绍完80386的地址的管理机制后会作介绍，先介绍一下以下CALL指令在8086中的用法：
　　 a.段内直接转移，具体格式：CALL 过程名。此时CS不入栈，IP的内栈入栈，入栈后再将加上目的地址与CALL指令的下一条指令的偏移地址之差值就可以转移到目的地址，详细过程：
　　 SP-2=>SP;将堆栈指针SP减2
　　 (SP)<=IP;将IP进栈
　　 IP+偏移地址之差;转到目的地址
　　 b.段内间接转移，具体格式:CALL OPRD，那么在这里OPRD可以寄存器或内存单元，它的具体实现过程：
　　 SP-2=>SP;将堆栈指针SP减2
　　 (SP)<=IP;将IP进栈
　　 IP<=(OPRD);转到目的地址
　　 同a一样，CS不入栈
　　 c.段间直接转移，具体格式：CALL 过程名 [FAR]，此时CS，IP均要入栈，详细的实现过程：
　　 SP-2=>SP;将堆栈指针减2
　　 (SP)<=CS;将CS入栈
　　 SP-2=>SP;将堆栈指针再减2
　　 (SP)<=IP;将IP入栈
　　 ;装入新的CS，IP
　　 IP<=过程入口的偏移地址
　　 CS<=过程入口的段地址
　　 d.段间间接转移，具体格式：CALL OPRD [FAR]，此时CS，IP均要入栈，OPRD是32位，你知道在8086中没有32位寄存器。因此，这里的OPRD一定是存储单元，高16位是CS的值，低16位是IP值，详细的实现过程：
　　 SP-2=>SP;将堆栈指针减2
　　 (SP)<=CS;将CS入栈
　　 SP-2=>SP;将堆栈指针再减2
　　 (SP)<=IP;将IP入栈
　　 ;装入新的CS，IP
　　 IP<=(OPRD+2,OPRD+3)
　　 CS<=(OPRD,OPRD1)
　　 e.段内返回
　　 格式：RET。实际上它的实现过程：
　　 (SP)=>IP;从当前栈顶弹出一个字，将它送给IP指令计数器
　　 SP+2=>SP;SP
　　 f.段间返回
　　 格式：RET,实际上它的实现过程：
　　 (SP)=>IP;IP出栈
　　 SP+2=>SP;
　　 (SP)=>CS;CS出栈
　　 SP+2=>SP;
　　
　　 D.中断返回指令IRET
　　 功能和用法与8086相同，这里顺便介绍一下8086的中断返回指令
　　 IRET，具体的实现过程：
　　 IP<=(SP);IP出栈
　　 SP+2=>SP;
　　 CS<=(SP);CS出栈
　　 SP+2=>SP;
　　 FLAGS<=(SP);标志寄存器出栈
　　 SP+2=>SP;
　　
　　 E.串操作指令
　　 80386在串操作指令方面增加了双字操作，在8086五条指令的基础上增加了INS,OUTS。
　　 a.LOADSD，和8086的用法和功能相同，不过是对32位操作数操作。
　　 b.STOSD，和8086的用法和功能相同，不过是对32位操作数操作。
　　 c.CMPSD，和8086的用法和功能相同，不过是对32位操作数操作。
　　 d.SCANSD，和8086的用法和功能相同，不过是对32位操作数操作。
　　 e.MOVSD，和8086的用法和功能相同，不过是对32位操作数操作。
　　 f.重复前缀REP，和8086的功能与用法相同，仍以CX为计数器，看下面的一小程序：
　　 ROR ECX,2
　　 REP MOVSD;以CX为计数器，每次传送双字
　　 ROL ECX,1
　　 REP MOVSW;以CX为计数器，每次传送一字
　　 ROL ECX,1
　　 REP MOVSB;以CX为计数器，每个传送一个字节
　　 g.INSB,INSW,INSD,OUTSB,OUTSW,OUTSD
　　 g1.INSB，串输入指令，以字节单位，该指令的功能是从DX指定的端口读入一个字节到ES:DI指定的内存单元中。
　　 g2.INSW，串输入指令，以字单位，该指令的功能是从DX指定的端口读入一个字节到ES:DI指定的内存单元中。
　　 g3.INSD，串输入指令，以双字单位，该指令的功能是从DX指定的端口读入一个字节到ES:DI指定的内存单元中。
　　 g4.OUTSB， 串输出指令，以字节为单位，将DS:SI内存单元的内容送往DX指定的端口。
　　 g5.OUTSW， 串输出指令，以字为单位，将DS:SI内存单元的内容送往DX指定的端口。
　　 g6.OUTSD， 串输出指令，以双字为单位，将DS:SI内存单元的内容送往DX指定的端口。
　　 g7.串输入和串输出指令不影响标志寄存器中的各标志位，串操作指令可以与REP一起使用

　　高级语言支持，条件字节设置指令
　　 AA.高级语言支持指令，开始于80186，主要是用来简化高级语言的某些特征，总共有3条指令:ENTER,LEAVE,BOUND
　　 a.ENTER,LEAVE，建立与释放堆栈框架命令。在C语言中，栈不仅用来向函数传递入口参数，而且在函数内部的局部变量也存放在栈中。为了准确地存取这些这些局变量和准确地获得入口参数，就需要建立堆栈框架，先看一个小程序：
　　 //C Programming-Language
　　 int sum(int x,int y)
　　 {
　　 int sum;
　　 sum=x+y;
　　 return sum;
　　 }
　　 //The corresponding ASM codes lists below
　　 _sum proc near;注意C语言中函数参数的入栈方式是从右向左，即先是参数y入栈，再是x入栈，再是函数的返回地址入栈
　　 push bp
　　 mov bp,sp;建立堆栈框架
　　 sub sp,2
　　 mov ax,word ptr [bp+4];取参数x
　　 add ax,word ptr [bp+6];加参数y
　　 mov word ptr [bp-2],ax
　　 mov ax,word ptr [bp-2]
　　 mov sp,bp;释放栈框架
　　 pop bp
　　 ret
　　 _sum endp
　　此时栈顶的示意图是：
　　|———————-|
　　| BP |<====SP
　　|———————-|
　　| 函数返回地址 |<====BP+2
　　|———————-|
　　| 参数x |<====BP+4
　　|———————-|
　　| 参数y |<====BP+6
　　|———————-|
　　| …… |<====BP+8
　　|———————-|
　　| …….. |<====BP+n,n是一能被2整除的数
　　|———————-|
　　如果用建立和释放堆栈框架指令，那么对应的汇编程序应该是:
　　_sum proc near
　　 enter 2,0;建立栈框架
　　 mov ax,word ptr [bp+4];取参数x
　　 add ax,word ptr [bp+6];加参数y
　　 mov word ptr [bp-2],ax
　　 mov ax,word ptr [bp-2]
　　 leave;释放栈框架
　　 ret
　　_sum endp
　　b.建立栈框架指令ENTER，格式如下：ENTER CNT1,CNT2。其中CNT1表示框架的大小，即子程序中需要放在栈中局部变量的字节数；CNT2是立即数，表示子程序嵌套级别，即从调用框架复制到当前框架的指针数。在立即数CNT2为0时，ENTER指令的实过程是：
　　PUSH BP
　　SP=>BP
　　SP<=SP-CNT1
　　c.释放栈框架指令LEAVE，其具体实现过程:
　　8086:
　　BP=>SP
　　POP BP
　　80386:
　　EBP=>ESP
　　POP EBP
　　d.ENTER和LEAVE指令均不影响标志寄存器中的各标志位，同时LEAVE指令只负责释放栈框架，并不负责函数返回。因此，要在LEAVE指令后安排一条返回指令。
　　BB.条件字节设置指令
　　这是80386新增的一组指令集，将会在后面全部列表出来。条件字节设置指令的格式：
　　SETxx OPRD
　　xx是助记符的一部分，OPRD只能是8位的寄存器或存储单元。
　　eg:
　　SETO AL;表示当溢出标志位为1时，即OF=1，将AL置1，否则AL清0
　　SETNC CH;表示当CF=0时，将CH置1，否则将CH清0
　　SETNA BYTE PTR [100];表示当AF=0，将DS:[100]这一个字置1，否则将它清0
　　a.SETZ OPRD;等于0时(ZF=1)，置OPRD为1，否则清0
　　b.SETE OPRD;同a
　　c.SETNZ OPRD;不等于0时(ZF=0)，置OPRD为1，否则清0
　　d.SETNE OPRD;同c
　　e.SETS OPRD;为负数时(SF=1)置OPRD为1，否则清0
　　f.SETNS OPRD;同e正好相反(SF=0)
　　g.SETO OPRD;OF=1,置OPRD为1，否则清0
　　h.SETNO OPRD;同g正好相反
　　i.SETP OPRD;偶(PF=1)置1
　　j.SETPE OPRD;同i
　　k.SETNP OPRD;奇(PF=0)置1
　　l.SETPO OPRD;同k
　　m.SETB OPRD;低于置OPRD为1，否则清0，这是针对无符号数的
　　n.SETNAE OPRD;不高于即低于或等于时置OPRD为1，否则清0,这是针对无符号数的
　　o.SETC OPRD;CF=1，置OPRD为1，否则清0
　　p.SETNB OPRD;高于或等于时，置OPRD为1，否则清0，这是针对无符号数的
　　q.SETAE OPRD;高于时置OPRD为1，否则清0，这是针对无符号数的
　　r.SETNC OPRD;CF=0时，置OPRD为1，否则清0，这是针对无符号数的
　　s.SETBE OPRD;低于或等于时，置OPRD为1，否则清0，这是针对无符号数的，CF|ZF=1
　　t.SETNA OPRD;同s，这是针对无符号数的，CF|ZF=1
　　u.SETNBE OPRD;高于时置OPRD为1，否则清0，这是针对无符号数的，CF OR ZF=0
　　v.SETA OPRD;同u，这是针对无符号数的，CF OR ZF=0
　　w.SETL OPRD;小于时，置OPRD为1，否则清0，这是针对有符号数的
　　x.SETNGE OPRD;同w，这是针对有符号数的
　　y.SETNL OPRD;大于或等于时，置OPR为1，否则清0，这是针对有符号数的
　　z.SETGE OPRD;同y，这是针对有符号数的
　　a1.SETLE OPRD;小于或等于时，置OPRD为1，否则清0，这是针对有符号数的
　　a2.SETNG OPRD;同a1，这是针对有符号数的
　　a3.SETNLE;大于时，置OPRD为1，否则清0，这是针对有符号数的
　　a4.SETG;同a3，这是针对有符号数的

　　位操作指令，处理器控制指令
　　AA.位操作指令，8086新增的一组指令，包括位测试，位扫描。BT,BTC,BTR,BTS,BSF,BSR
　　a.BT(Bit Test)，位测试指令，指令格式:
　　 BT OPRD1,OPRD2,规则：操作作OPRD1可以是16位或32位的通用寄存器或者存储单元。操作数OPRD2必须是8位立即数或者是与OPRD1操作数长度相等的通用寄存器。如果用OPRD2除以OPRD1，假设商存放在Divd中，余数存放在Mod中，那么对OPRD1操作数要进行测试的位号就是Mod,它的主要功能就是把要测试位的值送往CF，看几个简单的例子：
　　b.BTC(Bit Test And Complement)，测试并取反用法和规则与BT是一样，但在功能有些不同，它不但将要测试位的值送往CF，并且还将该位取反。
　　c.BTR(Bit Test And Reset)，测试并复位，用法和规则与BT是一样，但在功能有些不同，它不但将要测试位的值送往CF，并且还将该位复位(即清0)。
　　d.BTS(Bit Test And Set)，测试并置位，用法和规则与BT是一样，但在功能有些不同，它不但将要测试位的值送往CF，并且还将该位置位(即置1)。
　　e.BSF(Bit Scan Forward)，顺向位扫描，指令格式:BSF OPRD1,OPRD2，功能：将从右向左(从最低位到最高位）对OPRD2操作数进行扫描，并将第一个为1的位号送给操作数OPRD1。操作数OPRD1，OPRD2可以是16位或32位通用寄存器或者存储单元，但OPRD1和OPRD2操作数的长度必须相等。
　　f.BSR(Bit Scan Reverse)，逆向位扫描，指令格式:BSR OPRD1,OPRD2，功能：将从左向右(从最高位到最低位）对OPRD2操作数进行扫描，并将第一个为1的位号送给操作数OPRD1。操作数OPRD1，OPRD2可以是16位或32位通用寄存器或存储单元，但OPRD1和OPRD2操作数的长度必须相等。
　　g.举个简单的例子来说明这6条指令:
　　AA DW 1234H,5678H
　　BB DW 9999H,7777H
　　MOV EAX,12345678H
　　MOV BX,9999H
　　BT EAX,8;CF=0,EAX保持不变
　　BTC EAX,8;CF=0,EAX=12345778H
　　BTR EAX,8;CF=0,EAX=12345678H
　　BTS EAX,8;CF=0,EAX=12345778H
　　BSF AX,BX;AX=0
　　BSR AX,BX;AX=15
　　BT WORD PTR [AA],4;CF=1，[AA]的内容不变
　　BTC WORD PTR [AA],4;CF=1，[AA]=1223H
　　BTR WORD PTR [AA],4;CF=1，[AA]=1223H
　　BTS WORD PTR [AA],4;CF=1，[AA]=1234H
　　BSF WORD PTR [AA],BX;[AA]=0;
　　BSR WORD PTR [AA],BX;[AA]=15(十进制)
　　BT DWORD PTR [BB],12;CF=1,[BB]的内容保持不变
　　BTC DWORD PTR [BB],12;CF=1,[BB]=76779999H
　　BTR DWORD PTR [BB],12;CF=1,[BB]=76779999H
　　BTS DWORD PTR [BB],12;CF=1,[BB]=77779999H
　　BSF DWORD PTR [BB],12;[BB]=0
　　BSR DWORD PTR [BB],12;[BB]=31(十进制)
　　BB.处理器控制指令
　　处理器控制指令主要是用来设置/清除标志，空操作以及与外部事件同步等。
　　a.CLC，将CF标志位清0。
　　b.STC，将CF标志位置1。
　　c.CLI，关中断。
　　d.STI，开中断。
　　e.CLD，清DF=0。
　　f.STD，置DF=1。
　　g.NOP，空操作，填补程序中的空白区，空操作本身不执行任何操作，主要是为了保持程序的连续性。
　　h.WAIT，等待BUSY引脚为高。
　　i.LOCK，封锁前缀可以锁定其后指令的操作数的存储单元，该指令在指令执行期间一直有效。在多任务环境中，可以用它来保证独占其享内存，只有以下指令才可以用LOCK前缀:
　　 XCHG,ADD,ADC,INC,SUB,SBB,DEC,NEG,OR,AND,XOR,NOT,BT,BTS,BTR,BTC
　　j.说明处理器类型的伪指令
　　 .8086，只支持对8086指令的汇编
　　 .186，只支持对80186指令的汇编
　　 .286，支持对非特权的80286指令的汇编
　　 .286C，支持对非特权的80286指令的汇编
　　 .286P，支持对80286所有指令的汇编
　　 .386，支持对80386非特权指令的汇编
　　 .386C，支持对80386非特权指令的汇编
　　 .386P，支持对80386所有指令的汇编
　　 只有用伪指令说明了处理器类型，汇编程序才知道如何更好去编译，连接程序，更好地去检错。
　　 在后续的几篇里将详细介绍80386的段页管理机制及控制寄存器，调试寄存器，以及如何在386实模下和保护模式下编程。

　　80386实模式下编程
　　80386在实模式下是一个更快的8086，它不但可以进行32位操作，而且还可以进32位寻址，并且还可以使用80386的扩展指令。不过，由于是在实模下，寻址的最大空间为1M。在一个段内，段的最大长度不超过64K，否则就会发生异常。
　　在8086下定义一个段的完整格式是：
　　段名 [定位类型] [组合类型] [‘类别’]
　　80386下定义一个段的完整格式是：
　　段名 [定位类型] [组合类型] [‘类别’] [属性类型]
　　说明：属性类型有两种：USE32和USE16，USE32表示32位段，USE16表示16位段。如果你在程序中用到伪指令.386，那么默认的属性类型就是USE32(32位段)，如果没有用伪指令指定CPU的类型，那么默认的属性类型就是USE16，在实方式下只能使用16位段，即用USE16。
　　eg:
　　 CSEG PARA PUBLIC USE32;定义一个32位的段
　　 AA DW ?
　　 BB DD ?
　　 CC DB ?
　　 DD DW ?
　　 EE DW 0,0,0…..
　　 CSEG ENDS
　　由于在80386中用到了66H操作前缀和67H地址前缀，因此尽管在实式模式下，只要设定的CPU类型是80386，仍然可以进行32位操作，可以进行32位寻址，66H,67H这两个前缀无需程序员在程序中书写，汇编程序会自动加上的。只要在程序中对32位操作数进行访问，或进行32位寻址，那么就会加上操作数前缀66H和地址前缀67H。相反，如果在32位段中对16位或8位的访问，汇编程序中也会加上这两个前缀。
　　 下面将给出一个例子程序，演示一下在80386的实模式下编程的方法与技巧(这是从网上down的一个程序，不是我写的，但我会作详细的解剖，并与8086下的程序设计作出比较)：
　　 用十进制，十六进制，二进制三种形式显示双字存储单元F000:1234中的内容