Windows CE是微软为嵌入式设备打造的操作系统,CE操作系统必须是可定制.
Windows CE搭建出来的物体就是平台，是适应某种有固定标准的嵌入式设备的操作系统子集，最著名的平台是Pocket PC。
可以自己开发平台，开发工具是微软提供的Platform Builder，Platform Builder的版本号是和Windows CE的版本号一致的。
应用程序开发是针对特定平台的，我们在开发之前必须安装目标平台的SDK，才能够开发出适应目标平台的开发工具。
微软提供给应用程序开发者的工具包括：Embedded Visual Tools 3.0，其中包括Embedded Visual C++ 3.0和Embedded Visual Basic 3.0；Embedded Visual C++ 4.0和Visual Studio.NET。
开发工具的版本号是与Windows CE的版本号对应的。
开发环境和模拟器之间是通过网络连接协议进行通讯的，所以开发所用的计算机上必须有一个活动的网络连接。如果没有，可以安装微软的虚拟网卡。
EVC也是WinCE上的主流开发工具。EVC支持MFC类库的子集，可以给开发者提供最强大的支持，也使Win32平台上的VC程序员可以很容易地迁移到WinCE平台上。但由于MFC类库需要一个DLL，所以对某些存储空间有限的嵌入式设备来说，这是个很大的负担，所以SmartPhone就不支持MFC。
由于嵌入式设备支持的CPU种类很多，我们在选择创建工程类型的同时，也要把该工程所支持的CPU类型选择好。创建工程的过程和VC是一样的。当然不同的平台支持的工程类型是不同的，比如Pocket PC 2003有支持MFC和API的两种工程，而SmartPhone 2003则只有支持API的一种工程。
EVC中比VC环境中多了一行下拉菜单的选项，分别用来选择：工程、SDK、CPU类型和输出设备。以Pocket PC为例，在实际设备上调试应该选择Win32(WCE ARMV4)Debug ，而在模拟器上则需要选择Win32(WCE emulator)Debug。
Windows CE是基于Win32应用程序接口（API）的。
Windows CE的编程戒律，如"千万不要给Unicode（国际标准组织10646标准）字符分配奇数内存地址"。
大约有百分之九十的问题或多或少地与Unicode有关。尽管Unicode编程不难，但是，当给单字节字符编写代码时，很容易出错（我有过许多次错误）。
当用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设备上不可用，而你的软件最终要能在这些设备上运行。
你不要采用那些在写普通Win32或非Windows CE程序时使用的包含文件和库文件。
几乎所有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*/
不要将Unicode 字符串放入奇数内存地址
编辑器经常在这些问题上提醒你。你无法管理堆栈变量地址，并且编辑器会检查确定这些地址与变量类型是否相匹配。同样，运行时间库必须保证从堆中分配的内存总是满足一个word边界，所以你一般不必担心那两点。
在ANSI和Unicode字符串之间进行翻译，可采用MultiByteToWideChar()和WideCharToMultiByte () Win32 API 函数。
所以如果你想既要支持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()函数更难以限制目标指针所指向的字符串的长度。
选择正确的字符串比较函数
如果你要分类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()函数来区分大小写
不要使用相对路径
与Windows NT不一样，Windows CE没有当前目录这个概念，因此，任何路径只是相对于根目录而言的。如果你的软件给文件或目录使用相对路径，那么你很可能把它们移到别的地方了。例如，路径"./abc"在Windows CE中被当作"/abc"看待。
移走了对calloc()和 time()函数的调用
C运行库中的calloc()函数不能使用，但是malloc()函数可以代替calloc()函数。并且不要忘记，calloc()函数初始化时分配的内存为零，而malloc()函数不一样。同样，time()函数也不能使用，但你可以使用Win32函数GetSystemTime()函数代替time()函数。
经过以上的警告后，你会高兴地学习最后令你惊讶的两点忠告。
不需要改变Win32 输入/输出（I/O）文件的调用
Win32的输入输出函数，Windows CE也支持。允许你象访问Win32文件系统那样访问对象。CreateFile()函数在Windows CE中不能辩认标志FILE_FLAG_RANDOM_ACCESS，但是这个标志仅用作可选的磁盘访问，并且不影响函数调用的功能。
不要担心字节的状态
当我们把应用程序写入Windows CE时，有了一个美好的发现，那就是Windows CE的数字数据类型的字节状态与Intel结构的字节状态一样，在所有的处理器上，Windows CE均支持。
几乎象所有的数据库引擎一样，Raima数据库管理器在数据库文件中以二进制形式保存数字数据。这就意味一个记录无论何时写入数据库或从数据库读出，均被当作一系列的字节来处理，不管它域的内容。只要数据库文件不要传给别的任何系统，数字数据的字节状态问题就解决了。如果数据库文件被一个来自原始系统且带有不同字节状态的处理器访问，数字数据将被误解。
无论何时，当你在拥有不同处理器的机器上传输文件时，就会出现这个问题。在这个问题上，值得高兴的是所有类型的处理器都使用相同的字节状态。
在使用Windows CE时，这些忠告应该引起你足够的重视，避免学习时走弯路。