内存映射文件http://blog.csdn.net/sky1415/article/details/5567200

一 内存映射文件用法
　　前面已经提到:内存映射文件是拿文件直接当作系统的内存使用,那么它主要
　　的用途是什么呢?主要有以下两点:
　　1. 直接用内存映射文件来访问磁盘上的数据文件,无需再进行文件
　　的I/0操作.
　　2. 用来在多个进程之间共享数据.进程间共享数据有很多种方法,比如
　　发送消息WM_COPYDATA,匿名管道等等,但他们的低层都毫无例外
　　的使用到了Mapping File.然而因为WM_COPYDATA一定需要使用
　　同步函数SendMessage,所以在实时性方面表现的不是很好.
　　(至于同步和异步的区别可以参考笔者的另一篇文章:
　　http://www.csdn.net/Develop/read_article.asp?id=14204
　　 
　　前面已经提到过,内存映射文件的位置在3G—4G的空间中,这部分是Win32
　　所有进程都看的到并且共享的,自然可以用来传输数据,另外各个进程所
　　共享的DLL等也是映射在这个空间范围.
　　 内存映射文件的使用可以分为以下三步:
　　1.CreateFileMapping 创建一个文件映射内核对象
　　2.MapViewOfFile 将文件数据映射进进程地址空间
　　3.UnmapViewOfFile 从进程地址空间解除这个映射
　　 
　　 下面以Mapping File的两个主要作用分别给出两个简单的例子:
　　 
　　A 直接用内存映射文件访问文件.
　　 首先在C盘下创建一个Mapping.txt里面输入1234567
　　 HANDLE hFile=CreateFile("c://mapping.txt",GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE,
NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);

HANDLE hFilemap = CreateFileMapping(hFile,NULL,PAGE_READWRITE,0,100, NULL);

LPVOID pVoid=MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,0,0);

char *Buf=(char *)pVoid;

Buf[0]='T';

           UnmapViewOfFile(pVoid);

CloseHandle(hFile);

CloseHandle(hFilemap);

　　(注意:没有考虑异常情况)
　　 
　　 这样,当我们再打开Mapping.txt的文件的时候,就发现第一个字节”1”
　　 已经被改为了’T’.
　　 也许有些读者会提问:干吗这么麻烦呢?直接用fopen或者CreateFile
　　不就OK了?是的,小文件是,可是如果这个文件有上百兆呢?Mapping
　　File为我们提供了一种直接映射存取的方便之道.
　　 这里有个小小的地方要注意,创建映射对象的时候有个保护属性
　　fdwProtect可以选择PAGE_WRITECOPY,顾名思义是用来写拷贝的,
　　系统在收到这个参数后,将会从页面文件中额外的提交物理内存
　　(前面已经提到过,映射对象不使用页面文件).当发生读操作的时候,系统
　　仍旧使用映射文件,当发生写操作的时候,系统从页面文件中分配页面,
　　从映射文件中拷贝到该页进行访问,这样使得原先的写操作被丢弃.
　　读者可以试着照上面的例子把CreateFileMapping和MapViewOfFile
　　里面的两个对应字节改为PAGE_WRITECOPY和FILE_MAP_COPY,
　　这样原文件即使有写操作也不会被改动.
　　 
　　B 在不同的进程间共享数据
　　 要进行共享如果每次都要在硬盘上创建一个文件该是多么的麻烦啊,
　　 Windows提供了这样一种机制:当在创建映射对象的时候如果hFile
　　 填上(HANDLE)0xFFFFFFFF,系统会自动从页面文件中创建文件对象.
　　 另外有书上提到共享方式是以p2p的方式还是c/s的架构来进行,
　　 我想不过是打开的方式不同吧,没有别的差别,(一个用CreateFileMapping
　　打开看是否为已经存在,另一个用OpenFileMapping打开)
　　 
　　来看个例子;
　　 
　　 # define WM_DATACOMING WM_USER+100
　　 
　　进程A:
　　 HANDLE hFilemap=CreateFileMapping((HANDLE)0xFFFFFFFF,
　　 NULL,
　　 PAGE_READWRITE,
　　 0,
　　 100,
　　 "SHARED");
　　 
　　 LPVOID pVoid=MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,0,0);
　　 memset(pVoid,0,100);
　　 strcpy((char *)pVoid,"this is a mapping file test");
　　HANDLE hDes=FindWindow(NULL,"MAPPING"); // 对象窗口的名称
　　SendMessage(hDes, WM_DATACOMING,0,0);
　　CloseHandle(hFilemap);
　　UnmapViewOfFile(pVoid);
　　 
　　进程B(拥有窗口名称为MAPPING)
　　 
　　// WM_DATACOMING消息捕捉函数
　　HANDLE hFilemap=OpenFileMapping(NULL,NULL,"SHARED");
　　LPVOID pVoid=MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,0,0);
　　Label1->Caption=(char *)pVoid;
　　 
　　可以看到数据已经被正确的传送过来.
　　可能有些读者已经注意到,在这种情况下需要给映射对象取个名字(例子
　　中为SHARED),是的,在这种用途下需要给它取个名字,而在第一种应用
　　中这个地方可以被忽略.这里可能会引起打架的地方就是这个名字了,
　　如果多个进程创建了多个映射对象,根据名字来不是比较容易冲突了吗?
　　是的,这是个问题,笔者建议可以采用窗体的名称(MAPPING)或者别的
　　唯一的ID来使得不引起混淆.
　　 请注意这个函数:MapViewOfFile,注意到里面有个单词:Viewà视
　　这个函数是把创建好的映射对象真正提交到地址空间去,这就产生了
　　一个视.Windows中允许映射统一数据文件的多个视,比如说可以将
　　一个文件的全部映射到一个视,然后将他的前10K单独映射为一个视.
　　那么系统是不是真正区别这多个视呢?答案是要看是什么系统,
　　如果是Win9x,系统并没有额外再映射一个新的地址给它,而只是
　　把原先的基地址加上一个偏移量做为新的视的地址而返回,换句话
　　说地址空间只有一份,而WinNT则是真正的新产生了一个地址空间
　　返回来.
　　 看看下面这个小例子:
　　HANDLE hFilemap=CreateFileMapping((HANDLE)0xFFFFFFFF,
　　 NULL,
　　 PAGE_READWRITE,
　　 0,
　　 100,
　　 "SHARED");
　　// 提交整个地址给空间
　　LPVOID pVoid1=MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,0,0);
　　// 从偏移40产生一个新视
　　LPVOID pVoid2= MapViewOfFile(hFilemap,FILE_MAP_ALL_ACCESS,0,40,0);
　　If(pVoid1+40==pVoid2)
　　 MessageBox(“Run On Win95”);
　　else
　　 MessageBox(“Run On NT”);
　　 
　　 可以注意到返回的值为0x8…这符合地址列表中MappingFile的位置.必然在
　　“Server”中开启的映射对象的地址和”Client”中利用MapViewOfFile返回的地址

　　是一致的(9x环境).这也是因为这个部分的地址空间是大家共享的.
　　 那么既然是一样的,能不能直接使用这个值呢?比如上面的进程间共享数据
　　的例子:如果进程A的发送语句改为:
　　 // 把指针值作为参数传递
　　 SendMessage(hDes, WM_DATACOMING,(WPARAM) pVoid,0);
　　 
　　进程B的接受消息部分改为:
　　 LPVOID pVoid=(LPVOID)MSG.WPARAM;
　　 Label1->Caption=(char *)pVoid;
　　 
　　可以看到可以正确的显示出来,因为指针所指的地方的确是有这么一笔数据,
　　那么是不是意味着我们就能这么使用呢?答案是否定的,首先这个值相等
　　只是在Win9x的环境下,在NT环境下是不相等的,另外NT下访问这个地址
　　空间的时候要求一定要先使用MapViewOfFile函数.这是第一个原因,更加
　　重要的是内存映射对象属于内核对象(Kernal Object),这种对象的最大不同就
　　在于它是系统维护的一块数据结构,用户只能通过相应的接口函数进行间接
　　的访问.每访问一次就增加一个引用记数(reference count),当计数器变为0的
　　时候,系统自动释放这个内核对象.在上面的例子中,尽管Server端和Client
　　的值是一样的,但是如果Server端执行UnmapViewOfFile释放内核对象的时候,
　　这部分数据将会被系统释放掉,因为它的引用计数只是1,只有我们在Client
　　端使用MapViewOfFile增加这个对象的计数的时候,才不会被系统释放掉.
　　 
　　 堆
　　 Win32的堆位于进程私有空间内,属于自由分配区,比如大家在C++中常
　　使用的new操作符就是在这个地方分配的,关于堆的操作有HeapCreate
　　和HeapAlloc等,这里就不再继续讨论了.
　　 
　　后记
　　 Mapping File一直是个比较难以讨论的问题,在CSDN上也看到不少网友
　　讨论的比较模糊,最后不了了之.笔者对这个问题也一直想搞个明白,在看
　　Richter的大作的时候,因为内存这个部分是连在一起
　　的好几章,理论也比较抽象和繁杂,看的很是头痛.写出这篇文章也是希望
　　帮助大家更好的理解这个部分,对内存有着进一步的了解以便更好的开发程序.
　　有兴趣进一步研究者可联系 QQ:33854303
　　 
　　 二:相关流程
1) 新建命名共享内存
   首先利用CreateFile或者CreateFileForMapping获得一个用于映射的物理文件句柄, 然
后利用该文件句柄结合CreateFileMapping得到一个命名的共享内存映射文件句柄

2) 打开命名共享内存
   如果需要共享已经存在的命名共享内存映射文件, 使用OpenFileMapping函数

3) 获得地址空间指针
   进行内存映射文件的读写和一般的文件读写不同, 是直接面对你申请的地址空间, 为此
需要使用MapViewOfFile得到相关的地址LPVOID类型的指针.

   如果需要进行文件写入, 可以通过类型转换直接对于内存地址进行赋值, 比如:
   memcpy( lpAddress, lpBuf, ....)
   这里自然需要防止内存溢出的情况

   如果是读取操作, 呵呵将参数顺序调整一下就可以了

4) 将内存复制到所映射的物理文件上面
   FlushMapViewOfFile函数可以将内存里面的内容DUMP到物理磁盘上面

5) 卸载内存映射文件地址指针
   UnmapViewOffFile函数就是卸载

6) 关闭内存映射文件
   太简单了, CloseHandle搞定

三 Win 95下内存映射文件的工作原理

一、引言
　　WIN32 API为我们提供了一种进行文件操作的高效途径，即内存映射文件。内
存映射文件允许我们在WIN32进程的虚拟地址空间中保留一段内存区域，把目标文
件映射到这段虚拟内存之中。我们可以用存取内存数据的方式直接操作文件中的
数据，就好像这些数据放在内存中一样。而实际上，我们并没有、也不需要调用
API函数来读写文件，更不需要自己提供任何缓冲算法，操作系统将会为我们完成
这些工作。使用内存映射文件能给程序开发工作提供极大的方便，程序的运行效
率也非常高。
　　内存映射文件在Windows NT和Windows95中的实现机制略有不同，下面主要介
绍Windows95下内存映射文件的工作原理及使用方法。
　　二、Windows95如何管理WIN32进程的内存空间
　　内存映射文件的实现与Windows95的内存管理有密切的关系，因此先讨论一下
Windows95在运行WIN32进程时的内存管理与划分。
　　在Windows3.x下，所有Windows应用程序共享单一的地址空间，任何进程都能
够对这一空间中属于其他进程的内存进行读写操作，甚至可以存取操作系统本身
的重要数据。在这种环境中，编写不当的应用程序或者带有恶意的应用程序，就
可能破坏其他程序的数据或代码，使得系统运行不正常，严重时甚至会导致系统
崩溃。
　　在实现了WIN32的操作系统Windows NT和Windows95中，每个WIN32进程拥有自
己的地址空间，一个WIN32进程不能存取另一个进程地址空间的私有数据，两个进
程可以用具有相同值的指针寻址，但所读写的只是它们各自的数据，这样就大大
减少了进程之间的相互干扰，增强了系统的健壮性；另一方面，每个WIN32进程拥
有4GB的地址空间，但并不代表它真正拥有4GB的实际物理内存，而只是操作系统
利用CPU的内存分页功能提供的虚拟地址空间。在一般情况下，绝大多数虚拟地址
并没有物理内存与之对应，在真正可以使用这些地址空间之前，还要由操作系统
提供实际的物理内存。为虚拟地址提供实际物理内存的过程叫做“提交
”(Commit)。在不同情况下，系统提交的物理内存的类型是不同的，可能是
RAM，也可能是硬盘模拟的虚拟内存。

　　Windows95对WIN32进程地址空间的划分如下:
　　地址空间底部的4MB由Windows95用来维护与DOS和16位Windows的兼容性。理
想情况下，WIN32进程应该不能访问这段内存，但由于实现上的困难，Windows95
只能保护低端从0x00000000到0x00000FFF的4KB区域，这4KB区间用来捕获NULL指
针。从0x80000000到0xBFFFFFFF的1GB空间由所有的WIN32进程共享，内存映射文
件就使用这段地址空间。高端的1GB空间由Windows95自己使用，不像Windows NT
那样，这段空间也没有受到保护，任何进程都可能破坏其中的数据。
　　三、内存映射文件的工作原理
　　内存映射文件分三种情况，第一种是可执行文件的内存映射，主要由
Windows95自身使用；第二种是数据文件的内存映射；最后一种是借助于页面交换
文件的内存映射。应用程序可以使用后面两种内存映射文件。
　　1、可执行文件的内存映射
　　Windows95在执行一个WIN32应用程序时使用内存映射文件，它为将要执行的
EXE文件保留足够大的地址空间。一般情况下，这段空间是从WIN32进程的载入地
址0x00400000开始，系统给这段空间提交的物理存储就是硬盘上的EXE文件本身。
做好各项准备工作后，系统开始执行这个程序。刚开始，程序的代码并不在RAM中
，执行程序入口的第一条指令时会产生一个页面异常，系统捕获到这个异常后，
分配一块RAM，将其映射到0x00400000处，并把实际代码读入其中，然后继续执行
。以后在执行到不在RAM中的代码时，同样会产生页面异常，从而系统有机会读入
这些代码。系统以类似的方式处理WIN32DLL，只是DLL被映射到的地址空间是由所
有WIN32进程共享的。

　　当用户运行同一个应用程序的第二个实例时，系统知道程序已经有一个实例
了，EXE文件的代码和数据已经被读到RAM中，系统只需要把这段RAM再映射到新进
程的地址空间就行了，这就实现了共享RAM中的代码和数据。事实上，这种共享只
是针对只读数据，一旦出现进程改写自身代码和数据，操作系统会把被修改数据
所在页面拷贝一份，分配给执行写操作的进程，从而避免了多个实例之间的相互
干扰。
　　当然，操作系统执行一个WIN32应用程序的实际过程非常复杂，上面所描述的
只是工作原理。我们可以用Softicefor Windows95来验证操作系统是以映射文件
的方式来执行一个应用程序的：使用Wldr第一次调入一个应用程序如Notepad时，
Softice被激活。它所列出的程序的入口代码处全是Invalid（无效），这表明将
要执行的代码所在页面并不在RAM之中。按下F8，单步执行一条指令，屏幕上立刻
列出了真正的程序指令，这是因为指令执行时首先产生了一个页面异常，操作系
统在处理页面异常时，将代码读入RAM之中。Softice再次被激活时，就能看见刚
读入的指令了。进一步检查还可以发现，系统每次只读一个页面(4KB)到RAM中，
以便尽量节约内存。我们再用Wldr调入Notepad的第二个实例，这一次Softice被
激活后列出的入口代码不再是Invalid，而是真正的程序指令。由于Softice是系
统级的调试器，用它修改内存中的应用程序时，操作系统并不做页面拷贝。我们
将Notepad的入口代码做一点改动，然后再用Wldr调入第三个实例。这次可以发现
，列出的入口代码是刚刚修改过的，而实际的EXE文件并无任何变化，这表明，操
作系统把同一块RAM中的程序代码映射到多个进程的地址空间中，从而实现了共享
RAM中的程序代码。

　　2、数据文件的内存映射
　　数据文件内存映射的工作原理与可执行文件的内存映射原理是一样的。首先
把数据文件的一部分映射到虚拟地址空间（映射到的区域是在0x80000000－
0xBFFFFFFF内），但不提交RAM，存取这段内存的指令同样会产生页面异常。操作
系统捕获到这个异常后，分配一页RAM，并把它映射到当前进程发生异常的地址处
，然后系统把文件中相应的数据读到这个页面中，继续执行刚才产生异常的指令
。这就是应用程序自己不需要调用文件I/O函数的原因。
　　3、基于页面交换文件的内存映射
　　内存映射文件的第三种情况是基于页面交换文件的。一个WIN32进程可以利用
内存映射文件在WIN32进程共享的地址空间中保留一块区域，这块区域与系统的页
面交换文件相联系。我们可以用它来存储临时数据，但更常见的用法是，利用它
与其他WIN32进程进行通信。事实上，WIN32实现多进程间通信的各种方法都是通
过内存映射文件来实现的，例如PostMessage()函数或SendMessage()函数，在内
部都使用了内存映射文件。