VirtualAlloc和VirtualCopy的蕴含知识点

wince下的地址映射知识点滴

posted on 2007

对外设进行 I/O 操作实际上也就是读写外设的寄存器,而我们通常使用的X86或者ARM处理器在硬件上决定了wince系统启动后,无法直接访问物理地址,因此需要做一些工作来实现I/O操作.

首先要理解 windows CE 下的地址映射机制。 wince有两种地址：物理地址和虚拟地址．不同架构的 CPU 硬件上的区别导致地址映射也不同。ＭＩＰＳ和ＳＨ x 处理器，不采用ＭＭＵ，直接在ＣＰＵ和内核里定义 1G 的物理地址；而Ｘ８６和ＡＲＭ带有 MMU 单元，在 OEMAddressTable 中定义物理地址到虚拟地址间的映射关系或者是ＯＳ启动后调用 CreateStaticMapping 和 NKCreateStaticMapping 来实现从虚拟地址到物理地址的静态映射．经过静态映射的地址，可以由操作系统内核用于 ISR 访问设备。如果我们要在应用程序中访问外设，必须在物理地址和虚拟地址间建立动态映射关系，我们可以使用 VirtualAlloc 和 VirtualCopy （或者直接调用 MmmapIoSpace 函数）来实现。

其次，如果是操作通过总线挂接的 I/O 或者存储器，必须先把总线地址转化成 CPU 上的系统地址，再做物理地址到虚拟地址的映射。这里需要查 CPU 的 Datasheet ，找出所要操作的I/O地址.先调用 HALTranslateBusAddress( )把总线地址转化成CPU上的系统地址, 再调用 MmmapIoSpace 函数实现虚实映射；也可以使用 TransBusAddrToVirtual （）直接把总线上的地址转化成系统的虚拟地址。

第三，在一般的应用程序中访问 I/O 是访问它的缓存段虚拟地址，而驱动中必须访问无缓存段虚拟地址。简单来说无缓存段虚拟地址 = 缓存段虚拟地址 +0x20000000 。 
    总结起来，如果是 wince 内核(如HAL)访问外部 I/O ，只需要在 OEMAddressTable 中定义物理地址到虚拟地址间的映射关系就可以了；
如果是应用程序或者驱动要访问 I/O ，
要做的工作包括：
1 。在 CPU 物理地址和虚拟地址间做一个动态映射，
 2 。对虚拟地址进行操作。

C#如何调用VirtualAlloc()和VirtualCopy()函数？
在程序前面加上: #include<window.h>
这样声明:
public static class API
{

[DllImport( "Kernel32.dll", CharSet = CharSet.Ansi, EntryPoint = "VirtualAlloc" )]
public static extern IntPtr VirtualAlloc(
IntPtr lpAddress,
uint dwSize,
uint flAllocationType,
uint flProtect );


[DllImport( "Coredll.dll", CharSet = CharSet.Ansi, EntryPoint = "VirtualCopy" )]
public static extern bool VirtualCopy(
IntPtr lpvDest,
IntPtr lpvSrc,
uint cbSize,
uint fdwProtect );
}

将已有的应用程序移植到Microsoft Windows CE中。一般说来，这个计划不是太难。我们起步于Microsoft Win32代码，当然Windows CE是基于Win32应用程序接口（API）的。有利的是，我们的应用程序（即Raima 数据管理器）有方便的使用接口，并包含一个大约由150个子函数组成的库，这些函数都是由C语言写成，可以用来创建、管理和访问数据库。

　　按建立应用程序的方式来说，我们原以为将它移植到Windows CE中是一项相对简单的C语言编程练习。然而，我们不久便遇到好些困难。从粗心大意的错误开始，比如在基于Windows NT 的Windows CE仿真器上使用Microsoft Windows NT库，接着又违背Windows CE的编程戒律，如"千万不要给Unicode（国际标准组织10646标准）字符分配奇数内存地址"。

　　大约有百分之九十的问题或多或少地与Unicode有关。尽管Unicode编程不难，但是，当给单字节字符编写代码时，很容易出错（我有过许多次错误）。

　　下面这些忠告是根据我们在Windows CE上编写Raima 数据管理器的经验总结出来的，但我相信，在做任何其它Windows CE程序之前，它们都值得借鉴。毕竟大多数Windows开发者，当他们创建第一个Windows CE应用程序时，真正运用的是已掌握的Win32知识。

　　1. 不要在仿真器上使用Windows NT库

　　这里所讨论的第一个错误实在太愚蠢了，但我还是陷了进去，也许你也会。当用Microsoft VC++（5.0版）创建一个Windows CE程序时，你会发现，包含路径（include）、 库路径（library）、及可执行程序路径被自动调整以匹配反应目标环境的选择。因此，比如说为Windows CE模拟器建立应用程序时，你会发现，include路径没有指向Win32的包含文件（在VC目录下），而是指向Windows CE包含文件（在WCE目录下）。千万别去修改。

　　由于Windows CE在Windows NT下运行，所以仿真器上运行的程序能够调用任一Windows NT动态链接库(DLL)中的函数，即使这个DLL不是模拟器的成员也一样。显然，这不是很好的事，因为相同的函数也许在手持PC(H/PC)或Windows CE设备上不可用，而你的软件最终要能在这些设备上运行。

　　第一次将非Unicode应用程序装入Windows CE仿真器时，你会发现，许多正在使用的函数它都不支持，例如美国国家标准协会(ANSI)定义的字符函数strcpy()。这也许引诱你去链接Windows NT 运行时间库，以便能解决所有问题。

　　如果你是刚开始用Windows CE编程，可能你能用的包含文件和库文件是明显的。答案就是，你不要采用那些在写普通Win32或非Windows CE程序时使用的包含文件和库文件。

2. 不要混淆TCHARs和bytes

　　如果你正在Windows CE上写非Unicode应用程序，你或许要将所有的字符串从单个字符(chars)转换为宽字符(widechars)（例如，C变量类型whcar_t）。几乎所有Windows CE支持的Win32和运行时间库函数都要求宽字符变量。Windows 95不支持Unicode，然而，为了使程序代码具有可移植性，你要尽可能采用tchar.h中定义的TCHAR类型，不要直接使用wchar_t。

　　TCHAR是定义为wchar_t还是char，取决于预处理器的符号UNICODE是否定义。同样，所有有关字符串处理函数的宏，如_tcsncpy宏，它是定义为Unicode函数wcsncpy还是定义为ANSI函数strncpy，取决于UNICODE是否定义。

　　在现存的Windows应用程序中，有些代码也许暗示字符长为单字节。这在给字符串分配内存时经常用到，例如：

int myfunc(char *p)
{
char *pszFileName;

pszFileName = malloc(MAXFILELEN);
if(pszFileName)
strncpy(pszFileName, p, MAXFILELEN);
/*etc*/

　　在这段代码中，分配的内存块应该写作(MAXFILELEN * sizeof(char))，但是大多数程序员喜欢将它简化为MAXFILELEN，因为对于所有的平台来说sizeof(char)的值等于1。然而，当你用TCHARS代替多个字符时，很容易忘记这种固有的概念，于是将代码编写成下面的形式：

int myfunc(TCHAR *p)
{
TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN);
If (pszFileName)
tcsncpy(pszFileName, p, MAXFILELEN);
/*etc*/

　　这是不行的。它马上会导致出错。这里的错误在于malloc函数中指定变量大小为bytes，然而_tcsncpy函数中使用的第三个变量却指定为TCHARs而不是bytes。当UNICODE被定义时，一个TCHAR等于两个字节数(bytes)。

　　上述代码段应该改写为：

int myfunc(TCHAR *p)
{
TCHAR *pszFileName;

PszFileName = (TCHAR*)malloc(MAXFILELEN * sizeof(TCHAR));
if(pszFileName)
tcsncpy(pszFileName, p, MAXFILELEN);
/*etc*/

　　3. 不要将Unicode 字符串放入奇数内存地址

　　在Intel系列处理器上，你可以在一奇数内存地址储存任何变量或数组，不会导致任何致命的错误影响。但在H/PC上，这一点不一定能行 ? 你必须对大于一个字节的数据类型小心谨慎，包括定义为无符号短型（unsigned short） 的wchar_t。当你设法访问它们的时候，将它们置于奇地址会导致溢出。

　　编辑器经常在这些问题上提醒你。你无法管理堆栈变量地址，并且编辑器会检查确定这些地址与变量类型是否相匹配。同样，运行时间库必须保证从堆中分配的内存总是满足一个word边界 ，所以你一般不必担心那两点。但是，如果应用程序含有用memcpy()函数拷贝内存区域的代码，或者使用了某种类型的指针算术以确定内存地址，问题也许就出现了。考虑下面的例子：

int send_name (TCHAR * pszName)
{
char *p, *q;
int nLen=(_tcslen(pszName) + 1) * sizeof(TCHAR);

p=maloc(HEADER_SIZE + nLen);
if(p)
{
q = p + HEADER_SIZE;
_tcscpy((TCHAR*)q, pszName);
}
/* etc */

　　这段代码是从堆中分配内存并复制一个字符串，在字符串的开头留一个HEADER_SIZE的大小。假设UNICODE定义了，那么该字符串就是一个widechar字符串。如果HEADER_SIZE是一个偶数，这段代码就会正常工作，但如果HEADER_SIZE为奇数，这段代码就会出错，因为q指向的地址也将为奇数。

　　注意，当你在Intel系列处理器中的Windows CE仿真器上测试这段代码时，这个问题是不会发生的。

　　在这个例子中，只要确保HEADER_SIZE为偶数，你就可以避免问题的发生。然而，在某些情况下你也许不能这么做。例如，如果程序是从一台式PC输入数据，你也许不得不采用事先定义过的二进制格式，尽管它对H/PC不适合。在这种情况下，你必须采用函数，这些函数用字符指针控制字符串而不是TCHAR指针。如果你知道字符串的长度，就可以用memcpy()复制字符串。因此，采用逐个字节分析Unicode字符串的函数也许足以确定字符串在widechars中的长度。

　　4. 在ANSI和Unicode字符串之间进行翻译

　　如果你的Windows CE应用程序接口于台式PC，也许你必须操作PC机中的ANSI字符串数据（例如，char字符串）。即使你在程序中只用到Unicode字符串，这都是事实。

　　你不能在Windows CE上处理一个ANSI字符串，因为没有操纵它们的库函数。最好的解决办法是将ANSI字符串转换成Unicode字符串用到H/PC上，然后再将Unicode字符串转换回ANSI字符串用到PC上。为了完成这些转换，可采用MultiByteToWideChar()和WideCharToMultiByte () Win32 API 函数。

5. 对于Windows CE 1.0的字符串转换，劈开（hack）

　　在Windows CE 1.0 版本中，这些Win32API函数还没有完成。所以如果你想既要支持CE 1.0又能支持CE 2.0，就必须采用其它函数。将ANSI字符串转换成Unicode字符串可以用wsprintf()，其中第一个参数采用一widechar字符串，并且认识"%S"(大写)，意思是一个字符串。由于没有wsscanf() 和 wsprintfA()，你必须想别的办法将Unicode字符串转换回ANSI字符串。由于Windows CE 1.0不在国家语言支持(NLS)中，你也许得求助于hack，如下所示：

/*
Definition / prototypes of conversion functions
Multi-Byte (ANSI) to WideChar (Unicode)

atow() converts from ANSI to widechar
wtoa() converts from widechar to ANSI
*/
#if ( _WIN32_WCE >= 101)

#define atow(strA, strW, lenW) \
MultiByteToWidechar (CP_ACP, 0, strA, -1, strW, lenW)

#define wtoa(strW, strA, lenA) \
WideCharToMutiByte (CP_ACP, 0, strW, -1, strA, lenA, NULL, NULL)

#else /* _WIN32_WCE >= 101)*/

/*
MultiByteToWideChar () and WideCharToMultiByte() not supported o-n Windows CE 1.0
*/
int atow(char *strA, wchar_t *strW, int lenW);
int wtoa(wchar_t *strW, char *strA, int lenA);

endif /* _WIN32_WCE >= 101*/

#if (_WIN32_WCE <101)

int atow(char *strA, wchar_t *strW, int lenW)
{
int len;
char *pA;
wchar_t *pW;

/*
Start with len=1, not len=0, as string length returned
must include null terminator, as in MultiByteToWideChar()
*/
for(pA=strA, pW=strW, len=1; lenW; pA++, pW++, lenW--, len++)
{
*pW = (lenW = =1) ? 0 : (wchar_t)( *pA);
if( ! (*pW))
break;
}
return len;
}

int wtoa(wxhar_t *strW, char *strA, int lenA)
{
int len;
char *pA;
wchar_t *pW;
/*
Start with len=1,not len=0, as string length returned
Must include null terminator, as in WideCharToMultiByte()
*/
for(pA=strA, pW=strW, len=1; lenA; pa++, pW++, lenA--, len++)
{
pA = (len==1)? 0 : (char)(pW);
if(!(*pA))
break;
}
return len;
}

#endif /*_WIN32_WCE<101*/

　　这种适合于Windows CE 1.0的实现办法比使用wsprintf()函数要容易，因为使用wsprintf()函数更难以限制目标指针所指向的字符串的长度。

　　6. 选择正确的字符串比较函数

　　如果你要分类Unicode标准字符串，你会有以下几个函数可供选择：

wcscmp(), wcsncmp(), wcsicmp(), 和wcsnicmp()

wcscoll(), wcsncoll(), wcsicoll(),和wcsnicoll()

CompareString()

　　第一类函数可用来对字符串进行比较，不参考当地（Locale）或外文字符。如果你永远不想支持外文，或者你仅仅想测试一下两个字符串的内容是否相同，这类函数非常好用。

　　第二类函数使用现有的当地设置(current locale settings)（系统设置，除非你在字符串比较函数之前调用了wsetlocale()函数）来比较两个字符串。这些函数也能正确分类外文字符。如果当地的字符"C"（"C" locale）被选定，这些函数与第一类函数就具有了相同的功能。

　　第三类函数是Win32函数CompareString()。这个函数类似于第二类函数，但是它允许你指定当地设置（the locale）作为一个参数，而不是使用现有的当地设置(current locale settings)。CompareString()函数允许你选择性地指定两个字符串的长度。你可以将第二个参数设置为NORM_IGNORECASE，从而使函数比较字符串时不比较大小写。

　　通常，即使不将第二个参数设置为NORM_IGNORECASE，CompareString()函数也不用来区分大小写。我们经常用wcsncoll()函数来区分大小写，除非使用当地的字符"C"（"C" locale）。所以，在我们的代码中，不使用CompareString()函数来区分大小写，而用wcsncoll()函数来区分大小写

　　7. 不要使用相对路径

　　与Windows NT不一样，Windows CE没有当前目录这个概念，因此，任何路径只是相对于根目录而言的。如果你的软件给文件或目录使用相对路径，那么你很可能把它们移到别的地方了。例如，路径".\abc"在Windows CE中被当作"\abc"看待。

　　8．移走了对calloc()和 time()函数的调用

　　C运行库中的calloc()函数不能使用，但是malloc()函数可以代替calloc()函数。并且不要忘记，calloc()函数初始化时分配的内存为零，而malloc()函数不一样。同样，time()函数也不能使用，但你可以使用Win32函数GetSystemTime()函数代替time()函数。

　　经过以上的警告后，你会高兴地学习最后令你惊讶的两点忠告。

　　9. 不需要改变Win32 输入/输出（I/O）文件的调用

　　Win32的输入输出函数，Windows CE也支持。允许你象访问Win32文件系统那样访问对象。CreateFile()函数在Windows CE中不能辩认标志FILE_FLAG_RANDOM_ACCESS，但是这个标志仅用作可选的磁盘访问，并且不影响函数调用的功能。

　　10. 不要担心字节的状态

　　当我们把应用程序写入Windows CE时，有了一个美好的发现，那就是Windows CE的数字数据类型的字节状态与Intel结构的字节状态一样，在所有的处理器上，Windows CE均支持。

　　几乎象所有的数据库引擎一样，Raima数据库管理器在数据库文件中以二进制形式保存数字数据。这就意味一个记录无论何时写入数据库或从数据库读出，均被当作一系列的字节来处理，不管它域的内容。只要数据库文件不要传给别的任何系统，数字数据的字节状态问题就解决了。如果数据库文件被一个来自原始系统且带有不同字节状态的处理器访问，数字数据将被误解。

　　无论何时，当你在拥有不同处理器的机器上传输文件时，就会出现这个问题。在这个问题上，值得高兴的是所有类型的处理器都使用相同的字节状态。

　　在使用Windows CE时，这10点忠告应该引起你足够的重视，避免学习时走弯路。

学习过windows编程的人，都明白windows的消息处理机制，在Windows CE中继承了这种机制。

为了能够获得消息，需要调用GetMessage函数
通常一个工程在消息循环中调用GetMessage函数

下面的代码，显示了如何在消息循环中调用GetMessage函数

while (GetMessage(&msg, NULL, 0, 0))
{

TranslateMessage(&msg);

DispatchMessage(&msg);

}

当一个线程调用GetMessage函数时，Windows CE检测消息队列，Windows CE按照以下的步骤处理消息：

（1）Windows CE检测消息队列，这些消息是通过SendMessage函数产生的。当系统从消息队列提取消息后，它通过GetMessage函数将消息发送到适当地窗体过程，这样就可以保证消息的发送和接收保持同步。必须通过调用GetMessage函数才能保证消息被处理。

（2）如果没有通过SendMessage得到的消息，Windows CE检测由PostMessge发送的消息队列。

（3）如果没有通过PostMessage得到的消息，Windows CE检测用户用户输入消息。
在处理用户输入消息时，系统保证在处理下一个消息以前已经处理结束前一个输入的消息。

（4）如果没有用户输入消息，Windows CE检测WM_QUIT消息，该消息是由PostQuitMessage函数发送的。

（5）如果没有WM_QUIT消息，Windows CE检测WM_PAINT消息。

（6）如果没有WM_PAINT消息，Windows CE检测WM_TIMER消息

当GetMessage接收到任何消息，它返回消息的内容，该线程必须调用DispatchMessage函数来把消息发送到正确的窗体处理过程。如果这个消息是WM_QUIT消息，GetMessage函数的返回值为0，触发线程结束消息循环。

系统处理的消息是通过GetMessage函数在消息循环中的调用，又通过在消息循环中调用DispatchMessage函数来处理分派消息。

在通过DispatchMessage函数分发通过GetMessage得到的函数以前，用户可能需要处理这些消息，最常用的函数就是TranslateMessage, TranslateAccelerator, 和IsDialogMessage这三个函数。其中的一些函数可以自己分发消息，这样就必再次调用DispatchMessage来分发消息。

WINDOWS CE的消息处理机制(二）

用户通常使用TranslateMessage函数。该函数可以决定哪些字符对应相应的键盘消息。该函数同时也可以将字符发送到消息队列中，让下一次消息循环继续处理。

截取键盘消息产生菜单命令，用户可以调用TranslateAccelerator 函数，要对无模式对话框进行适当的操作需调用IsDialogMessage函数。

下面的例子向用户显示一个消息循环的例子，它使用到了DispatchMessage函数, TranslateMessage函数, TranslateAccelerator函数,和IsDialogMessage函数以及GetMessage函数。

while (GetMessage(&msg, NULL, 0, 0))
{

if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))

{

if (hwndDLGCurrent != NULL || !IsDialogMessage(hwndDLGCurrent,

&msg))

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}
}
}

用户可以通过GetMessage函数取得消息队列中的事件，并且从消息队列中去除该消息，用户也可以用PeekMessage函数从一个消息队列中获得消息，但却不必从消息队列中去除它。

通过该函数可以把有关消息的信息填充到MSG结构中。使用PeekMessage函数时要小心，因为它并不会阻止消息的等待，这样一个程序就会不管消息队列中是否有消息而不停地运行，这样CPU就不会处于low-power 模式，从而导致电池用电量过大。

当处理消息的时候，Windows CE不仅支持系统定义的消息同时也支持用户自定义的消息。系统消息定义从0到0x3ff，用户可以使用0x400到0x7fff定义自己的消息。Windows CE把0x400定义为WM_USER。如果用户想定义自己的一个消息。可以在WM_USER上加上一个值。下面的过程讲述了如何进行自定义消息。

#define WM_MYNEWMESSAGE (WM_USER + 999)

有两种系统定义的消息，一种是窗体消息，使用于所有的窗体，还要一种是特殊目的的消息，应用于一定的窗体类。通常的窗体消息覆盖的范围非常大，包括输入设备和一些键盘的消息，同时也包括一些如窗体建立和管理的消息。 一定的消息包含有特定的前缀，比如说，一个通常的WINDOWS消息通常以WM开头，属于按钮的消息通常以BM开头。

用户可以定义自己的消息，如果定义消息，一定要保证窗体过程争取地接收和解释消息，因为操作系统不会自动地处理用户定义的消息。

偶尔，用户也需要通过消息和别的进程中的休息保持通信。这种情况下，用户必须通过调用RegisterWindowMessage 函数来注册一个消息句柄。这样就可以保证消息号在整个系统中是唯一的，从而避免了不同的进程使用相同的消息号，造成冲突。

Windows CE不支持钩子函数，因为钩子函数需要的额外进程会不利于WINDOWS CE的执行。

在一个程序中处理消息序列时，请注意WM_HIBERNATE 消息。WINDOWS CE在系统资源不足时，通过WM_HIBERNATE 消息来通知应用工程。当一个工程接受到这个消息，它就会尽可能地释放资源。系统每隔五秒钟检测一次系统内存状态。

每一个WINDOWS CE的应用工程由于要适当地使用内存，所以都要能接收WM_HIBERNATE 消息。

如果一个应用工程的窗口不可见，该工程不能接收WM_HIBERNATE 消息。之所以收不到该消息，是因为WM_HIBERNATE 消息仅仅被发送到一个在任务栏上有相应菜单的工程。一个隐藏的窗体即使是占用内存很多，也不会接收到该消息。