世界上最先进的嵌入式GUI开发工具EmbeddedWizard, 现在新出了一个4.4版本,我download回来试了一下,发现已经支持touch screen & mouse了. 已经是 perfect 的EmbeddedWizard, 以后会不会还有激动人心的新特性呢

  preview some simple GUI examples designed by EW :

    

Memory marshalling in Windows CE
by Sue Loh
Although the subject is memory access, this presentation is primarily about drivers, how drivers used to work in CE5 and how they will work in CE6. That's because it's most urgent for BSP and driver developers to understand how their code is going to have to change. But these explanations also cover system servers: how the implementations of APIs and services work. Drivers and servers work the same way.

Let's begin with some quick definitions related to passing a pointer from client to server. Each term will be covered in more detail as we go.

• Pointer parameter: A pointer that's passed as a parameter to an API.
  
• Embedded pointer -- A pointer that's passed to an API by storing it inside a buffer.
  
• Access Checking -- Verifying that the caller process has privilege to access a buffer.
  
• Marshalling -- Preparing a pointer that a server can use to access a caller's buffer.
  
• Secure-copy -- Making a copy of a buffer to prevent against asynchronous modification by the caller.
  
• Synchronous -- Accesses during an API call, on the caller's thread.
  

A pointer parameter is a pointer that's passed as a parameter to an API. For example, the pBuffer parameter to the ReadFile() API is a pointer parameter.

ReadFile (hFile, pBuffer, dwBufferSize, ...);

An embedded pointer is a pointer that's passed to an API by storing it inside a pointer parameter, or nested inside another embedded pointer. For example, while the pMyStruct parameter to the following DeviceIoControl() call is a pointer parameter, the pEmbedded pointer that is stored inside MyStruct is an embedded pointer.

struct MyStruct  {
    BYTE *pEmbedded;
    DWORD dwSize;
};
DeviceIoControl (hFile, pMyStruct, sizeof(MyStruct), ...);

Pointers that are passed by other means, for example by storing them inside shared memory or by using SetEventData() to attach them to an event, end up having all the same properties as embedded pointers and so should be treated as such.

Access checking is verifying that the caller of an API has enough privilege to access a buffer that it passed to the API. (Access checking is not limited to memory, but in this case I'm only defining it with regard to memory.) The reason access checking is necessary is to prevent malicious applications from being able to induce driver code to perform actions on their behalf. Drivers have a lot of privilege, and can access a lot of system data. Applications can not. If a malicious application could cause a driver to read or write system memory on its behalf, then that driver is essentially granting the malicious application access to data it should not. Proper access checking inside the driver can protect system memory.

In CE5:

• Drivers used MapCallerPtr() to access-check pointer parameters and embedded pointers. The CE5 kernel also redundantly access-checked pointer parameters, but had no way to know the size of the buffers being passed. So it only checked the caller's access to a single byte of the buffer.
  
• The access was granted or denied based on the "trust level"?of the caller process.
  

In CE6:

• The API call definitions were changed to also include the sizes of pointer parameters. So the kernel now performs a full access check on pointer parameters. (I will explain this in more detail when I post about how API calls are implemented in CE6.)
  
• Drivers only need to access check embedded pointers, and they do this using the new API CeOpenCallerBuffer(). This API is also responsible for marshalling the data, as explained below.
  
• The access is granted or denied based on whether the caller is the kernel or a user-mode process. (It may change to a more granular determination in the future, based on privilege levels.)
  

Synchronous memory access is done during an API call, on the caller's thread. If a driver has a thread which accesses the other process' memory after the API call returns, that's asynchronous access. But just as significantly, if the driver has a thread which is guaranteed to access the other process' memory during the course of the API call -- before it returns -- for the purpose of this discussion, that access is asynchronous too.

Pointer mapping or marshalling is the preparation of a pointer that a driver can use to access a caller's buffer. Drivers run inside a different process than the application which calls them. The virtual memory space of every process is, by default, protected against access by other processes. A driver must do some work in order to access a buffer inside another process' memory.

In CE5, all processes shared a common address space. To obtain a pointer to its caller's memory, a driver would have to "map" the pointer into that process' address space. "Mapping" was a simple transformation of the pointer value, to make it point at the other process "slot" inside the common address space. The picture here shows device.exe accessing data in-place inside its caller.

In CE6, each process has its own unique address space. Marshalling memory cannot be as simple as a pointer transformation. Either the memory must be copied from one process to another (duplication) or a new virtual address must be allocated in the driver process and pointed at the same physical memory the caller was using (aliasing). Either way, resources are allocated inside the driver process, and must be freed when the driver is done with them. The following pictures show a marshalled version of the caller's buffer being created inside the kernel (for kernel-mode drivers) or udevice.exe (for user-mode drivers.)


The CE6 marshalling is also more formalized about declaring whether the buffer is in-only, in/out or out-only. Based on these settings, the marshalling helpers will ensure that copy-in and copy-out happen at the appropriate times. They are also used for access checking, for example a user-mode application cannot pass a shared heap address (which is read-only to applications) as an in/out or out-only parameter.

To explain what drivers must do to marshal memory, it is simpler to examine synchronous and asynchronous accesses separately. First, for synchronous access:

• The kernel automatically maps or marshals pointer parameters.
  
• The driver must take care of embedded pointers. In CE5, drivers used MapCallerPtr() for this. In CE6, drivers use CeOpenCallerBuffer() to marshal embedded pointers, and CeFreeCallerBuffer() when they are done.
  

Both MapCallerPtr and CeOpenCallerBuffer have the added benefit that they access-check the buffer as they prepare it for use.

Asynchronous accesses are more complicated. In CE5, Additional work must be done to access the caller's memory on a different thread. Each process "slot" was protected from access by other processes. Each thread had a its own set of "permissions" to access the various process slots. As the caller's thread jumped into the driver, it carried with it permission to access its owner process slot. So accesses to caller's memory would succeed as long as they were done on that thread. Other threads would first have to obtain permission to access to the other process slot.

In CE6, like CE5, additional work must be done to access the caller's memory on a different thread. The reasons are different, and not as easy to explain. The way memory is marshalled differs between kernel mode and user mode, and differs between pointer parameters and embedded pointers. The only way to guarantee that the driver code is going to work properly in all modes is to prepare buffers for asynchronous access before accessing them on another thread.

For asynchronous access, pointer parameters and embedded pointers are handled the same way. Assuming that we start with a buffer that is already mapped or marshalled for synchronous access, the steps a driver must take in order to access it asynchronously are:

• In CE5, a driver must call SetProcPermissions() on its asynchronous thread, in order to access a buffer in a different process.
  
• In CE6, a drivers must call CeAllocAsynchronousBuffer() to prepare an "asynchronous ready" version of the buffer that is already prepared for synchronous use. That call must be made synchronously, before passing the buffer to the asynchronous thread. When the thread is done with the buffer, it calls CeFreeAsynchronousBuffer() to release the resources associated with it.
  

Also, unfortunately, not all asynchronous cases are supported for user-mode drivers. What a user-mode driver cannot do is asynchronously write back to a pointer parameter. Kernel-mode drivers always work, embedded pointers always work, and read-only pointers (no write-back to the caller) always work fine too. I personally feel more comfortable saying that we simply don't support asynchronous access in user-mode drivers. If people listen to that, they can never get into trouble. If your driver needs asynchronous access to caller buffers, in CE6 you should run it in kernel mode. (Or if it's an option, rearchitect your protocol so that caller memory access is never asynchronous, eg. notify the caller that data is ready and have them call back into your driver to retrieve it.)

Other details for production quality drivers

You may say that the following two topics, secure copy and exception handling, are not part of memory marshalling. But they are required in today's world for safely receiving memory from other processes, and I believe that any discussion of memory passing is not complete without covering them.

There is a security risk a lot of developers are not aware of: callers can modify the buffers they pass, while a driver is still using it. The caller application could have a secondary thread which manipulates the data in a buffer while the primary thread is inside a driver call. Malicious applications could manipulate embedded pointers to get access to memory they shouldn't, or cause buffer overruns by manipulating buffer sizes, or cause other problems like exceptions and leaks. To prevent against this class of attacks, drivers must make a copy of the caller's data, called a secure copy, to prevent the caller from modifying it asynchronously.

For my first example of an attack that can be prevented using secure copies, imagine that the caller passes an embedded pointer to a driver. The driver uses MapCallerPtr (in CE5) or CeOpenCallerBuffer (in CE6) to access check the pointer and map/marshal it for use. If the driver continues to store that pointer into the caller's buffer, the caller could later manipulate it to point at other memory, and the driver would access the wrong memory. Drivers must make copies of the pointers they receive from callers to prevent asynchronous modification. Similarly, drivers must make copies of buffer size values they get from callers.

So, always copy embedded pointers to a local variable. This is easily accomplished as part of mapping/marshalling since you have to call MapCallerPtr or CeOpenCallerBuffer anyway. Never store the mapped/marshalled pointer back to the caller's buffer. Never use the pointer in the caller's buffer after it has been mapped/marshalled. Treat buffer size and length variables with the same caution, so that callers cannot manipulate sizes any more than they can manipulate pointers.

My second example of why secure copy is necessary involves file names. The CreateFile API, which takes a file name, validates that the caller is allowed to access that file. Suppose CreateFile read the file name, checked access, then used the file name to open the file when the access check passed. If the caller passes the name of a file it can access, then asynchronously changes it to a file name the caller is NOT supposed to be able to access, then there is a small window of time in which the caller could trick CreateFile into opening a file it's not supposed to. Perhaps it would only be able to get access 1 percent of the tries, but a hacker program could keep trying and trying until the trick worked. It only has to work once in order to compromise system security. The way to protect against this type of attack is that CreateFile must make a copy of the filename, in memory that the caller cannot access, before validating the caller's access to that file. (By the way, the OS already does a secure-copy of the file name before passing it to a driver's CreateFile in CE6, this is just a thought experiment.)

You should make a copy of any data that requires validation, to prevent asynchronous modification after the validation is done. Making a secure copy can be as simple as copying a buffer or pointer into a stack variable. Or you could make a temporary heap allocation to copy the caller's data into. You will notice that CeOpenCallerBuffer has a ForceDuplicate parameter you can use to guarantee that you get a secure copy of an embedded buffer. We've also created a CeAllocDuplicateBuffer helper function that you can choose to use. (It is basically a heap alloc, with memcpy as necessary for copy-in or copy-out.) It does not matter how you make the secure copy, as long as you do something to protect the data you take from callers.

Similar to secure copy is how drivers must use exception handling to protect their access of caller memory. It is important to note that, even if a caller has access to an address, that address may not refer to valid memory. An application can pass a pointer to a user-mode address that was never allocated. Or it could asynchronously free the buffer. So, drivers should always surround user buffer accesses with try/except blocks, and clean up resources during __except or __finally. For example, make sure to free memory that was allocated during the call, and release any critical sections, before returning to the caller.

In Summary

As you can see, passing memory between processes is a complicated matter. But don't despair. There are relatively simple rules governing drivers, as covered in the following table.

Use Case	What the driver must do in CE6
Parameter -- used synchronously	If a secure copy is necessary, make a copy yourself or use CeAllocDuplicateBuffer. Otherwise just use the pointer.
Parameter -- used asynchronously	If a secure copy is necessary, make a copy yourself or use CeAllocDuplicateBuffer / CeFreeDuplicateBuffer. Otherwise use CeAllocAsynchronousBuffer / CeFreeAsynchronousBuffer.
Embedded pointer -- used synchronously	Use CeOpenCallerBuffer / CeCloseCallerBuffer to marshal and secure-copy as necessary.
Embedded pointer -- used asynchronously	Call CeOpenCallerBuffer and then CeAllocAsynchronousBuffer. You must call CeFreeAsynchronousBuffer before you call CeCloseCallerBuffer.

... and remember, always use try/except so you can clean up properly if you get exceptions on caller memory!

One other tip: CE6 has some helper C++ classes to simplify your usage of these APIs. In public\common\oak\inc\marshal.hpp you will find:

• MarshalledBuffer_t -- wrapper for CeOpenCallerBuffer, CeAllocAsynchronousBuffer, and their cleanup functions. Use for all of your embedded pointers.
  
• DuplicatedBuffer_t -- wrapper for CeAllocDuplicateBuffer and its free. Use for pointer parameters that need a secure copy.
  
• AsynchronousBuffer_t -- wrapper for CeAllocAsynchronousBuffer and its free. Use for pointer parameters you need to access asynchronously.
  

The C++ version of the table then becomes:

Use Case	What the driver must do in CE6
Parameter -- used synchronously	If a secure copy is necessary, use DuplicatedBuffer_t. Otherwise just use the pointer.
Parameter -- used asynchronously	If a secure copy is necessary, use DuplicatedBuffer_t. Otherwise use AsynchronousBuffer_t.
Embedded pointer	Use MarshalledBuffer_t.

... and always use try/except!


Copyright (c) 2006 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published on the Windows CE Base Team Blog, here.

---

About the author: Sue Loh has been a developer on the Windows CE team for just over six years, spending the past couple of years working on system performance and tools for diagnosing performance problems, such as the kernel profiler and CeLog. She's also worked on the file system, registry and databases (CEDB), and from time to time has dabbled in parts of the kernel.

CE6 drivers: what you need to know by Sue Loh
Many, in fact most, device drivers will need modifications in order to run on CE6. While binary compatibility (being able to run the exact same driver without a rebuild) is not likely, we do expect it to be easy to port almost all drivers. That was our goal once we realized many drivers would have to change.

The primary reasons that drivers will need change are:

• Deprecated APIs
  
• Memory passing
  
• Asynchronous buffer access
  
• User interface handling

The biggest difference in CE6 is how drivers access embedded pointers and other data, as I described in detail in my earlier article on memory marshalling. There are two main things you need to do to fix memory accesses. First, look through your existing code for calls to mapping APIs like MapCallerPtr or MapPtrToProcess, and convert them to calls to marshalling APIs like CeOpenCallerBuffer / CeCloseCallerBuffer. Second, look for calls to SetKMode and SetProcPermissions. They most likely correspond to asynchronous memory access, for which you'll now need CeAllocAsynchronousBuffer / CeFreeAsynchronousBuffer.

That will take care of most of the porting work. The other thing to look for is UI functionality. If your driver has any UI, you won't be able to run it in the kernel. And most CE6 drivers will run in the kernel. Even if your driver will run in user mode, we recommend using the kernel UI handling to maximize portability between user and kernel mode. In CE6, drivers that require UI should break that UI functionality out into a companion user-mode DLL. Move all the resources, shell calls, etc. into the new DLL. Then use the new CeCallUserProc API to call into the user-mode helper.

BOOL CeCallUserProc( LPCWSTR pszDllName, LPCWSTR pszFuncName, LPVOID lpInBuffer, DWORD nInBufferSize, LPVOID lpOutBuffer, DWORD nOutBufferSize, LPDWORD lpBytesReturned);

This is something like a combination of LoadLibrary / GetProcAddress with an IOCTL call. When a kernel-mode driver calls this API, we'll load the DLL inside an instance of udevice.exe. When a user-mode driver calls this API, the DLL will load in-proc inside the same instance of udevice.exe that the user-mode driver is running in. So drivers that use this API can run in kernel or user mode without change.

The one big difference between CeCallUserProc and an IOCTL is that CeCallUserProc does NOT allow embedded pointers. All arguments must be stored inside the single "in" buffer passed to CeCallUserProc, and return data must be stored in the single "out" buffer. The problem is, if kernel code calls user code, user code cannot use CeOpenCallerBuffer or any other method to get the contents of kernel memory. We never allow user-mode code to access kernel-mode memory.

And, while you are modifying your drivers to use the new marshalling helpers and CeCallUserProc, you might as well check to see if it needs to do any secure-copy or exception handling it never did before -- as I outlined in the marshalling article. Remember, now that drivers run in the kernel, you must be more careful than ever to preserve the security and stability of the system.

User-Mode Drivers

As we've already mentioned, CE6 now supports running drivers inside a user-mode driver host, udevice.exe. User-mode drivers work pretty much the same as kernel-mode drivers: an application calls ActivateDevice(Ex) and DeactivateDevice on the driver. The device manager will check registry settings to see if the driver is supposed to be loaded in user mode. You can also use registry settings to specify an instance "ID" of udevice.exe to use, if you want multiple user-mode drivers to load into the same process.

For example, there is one user-mode driver group with ID 3. Multiple drivers load into this group. If you look inside the CE6 %_WINCEROOT%\public\common\oak\files\common.reg (an unprocessed version of what you get in your release directory), you'll see how this group is created and a few drivers that belong to it.

[HKEY_LOCAL_MACHINE\Drivers\ProcGroup_0003] "ProcName"="udevice.exe" "ProcVolPrefix"="$udevice" ; Flags==0x10 is DEVFLAGS_LOAD_AS_USERPROC [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Ethman] "Flags"=dword:12 "UserProcGroup"=dword:3 [HKEY_LOCAL_MACHINE\Drivers\Console] "Flags"=dword:10 "UserProcGroup"=dword:3 [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\SIP] "Flags"=dword:10 "UserProcGroup"=dword:3

If you don't specify a process group, your driver will be launched inside a unique instance of udevice.exe.

The device manager creates a reflector service object to help the user-mode driver do its job. The reflector service launches udevice.exe, mounts the specified volume and registers the file system volume APIs for communicating with the driver. Communication between applications and the user mode driver pass through the reflector, which helps with buffer marshalling. The reflector also assists the user-mode driver with operations that user-mode code is not normally allowed to make, like mapping physical memory; more on this later.

It is our goal that drivers should be as close to 100% portable between kernel and user mode as possible. However, kernel code will always be more privileged than user code will be. Taking advantage of the increased kernel capabilities will make your kernel-mode driver impossible to port to user mode.

What are some of the incompatibilities you need to know about?

As I explained in the marshalling article, user-mode drivers cannot write back pointer parameters asynchronously. I take it a step further and say that user-mode drivers cannot operate on caller memory asynchronously. That you're better off keeping such drivers in kernel mode for now, or restructuring their communication with the caller so that nothing is asynchronous.

Another detail you should know about is that user-mode drivers cannot receive embedded pointers from the kernel. This is exactly the same as saying that CeCallUserProc cannot support embedded pointers. If you're writing a driver that talks to kernel-mode drivers, and those kernel-mode drivers pass you embedded pointers, then your driver may have no choice but to run in kernel mode. If you can reorganize the communication between drivers, you may be able to "flatten" the structure so that, like CeCallUserProc, all the data is stored directly in the IN and OUT buffers instead of referenced via embedded pointers.

There are some APIs which used to require trust that now are (mostly) blocked against use in user mode. One notable example is VirtualCopy, and its wrapper function MmMapIoSpace. Most user-mode code cannot call VirtualCopy. User-mode drivers can, with a little help from the reflector. The reflector can call VirtualCopy on behalf of a user-mode driver, but it will not do so unless it knows the driver is allowed to use the addresses it's copying. Under each driver setup entry in the registry, there are IOBase and IOLen keys that we use to mark physical memory. When your driver calls VirtualCopy, the reflector will check these values to make sure your driver is allowed to access the physical address. For example, the serial driver might specify a physical address like this:

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial] "IoBase"=dword:02F8 "IoLen"=dword:8

If you have just one buffer to copy, use DWORD values. Use multi-strings to specify multiple base addresses and sizes.

[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\Serial] "IoBase"=multi_sz:"2f8","3f6" "IoLen"=multi_sz:"8","2"

Since only privileged applications can write to this part of the registry, the registry keys should protect against unprivileged code trying to gain access to these addresses.

Notable APIs that user-mode code cannot call:

• VM APIs: VirtualCopy[Ex], LockPages[Ex], CreateStaticMapping
  
• Interrupt APIs: InterruptInitialize, InterruptDone, LoadIntChainHandler
  
• You cannot install IISR directly, though you can install GIISR via the reflector. (GIISR exposes well known interfaces and the reflector can do the required checks on these calls.)
  
• OAL IOCTLs that are not explicitly permitted by the kernel

Call-backs from a user-mode driver to any process are also prohibited. The most important repercussion of this is, if you move a bus driver to user mode, you'd have to move the client drivers to user mode too. You can't have the client driver in the kernel since you cannot call back to the bus driver. You may want to put the bus driver and all of its client drivers in the same udevice.exe instance, so that the callbacks are all within a single process.

OEMs can choose to expose additional OAL IOCTLs and APIs to user mode by building a kernel-mode driver that provides these services -- by essentially writing their own version of a reflector. There is a kernel-mode driver, the oalioctl driver, that OEMs can extend to this end. Anyone who's not an OEM would have to write their own kernel-mode driver to do it. But be warned! Using oalioctl or writing new kernel-mode drivers to expose this functionality is essentially opening up a security gap that we (Microsoft) sought to close. Personally I advise against it.

Writing CE5 drivers to be compatible with CE6

I would like to mention that Steve Maillet, one of our eMVPs, had a good suggestion: you can set up abstractions which combine the CE5 and CE6 driver needs, so that all you have to do is reimplement the abstraction layer in order to port from CE5 to CE6. He even presented his abstraction layer at this year's MEDC (Mobile & Embedded DevCon, 2006). I don't know if he's interested in giving it out widely, but you could contact him at EmbeddedFusion, or steal his idea and implement your own layer.

Juggs Ravalia did a Channel 9 interview on the topic of drivers in CE6 -- if you don't like my explanation, maybe you'll like his better. He knows much more about our user mode driver framework than I do. Many thanks to Juggs for reviewing this article and my marshalling article.


Copyright (c) 2006 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published on the Windows CE Base Team Blog, here.

---

About the author: Sue Loh has been a developer on the Windows CE team for just over six years, spending the past couple of years working on system performance and tools for diagnosing performance problems, such as the kernel profiler and CeLog. She's also worked on the file system, registry and databases (CEDB), and from time to time has dabbled in parts of the kernel.

Understanding Windows CE 6.0's kernel mode
by Sue Loh
In Windows CE 5.0 and earlier, "kernel mode" is an access level attached to a thread. If a thread is "in kernel mode" it can access kernel address space. You could call SetKMode to put your thread into or out of kernel mode, whenever you wanted (it required trust, of course). Most system APIs were not implemented by the kernel (nk.exe), so calling an API didn抰 put your thread into kernel mode. Unless you called an API that was implemented by nk.exe, in which case your thread would temporarily enter kernel mode for the duration of the call.

In Windows CE 6.0 the implementation is actually the same, except that the SetKMode API is no longer supported. You can't put threads into or out of kernel mode at a time of your choice. However, most system APIs are implemented by modules that are now loaded into the kernel process, so calling an API usually puts your thread into kernel mode.

While the implementation is the same, the result is effectively different meanings. In CE 5.0, "kernel mode" was a property a thread could acquire or release on demand. In CE 6.0, the rule is fairly simple: your thread is in kernel mode while executing code inside the kernel process, and not in kernel mode when executing code inside a user process. We use the term loosely, like talking about "kernel mode drivers," "kernel mode code" and "kernel mode addresses." Whenever people use these phrases they're trying to talk about code and addresses that are only accessible to the kernel process, that are at addresses above 0x80000000. (Side note, you also have to be clear about whether you're talking about everything inside the kernel process vs. only the kernel module, kernel.dll.)

The one remaining gotcha in the CE 6.0 rule is callbacks. If a user application passes a function pointer to kernel mode code, and the kernel mode code calls the function pointer directly, then the thread is STILL in kernel mode (remember it is still a property of the thread, just not so obviously) while executing user mode code. And that is very bad for security. Because the user mode code could do anything; it could access kernel addresses or call kernel-only APIs.

If you write a driver that takes a function pointer from the caller and later calls it, make sure your driver only does so by using the new CEDDK function, CeDriverPerformCallback. That way your thread jumps back to the user process properly before calling the function, so that the function call can't do anything that the user process itself couldn't do already.

Or even better -- find a different way to implement what you're doing. Ask yourself this: if an attacker passed me an evil function pointer, could they get me to do something bad on their behalf? If you don't know the answer, don't take function pointers from your callers.

You might wonder about function pointers and memory marshalling. "Marshalling" only applies to passing data buffers between processes -- not to passing function pointers between processes. You can't "marshal" a function so that you can safely call it from kernel code. The CeDriverPerformCallback function is the only way to shed the privileges that a kernel mode driver has, for the duration of the call. I suppose you could consider that a form of "marshalling" but I don't.

Kernel mode vs. "most privileged processor mode"

Andrew Tuck, one of our support engineers, pointed out another detail that can lead to confusion. (Thanks, Andrew!) Often (at least in Windows environments, if not all OSes), the most privileged processor mode is referred to as "kernel mode." This usage of the term refers to when the CPU is operating with additional privileges, such as the ability to call special instructions that aren't normally legal. For example interrupt handling often happens in this CPU "kernel mode." This terminology is unrelated to the "kernel mode" concept I've been talking about in this article. When a Windows CE thread is in "kernel mode" it is not running in the most privileged processor mode. Only very restricted parts of the CE kernel and OAL run in that mode. The Windows CE "kernel mode" thread property controls whether the page tables for kernel address space are mapped, and some other things. (For example, in CE 5.0 it controlled whether the thread could make fast-path API calls, like I described in the API call post I wrote a while back.)


Copyright (c) 2006 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published on the Windows CE Base Team Blog, here.

---

About the author: Sue Loh has been a developer on the Windows CE team for just over six years, spending the past couple of years working on system performance and tools for diagnosing performance problems, such as the kernel profiler and CeLog. She's also worked on the file system, registry and databases (CEDB), and from time to time has dabbled in parts of the kernel.

Differences between Windows CE 5.0 and Windows CE 6.0

by K. Ashok Babu
Introduction

There have been lot of questions regarding differences between Windows CE 5.0 and Windows CE 6.0, and we thought it would be useful to Windows CE developers and OEMs (original equipment manufacturers) to know more about these changes. This article is the first in a series of articles on this subject.

The major changes in CE 6.0 are:

• Process address space is increased from 32MB to 1 GB.
  
• Number of processes has been increased to 32K from 32.
  
• User mode and kernel mode device drivers are possible.
  
• Device.exe, filesys.exe, GWES.exe has been moved to Kernel mode.
  
• SetKMode and set process permissions not possible.
  
• System call performance will improve.
  

Process address space

The existing implementation of CE 5.0 supports only 32 MB per process and is based on the Slot implementation. Every process apart from its native slot (Slot 2 ?33) used Slot 0 while running. For example, as mentioned in Figure 1, if filesys.exe running from Slot 2 has to run, then it has to run from Slot 0. So, if a.exe belonging to Slot 24 is running from Slot 0 apart from its native slot 24, all other processes also occupy the respective virtual address space. This actually leads to a waste in Virtual address space. A quick question would be, therefore, why was such an architecture arrived at when it was known that it is not scalable. The answer to this is beyond the scope of this article, and shall be discussed separately in future articles.


Figure 1
Windows CE 6.0 has moved toward more of a desktop OS format. Each process can now occupy up to 1 GB of address space, and the number of processes can be up to 32K. Microsoft confirms that it has tested up to 2600 processes running simultaneously. The process switching function is more like desktop like process switching; for example, every time a process switch happens, the entire TLB is flushed, data and instruction cache is invalidated, and fresh page tables are created (if the process is new). Compared to Windows CE 5.0, this should take more time to switch a process. Figure 2 illustrates the architecture in Windows CE 6.0.


Figure 2
You can see that Windows CE allows a user process to go up to 1 GB. The other 1 GB is allocated to DLLs, shared memory, and Kernel shared heap. The shared memory is for backward compatibility with CE 5.0 for sharing of files across processes. The DLLs, which were earlier restricted to 32MB of space (Slot 1), are now allowed to have 512MB of virtual address space starting from 0x40000000. An key aspect of this new architecture is that one process cannot view another process data directly, unlike in Windows CE 5.0. A process has to go through the kernel API to get data from other processes.

Device driver architecture changes

CE 6.0 implements both kernel mode device drivers and user mode device drivers. The use of kernel mode drivers provides enhanced security and robustness. OEMs can prevent drivers from gaining accesses to kernel resources by third party drivers, and hence can offer more security to his installation. OEMs can ship products with kernel mode drivers for all of the peripherals they supply, and for add on peripherals they can allow third parties to load kernel drivers only if they are signed by them, otherwise the drivers are restricted to run in user mode. However, user mode drivers are restricted to use Virtual Copy for only the memory space defined in the registry. In contrast, Windows CE 5.0 allowed user mode drivers to Virtual Copy any memory region other than the ones mentioned in the registry for them.

In CE 6.0, Filesys.exe, device.exe, and GWES.exe -- which were earlier part of user mode -- have been moved in to kernel mode. Calls to SetKMode and setting process permissions, so that other processes can be accessed, are not possible due to the reasons mentioned above. Consequently, drivers that use these calls have to be rewritten.

System call performance

In CE 5.0, system calls from a user application to a service process such as GWES.exe was tedious. A trap signals the event of the system call to the kernel. The kernel then switches the process to the service executable GWES.exe. Once GWES.exe returns, the kernel switches the process back to the user application. In CE 6.0, since GWES.exe is part of the kernel, there is no process switching and the user application goes to its application. This is very similar to what takes place in the desktop architecture. The flow chart shown in Figure 3 illustrates that.


Figure 3
Conclusion

With the release of CE 6.0, Microsoft has added lot more technologies, and has also renamed the OS from "Windows CE" to "Windows Embedded CE." Of significance, CE 6.0 boasts many security feature enhancements and performance improvements, such as moving filesys.exe, device.exe and GWES.exe into the kernel. OEMs have also gained an OAL update feature that will be provided by Microsoft from time to time, so that when there are bug fixes, they won't need rebuild the images and can just update the OAL on the fly. The next few articles in this series will explore new technologies in Windows CE 6.0 and also how to port a BSP from CE 5.0 to CE 6.0.

---

About the author: Ashok Babu is the Program Manager at e-con Systems in Chennai, India. His software specialities include developing Windows device drivers and designing Video codecs, and he also has hands-on experience in both Windows CE and Windows Mobile. He holds a Bachelor of Engineering, and his hobbies include music, soccer, and debugging. You can reach him by email, at "ashok at e-consystems dot com."

How Windows CE Bus Drivers Work

by David Liao

Abstract

A bus driver is designed for controlling and configuring a specific Bus. It also configures and controls hardware on the bus and loads and unloads hardware drivers called client drivers. It also carries out bus request from its client drivers. A bus driver has two basic functions from software perspective. One is serving its client driver. Another is configuring, loading, and controlling its client drivers. Microsoft provides a bus driver for most common buses, such as PCI, PCCARD, and the "Root" Bus.

What a Bus Driver does

A Bus Driver is responsible for Hardware Configuration, Hardware Power Control, Bus address translation, and loading and unloading upper-level client drivers.

Loading and Unloading upper-level client drivers

Most upper-level client drivers are loaded by a bus driver calling ActivateDevice(Ex). ActivateDevice(Ex) loads a client driver according to the contents of a registry entry that is passed in by the caller.

This means you need the registry in order to load the driver. A Bus driver has to either use an existing registry entry or create an instance registry entry according to a template.

For PNP drivers, the bus driver configures the hardware and sets up instance registry entries according to PNP information. Then, it loads a client driver by calling ActivateDevice(Ex) and specifying the new instance registry entries.

For non-PNP drivers and intermediate drivers, usually the registry is set up manually. It could be Microsoft, an OEM, or a third party who provides the bus driver. The bus driver normally still uses the registry to load those drivers.

A Bus driver can also be loaded by a "parent" bus driver, creating a "tree" of buses. The exception is the "Root" Bus Driver, or trunk of the tree. The Root Bus Driver is loaded by Device Manager using a registry path value found at a specific registry location:

[HKEY_LOCAL_MACHINE\Drivers]
"RootKey"="Drivers\BuiltIn"

The default value is set up by Microsoft. However, it can be changed by an OEM to allow the Root Bus Driver to enumerate drivers in some other registry path.

The above example indicates that the Root Bus driver is located at

[HKEY_LOCAL_MACHINE\Drivers\Builtin]

Device Manager loads the Root Bus Driver during initialization.

Important: Device Manager makes the Root Bus Driver run TWICE in a system with a two-phase boot.

In Boot Phase One, the Device Manager deletes the Drivers "Active" Key holding any stale driver instances (i.e. HKLM\drivers\Active), then loads the Root Bus Driver with the fixed Bus name "BuiltInPhase1". If this system has a two-phase boot, after the system "Phase 2" Event is signaled, the Device Manager loads the Root Bus Driver again. The second time the Device Manager uses a bus name found in the registry.

Is it possible that a driver can be loaded twice in two phase boot system? The answer is yes.

If a driver is included in HIVE registry and its entries do not include the DWORD "Flags" entry specifying DEVFLAGS_BOOTPHASE_1 (0x00001000), it will be loaded twice. It is important to take this into consideration when specifying the registry entries for a Bus Driver.

In theory, some Bus drivers should be loaded twice.

Bus Driver Access and the CEDDK Bus Functions

A client driver is capable of using its Bus Driver to:

• do bus address translation between a subordinate Bus and a Parent Bus
  
• do Device Power State changes
  
• access Configuration Data

There are many reasons to use a Bus Driver. One important reason is to make a Client Driver become bus-agnostic. This means a driver is capable of moving to user mode, or of working on different bus-architectures with the same binary. Some examples of bus-agnostic drivers are COM16550.dll and NE2000.dll. These can work as client drivers of the PCI Bus, Native Bus and PCMCIA bus with the same binary.

Bus Access Functions

In order to get access to its parent Bus Driver, a client driver has to call the CreateBusAccessHandle() function to get a bus driver access handle. This function is usually called by a client driver during its initialization (XXX_Init) because it requires that the client driver pass the "Active Registry Path" as an argument. CloseBusAccessHandle() is used for closing the access handle returned by calling CreateBusAccessHandle(). Usually the CloseBusAccessHandle() function is called before exiting XXX_Deinit. Please refer to MSDN online documentation for detailed information on these functions.

After a Bus Access Handle is created, a Client can use any function which uses this handle as an argument.

CEDDK Functions for Bus Driver operations are provided as wrappers -- they pack the corresponding function parameters and call the Bus Driver with an operation-specific IO Control Code (IOCTL). Microsoft strongly recommends that driver writers use the CEDDK functions instead of calling the Bus Driver directly with the IO Control Code. The parameters for the Bus IO Control Code may change from release to release, but the CEDDK functions (as formal APIs) signatures will not.

Listed below are the CEDDK functions and their corresponding IO Control Codes:

CreateBusAccessHandle	Creates an access handle for other CEDDK Bus functions. This results in the Parent bus?Open() entry being called.
CloseBusAccessHandle	Closes the handle which was created by using CreateBusAccessHandle(). This results in the Parent bus?Close() entry called.
SetDevicePowerState	IOCTL_BUS_SET_POWER_STATE
GetDevicePowerState	IOCTL_BUS_GET_POWER_STATE
TranslateBusAddr	IOCTL_BUS_TRANSLATE_BUS_ADDRESS
TranslateSystemAddr	IOCTL_BUS_TRANSLATE_SYSTEM_ADDRESS
SetDeviceConfigurationData	IOCTL_BUS_SET_CONFIGURE_DATA
GetDeviceConfigurationData	IOCTL_BUS_GET_CONFIGURE_DATA
GetChildDeviceRemoveState	IOCTL_BUS_IS_CHILD_REMOVED

SetDevicePowerState() and GetDevicePowerState() are used by a client driver to request that its parent Bus Driver put the client into a certain power state. Although some client drivers do the actual power state change by themselves, but it is the Bus driver's responsibility for putting its client drivers to their effective power states based upon the requests. Before a Bus Driver loads a client driver, it should put client driver's hardware into Power State D0. After the Bus driver unloads the client drivers, it should put the corresponding hardware into Power State D4.

TranslateBusAddr() and TranslateSystemAddr() are used to translate between physical CPU addresses and subordinate Bus addresses. To do so, TranslateBusAddr() should translate the target address from a Subordinate Bus to a Parent Bus. These calls should propagate up all the way to the Root Bus driver. Then Root Bus driver then calls the OAL function HalTranslateBusAddress() to acquire the final CPU-relative physical address. TranslateSystemAddr() works similarly, but in the other direction. The OAL uses HalTranslateSystemAddress() to translate from a CPU address to a Bus address. So, multi-layer bus address translation only can be resolved by TranslateBusAddr() and TranslateSystemAddr().

Before doing a virtual or static system memory mapping function for a driver, the BusTransBusAddrToVirtual() and BusTransBusAddrToStatic() functions use TranslateBusAddr() to translate a Bus address to a CPU(system) address.

IO Control Codes that are not supported by CEDDK

CEDDK provides the BusIoControl() and BusChildIoControl() functions to client drivers. Client drivers can use these two functions to issue a Bus IO Control call directly. The difference with these function is that BusChildIoControl() is used to issue an IO Control call related to client driver which is making the call.

The IOCTL_BUS_ACTIVATE_CHILD and IOCTL_BUS_DEACTIVATE_CHILD control codes are standard IO Control codes for which no wrapper function is implemented in the CEDDK. These IO Control codes can be called by any application if it opens a handle to the bus driver. The two Io Control Codes are used to activate or deactivate a client driver. Note: For legacy reasons not all client drivers can be deactivated.

How a driver's bus name is assigned

A Client Driver's bus name is assigned by its parent Bus Driver.

The Bus Name that Bus Driver assigns follows a simple four-part pattern:

busname _bus#_device#_function#

Usually, "busname" is assigned to a Bus Driver according to the value of its "BusName" registry entry under the Bus Driver device's registry key. This is value is pre-assigned either by Microsoft or by the OEM that is using the Bus Driver.

The "bus#", "device#" and "function#" are set to the "BusNumber", "DeviceNumber" and "FunctionNumber" registry entry values under the device key for the Client Driver. These registry value are created by the PnP Bus Driver. For non-PnP Bus drivers (for example, the Root Bus Driver), the "bus#" is assigned by the Bus Driver's device registry key. The "device#" and "function#" are then assigned automatically by the Bus driver.

Because the "busname" has to be unique in the system, an appropriate name must be chosen when the system has multiple bus drivers. The following is a list of well-known bus driver names:

1. Root Bus Driver: "BuiltIn"
   
2. PCI Bus Driver: "PCI"
   
3. PC Card Bus Driver: "PCCARD"

Power Manageable Drivers and Bus Drivers Power IO Control Codes

There are two different types of Power Manageable Drivers. The first type is a driver which is under the control of the system Power Manager (PM). The second type is a driver which manages its own power. Drivers which are under the control of the system Power Manager have to support the following IO Control Codes:

• IOCTL_POWER_CAPABILITIES -- The Power Manager uses this IO Control Code to query a driver's supported device power states. After a driver returns from this call with the Device Power States that it supports (D0->D4), and IOCTL_POWER_SET commands (see below) that specify a supported Device Power State should succeed. If the device does not accept the command to change power state, the PM will consider the refusal as a severe error.
  
  
• IOCTL_POWER_QUERY -- (Optional) This function simply returns a driver's current power state.
  
  
• IOCTL_POWER_SET -- The Power Manager uses this IO Control Code to change the driver's power state. Power Manager only specifies valid power states reported by a driver from IOCTL_POWER_CAPABILITIES.

Role the Bus Driver plays in Power Management of a Client Driver

As we described previously, the Client's Bus Driver is responsible for changing the hardware power state. Therefore, it would seem that the best solution would be for the Power Manager to call the Bus Driver directly to have it manage power. In fact, this does not happen. There are two reasons why not:

1. A Client Driver need to know the current power state in order to perform its function correctly. For example, the Client Driver has to make sure there is no ongoing processing on the hardware or a blocking future function request (if requests are queued) before calling the Bus Driver to turn off the hardware.
   
   
2. Driver before Windows CE 5.0 performed Power Control by itself. To make processing backwards compatible, the Power Manager needs to continue to call the Client Driver directly.

The Power Control commands from the System Power Manager are sent to the client driver. They are propagated to the client's Bus Driver via an Bus IO Control Code. The process is:

1. PM calls DeviceIoControl (IOCTL_POWER_SET) on the client Driver.
   
   
2. The Client Driver calls the SetDevicePowerState() CEDDK function which translates IOCTL_BUS_SET_POWER_STATE to the bus driver.
   
   
3. The Bus driver determines what to do base on the call from the client driver.

There can be confusion and fear resulting from the driver being simultaneously commanded by I/O functions (IoControl/Read/Write), and the Power Manager IO Control Code. When simultaneous requests happen, something must be done so that the Client driver still performs its functions correct.y. Use of a few CEDDK functions can help resolve the situation by following a general pattern:

Init()
{
hPwrHandle = DDKPwr_Initialize(__in PFN_SETPOWERLEVEL pSetPowerLevelFn,
__in DWORD dwContext,
__in BOOL fAbortOnPMRequests,
__in DWORD dwTimeout );
};

Deinit
{
DDKPwr_Deinitialize(hPwrHandle);
}

Function_Request()
{
       HANDLE hLevelHandle = DDKPwr_RequestLevel(hPwrHandle,
__in CEDEVICE_POWER_STATE dx );
       ?// Do some work.
       DDKPwr_ReleaseLevel(hPwrHandle, hLevelHandle);
}

PowerMgr_Request(Dx)
{       // From Power IO Control
DDKPwr_SetDeviceLevel(hPwrHandle ,Dx , __in PFN_SETPOWERLEVELCALLBACK pCallbackFn );
}

This pseudocode gives a general reference for how this is done. The released example for how to use the set of CEDDK function can be found public\common\oak\drivers\serial\serpddcm\cserpdd.cpp.

Bus Driver Library

Microsoft provides a Bus Driver Library to allow a user to write a Bus Driver. CEDDK functions pass Bus Io Control Codes to a Bus Driver. There are two different IO Control Codes. The first is targeted at the Bus Driver, the second is targeted at one client driver to control Configuration, Power State and Bus Address translation:

Class DefaultBusDriver {

Public:
      // Constructor
      // Client Driver Specific function.
      // Bus Driver Function.

Protected:
      // Container for all Folders of Child Client Driver.
      // Child Folder Class Manufacture. };

class DeviceFolder {

public:
      // Constructor
      // Device Power Function
      // Device Configuration Function
      // Device Bus Address Translation Function
      // Device Driver Load and Unload Function.
}; 

The DefaultBusDriver and DeviceFolder classes are abstract templates for implementation of a Bus Driver. A Bus Driver should inherit from these two basic classes and modify their virtual functions according to specific needs.

The Bus Library does not provide instantiable DefaultBusDriver and DeviceFolder classes. You must subclass these abstract bases and fill in implementation details. There are some default methods in the DefaultBusDriver implementation to manage a DeviceFolder-based class.

There are a few functions that the Bus Library provides:

DefaultBusDriver Class

• Forwards device-specific requests to a folder
  
• Manages DeviceFolder containers
  
• Performs Default Bus Translations for the IOCTL_BUS_TRANSLATE_SYSTEM_ADDRESS and IOCTL_BUS_TRANSLATE_BUS_ADDRESS IO Control Codes. It calls its parent bus driver to translate addresses or calls HalTranslateBusAddress or HalTranslateSystemAddress if it is a Root Bus Driver.
  
• Handles the basic IOCTL_BUS_IS_CHILD_REMOVED, IOCTL_BUS_NAME_PREFIX and other IO Control codes.
  
• Has a dummy function for PostInit(), which is called by IOCTL_BUS_POSTINIT

DeviceFolder

• Includes logic for creating a default bus name for use in driver loading and unloading.
  
• Perform Default Configuration Functions forwarded by the DefaultBusDriver class through IOCTL_BUS_GET_CONFIGURE_DATA and IOCTL_BUS_SET_CONFIGURE_DATA. It calls HalGetBusDataByOffset or HalSetBusDataByOffset when a request is from PCI Client Device Driver.
  
• Has a dummy function for SetPowerState which is called by the DefaultBusDriver through IOCTL_BUS_SET_POWER_STATE. The provided implementation of the PCI Bus Driver shows a good example of how to do SetPowerState for specific hardware.

PCI Bus Driver

The PCI Bus Driver is required to Configure the PCI Bus, Assign Resources, Search for Drivers according to a template, and set Instant Device Loading Registry keys. The details of this implementation are not described here, but the functions used to support Bus IoControl calls from external clients are detailed.

In order to support a Bus IO Control call from a Client Driver the PCI Bus Driver implements the following subclasses of the ones defined in the Bus Driver Library:

class PciDeviceFolder : public DeviceFolder{
    virtual BOOL PostInit() ;
...
};
class PciBusEnum : public  DefaultBusDriver {
...
};

These classes override their bases in the following ways:

• PciBusEnum -- Implements the PostInit() function to overwrite the dummy implementation in the parent class. This new implementation calls two sub functions:
  1. Calls AssignChildDriver() which creates one PciDeviceFolder for each Device Instance. This also inserts the folder into a Device Folder container.
     
  2. Calls ActivateAllChildDriver() which calls DeviceFolder::LoadDevice() to load each client driver in order.
  
  
• PciDeviceFolder -- Implements the SetPowerState() to overwrite the dummy implementation in the parent class. The new method implements its actions according to the PCI PM 1.1 specification.

Root Bus Driver

The default Root Bus Driver is called "BusEnum". This default only implements a simple BusEnum class which inherits its behavior from the DefaultBusDriver class in the Bus Driver library. It does not modify the default DeviceFolder implementation. Therefore, it does not support the SetPowerState() call to a device folder (default implementation is just a dummy).

class BusEnum : public  DefaultBusDriver {
virtual BOOL PostInit() ;
...
};

• BusEnum -- Implements the PostInit() function to overwrite the dummy implementation in the parent class. This new implementation calls two sub functions:
  • Calls AssignChildDriver() which creates one DeviceFolder for each Device Instance referenced by a sub registry key. It then inserts the folder into a Device Folder container.
    
  • Calls ActivateAllChildDriver() which calls DeviceFolder::LoadDevice() to load drivers in order.

For the Root Bus to support Power State Setting for Client Driver requests, the SetPowerState() Driver Folder function has to be implemented. The F-Sample (OMAP850) has an example of a platform-specific Root Bus Driver to show it how it can be done.


Copyright (c) 2007 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission. This article was originally published on the Windows CE Base Team Blog, here.

---

About the author: David Liao has been a software developer for over 20 years, and has worked for Microsoft for the past nine years. During his time at Microsoft, he has specialized in Windows CE device drivers, including the Mode Driver Framework, SD Bus driver re-design, USB 2.0 EHCI stack, PC Card stack, and Windows CE Bus Driver Architect, and BSPs (board support packages), including the design of USB Function Controller driver, USB OTG, PCI, and others. Prior to joining Microsoft, Liao worked for Xerox, Teklogix, and other companies as a DSP Software Developer.

转自：http://winceblog.blogspot.com/2007/01/flash.html

开发FLASH驱动除了要实现FMD_***的一系列函数之外,有几下几点需要格外注意:

1. FMD_GetInfo函数中需要正确地指明FLASH的类型,NOR或NAND,如果是NOR,则SECTOR SIZE只能是512.

pFlashInfo->dwNumBlocks 应设置成FLASH盘BLOCK的个数,

pFlashInfo->wDataBytesPerSector = 应该为PAGE的大小,

2.读写函数中需要访问的FlashInfo信息应该存放在FLASH的SPARE区,即数据区之外的地方,WINCE5.0系统中,有时上层不会将这些信息与真实的数据一起写入,而且有时候只会写这种数据. 但在某些系统或某些FLASH中不能将数据单独存入SPARE区,在这种情况下,可以将这些信息存放在一些专门的BLOCK中,或者不保存这些数据，在这种情况下，上层会不时地调用GetBlockStatus，别的似乎没有什么问题。

3.NAND的SPARE区一般用来保存ECC值，除此之外还会保存DISK INFO，而有些硬件会在写入数据时将数据区与SPARE区一起写入，所以得注意不要将原来SPARE区的数据覆盖掉。
DiskInfo中表示BLOCK是否已坏的那个成员,其值为-1时表示此BLOCK正常,其它值表示BLOCK已坏.

4.注意ECC只有在写入数据时才会产生(不论是由硬件还是软件生成),所以,刚把一个BLOCK擦除之后计算其ECC一定会有错,不应该在此时做ECC较验.

5.有一个问题，拷贝文件当FLASH快满时，驱动程序会死掉（Exception or dead lock like），不知还有谁遇到过？

转自：http://winceblog.blogspot.com/2007/02/wince.html

 

WINCE中标准的键盘驱动程序接口可以参考PS2键盘的驱动程序,但那个接口比较复杂,对于了解流接口的人来说,实现一个流接口的驱动程序应该是一个更好的选择.我们只需要实现一个流接口驱动程序,发生中断以后读到键盘的扫描码，将其用MapVirtualKey转化成虚键，再调用keybd_event函数将些虚键发送出去即可。只是我们需要注意记录CTRL,ALT等特殊键的状态。
注意：
1，某些键的扫描码有两个值，以0XE0或0XE1开始，注意正确处理。
2，一个PS2键盘不需要初始化就可以工作，但我们可以发送RESET命令再读其返回值来判断键盘是否已经连接。
3，必须加上kbdmous.dll，这个模块，我们的键盘驱动才能正常工作，通常只需要加上NOP Keyboard/Mouse English,再加上相应的注册表设置就行。
4,系统中只能有一个标准接口的键盘驱动，即kbdmouse.dll,所以如果我们有更多的键盘硬件需要驱动，就需要把其它的做成流接口的，最多将一个写成标准的键盘驱动，当然也可以把所有的都写成流接口驱动，再加上NOP Keyboard/Mouse English。

转自：http://winceblog.blogspot.com/2007/02/blog-post.html

串口驱动程序的样例在public\common\oak\drivers\serial下,其中COM_MDD2是MDD部分, SERCARD是PC卡MODEM设备的驱动.ISR16550是16550的ISR代码.SERPDDCM,是PDD的公用部分,OO16550是16550的PDD,一般我们可以以这个代码为基础根据需要开发我们自己的代码.可以参考OO16550中的代码,实现其中各个函数即可.

串口在硬件上很简单,只有九根线, 但其驱动程序却极其复杂.幸好WINCE提供了MDD,封装了与硬件无关的部分代码,而且从CE5.0开始又新加了SERPDDCM,提供了PDD的公用代码,将PDD又封装了一层.如此一来就极大的减少了我们开发的代码量.只需要参照OO16550的代码即可.需要注意的问题如下:

1. 驱动代码量不大,但是要想让它工作稳定还需要花费不少力气.CETK的Serial Communication Test 是一个不错的测试工具,一般只要能通过它的测试说明驱动已经可以比较稳定的工作了.
2. 一般的UART硬件会有寄存器来判断是否有新数据收到,所以我们在收到数据时用它判断是否还有数据,直到将其读完,但发送时可能无法知道发送FIFO中还可以存放几个字节.这时,我们可以做如下判断:如果发送FIFO已经为空,就可以写入整个FIFO大的字节.如果FIFO没空但到达了触发发送中断的界限，则可以写入FIFO大小减去中断临界值个字节。否则就一个字节也不能写入。16550的代码最小要写入1个字节，这种做法会有问题。在9600等比较低的速率时，如果没有达到中断临界值而我们去写入一个字节,可能会将FIFO中最上面的一个值覆盖掉。
3. 不能让发送或接收占用太多的时间。如果我们一直等着将更多的值读出或写入，如果发送与接收同时发生时就会产生问题。
4. 一个很简单的道理：如果高速率时正常而低速率有问题，就是对于某种硬件状态处理的太快，反之就是太慢。
5. MDD的发送线程在发送完所有数据以后还会调用一次PDD的发送函数来发送0个字节，从而让PDD将中断关掉。而如果最后一次写的数据太少，比发送中断临界值小就不会产生中断。这时可以让PDD的发送函数在发送一个太小的数据时触发PDD IST呈一次。
6. 做CETK测试时，需要一个信号线接全的NULL MODEM线。
7. 自认为比较重要的几个函数:

<!--[if !supportLists]-->1) <!--[endif]-->InitXmit与InitRecieve用来初始化发送器与接收器,它们在端口被打开,关闭和RESET时被调用。当输入参数为TRUE时启动硬件，输入参数为FALSE时关闭硬件。

<!--[if !supportLists]-->2) <!--[endif]-->CancelXmit与CancelRecieve，这两个函数在应用程序调用PurgeCom时被调用。只需要清除FIFO即可，不能将硬件停用。

<!--[if !supportLists]-->3) <!--[endif]-->其它比较重要的函数就是发送与接收的函数，与传输的稳定性有直接关系。

<!--[if !supportLists]-->4) <!--[endif]-->别的就是设置各种参数的函数，包括像停止位，奇偶效验位等，比较简单。

8．有一点需要注意：硬件对寄存器的读写顺序也许有要求，必须注意。比如，如果硬件已经启动之后就不能更改波特率，我们在改波特率时就要先将硬件停用，修改波特率之后再启用。

9.电源管理. 我们可以在调用InitRecieve及InitXmit函数中分别启动或停止接收及发送模块。如果发送和接收都已经禁用，就可以将整个UART硬件停用，用以节电。

10．注意InitXmit函数中，在停用发送模块时，需要等到所有数据都发送出去以后再停用发送模块。否则在低速率时驱动程序刚将数据写入FIFO，COM_Write函数返回，上层即关掉串口句柄，引起发送模块被停用，FIFO中没有发送出去的数据就再也无法发送出去。我在38400及以下的波特率上都测到过这个现象。

11．CETK。因为CETK需要两个WINCE设备，它们需要一根交叉线来连接，注意检查交叉线的连法：2与3互连，这样就能通过数据传输相关的测试。7与8互连，硬件流控就没有问题。其它的几个与MODEM信号相关的引线也要正确连接。

 

硬件中断线总是有限的，我们可能需要在已有的系统上做一些扩展，比如将串口扩展成好几个，有些硬件本身就设计成多个设备共享一条中断线，比如我的系统中两个串口就共享同一个CPU中断，任何一个串口发生中断以后都会触发CPU的同一条中断线，需要判断别的寄存器来确定是哪个串口发生了什么中断。

转自：http://winceblog.blogspot.com/2007/03/winceusbfn.html

USBFN，即USB客户端驱动，用来将一个WINCE设备模拟成一定的USB设备，让主机端（如PC）访问。目前WINCE提供的USB客户端有存储设备，串口设备，及RNDIS网络接口设备。

存储设备用来将WINCE设备上的存储空间，例如FLASH，当作一块存储介质给主机访问，即将WINCE设备模拟成一个U盘。

串口设备将设备与主机的USB连线模拟成串口，WINCE和主机端都认为它们之前连接上了一根串口线，它们之间可以做串口通信，典型的应用是用来实现WINCE与PC机的同步连接。

RNDIS设备使两端认为它们之间建立了网络连接，通过注册表设置可以让主机通过WINCE设备上网或者使WINCE设备通过主机上网。

WINCE已经提供了以上三种设备的驱动程序，在同一时刻只能使用一个设备。而我们需要做的只是提供USBFN总线控制器的驱动程序。USBFN系统各个模块的关系如下：

USBFN总路线控制器作为一个总线驱动程序，被设备管理器加载，根据注册表设置加载相应的客户驱动程序，即存储设备，串口设备或者RNDIS设备。客户驱动程序即启动USBFN，引发主机配置设备，配置完成以后即可开始工作。

而USBFN总路线控制器驱动的MDD部分WINCE本身已经提供，PDD只需初始化硬件设备，提供传输即可。MDD在初始化时调用UfnPdd_Init函数得到PDD层的函数表，之后会根据需要调用各个函数。PDD还需要提供IST，用以处理各个中断。需要注意的是USBFN有一个与其它设备不同之处，它的注册表需要这样一个设置：

"BusIoctl"=dword:2a0048，用以让系统加载完设备之后调用值为0x2a0048的IOCTL代码去完成初始化，其定义为IOCTL_BUS_POSTINIT。

 

使用DMA的好处就是它不需要CPU的干预而直接服务外设，这样CPU就可以去处理别的事务，从而提高系统的效率，对于慢速设备，如UART，其作用只是降低CPU的使用率，但对于高速设备，如硬盘，它不只是降低CPU的使用率，而且能大大提高硬件设备的吞吐量。因为对于这种设备，CPU直接供应数据的速度太低。

转自：http://winceblog.blogspot.com/2006/11/arm.html

平时大家接触最多的可能是X86平台，在这种系统上写程序几乎不需要考虑太多问题，但ARM上就不一样了，最常见也最容易被忽略的问题可能就是字节的对齐，即使像我这样有六七年程序开发经验的才手也时常难于提防，最近就有一个BUG，花了一天时间最终发现是对齐引发的，在此与大家分享，但愿大家能够注意到。

　　我在EBOOT中读取存在HARD　DISK上的nk.bin文件，从而从HARD　DISK上LOAD　WINCE系统，在这个过程中总是有check sum错误，但从ethernet下载时不会有错，所以问题应该还是在我加的这部分代码上，而且同样的代码在PC上能正常运行。经过检查代码的逻辑关系是正确的。接着我在出错时将那些数据全部用调试信息打出来，发现从文件开始算起第4096个字节被丢掉了，而其它的字节都是对的。初步判断是对齐引发的问题，所以去查每一个BUFFER，最终发现是在读取硬盘数据时BUFFERR并没有按双字节对齐，而硬盘以16BIT读取数据，而引发了错误。

实际上，这类问题在ARM系统上很常见，让人防不胜防，以下是我的一些例子。

1，解析数据流时应该时刻注意。如果需要把一个数据流（BUFFER）转化成结构进行取值，就应该把这个结构定义为按字节存取.考虑如下结构：

struct a{

char a;
short b;
long c;
};
如果某个数据流中包含这样的结构，而且我们要直接将数据流的指针转化成该结构的指针，然后直接取结构成员的值，我们就应该将这个结构定义成按字节访问，即将其夹在语句
#pragma pack(push,1)
...

#pragma pack(pop)
之中。如果我们不这样做，编译器会将成员b的地址对齐到short指针的地址，即在a之后加上一个char即8位的成员，将C对齐到LONG，即在B之后再加一个char成员。如此一来，成员B和成员C就得不到正确的值了。

如果我们定义一个普通的结构用来存放一些数据，则不用定义成按字节存取，编译器会加上一些占位成员，但并不会影响程序的运行。从这个意义上讲，在ARM中，将结构成员定义成CHAR和SHORT来节约内存是没有意义的。

一个典型的例子就文件系统的驱动程序，文件是以一些已经定义好的结构存放在存储介质上的，它们被读取到一个BUFFER中，而具体取某个文件、目录结构时，我们会将地址转化成结构而读取其中的值。


2，访问外设时。
例如，磁盘驱动通常以16BIT的方式存取数据，即每次存取两个字节，这样就要求传给它的BUFFER是双字节对齐的，驱动程序应该至上层传来的指针做出正确的处理以保证数据的正确性。


3.有时，我们没有将数据流指针转化为结构指针取值，但如果我们读取的是双字节或者是四字节的数据，同样需要注意对齐的问题，例如，如果从一个BUFFER的偏移10处读取一个四字节值，则实际得到的值是偏移8处的
地址上的DWORD值。

转自：http://winceblog.blogspot.com/2006/12/hive-registry.html

转自：http://winceblog.blogspot.com/2007/01/pqoalpqoal-bsp.html

节选1：
逃避风险就等于举旗投降。在过去，如果恰好遇到一个看来全无风险的项目，你也许会把它看作一次愉快的享受，或许还会感谢你的幸运星给了你这样一个轻松的项目。我们也曾有过这样的反应——多么愚蠢的反应。没有真正意义上的风险，项目注定是失败的：全无风险的同时，它们也几乎全无收益，所以这类项目至今仍然没有付诸实施。给自己节省一点时间和精力，去做那些真正有价值的事情吧。

——摘自第1章
节选2：

在克里福德之前，曾有这样一种观点：信念永远不能被放在伦理的灯下接受拷问；只要你愿意，你可以相信任何事。你甚至可以相信绝无可能的事，就像《爱丽丝漫游镜中世界》(Through the Looking Glass)里的白皇后那样。当爱丽丝认为“人不能相信不可能的事”时，这位皇后答道：

“我猜你只是缺乏练习……像你这么大的时候，我每天都会用半小时去相信不可能的事。啊，有时我甚至可以在早餐前相信六件不可能的事。”

不过，对于软件项目管理者来说，“在早餐前相信六件不可能的事”似乎并不是一种难以企及的能力——我们总在相信着各种各样不可能的事，例如在极短的时间里、以极低的预算和极高的效率完成项目。

在做这件事时，我们与那位对自己的船充满信心的船主并无太大区别。无疑，作为软件项目的管理者，你肯定曾经做过这样的事。这也许是因为旁人的怂恿，例如你的老板会请求你在圣诞节前完成一个项目，却只给你三个人。当然，你会表示怀疑：这点时间够用吗？

“那就是我选你来管理这个项目的原因。”老板信赖地对你说。

事情就这么定下来了：你接受这份工作，接受挑战，也准备接受荣誉……但你首先必须相信这个日程安排，那就是你要付出的代价。终于，你艰难地说：“我能行。”然后开始不断地巩固自己的信念。当然能行，不就是圣诞节吗？为什么不行？别的项目用的时间还要少呢，不是吗？没多久，你就已经充满信心了。也许时间会证明你的信心毫无根据，但至少现在，你非常肯定：你能够按时完成任务。

这时，你应该回想一下威廉·金顿·克里福德的质询。没错，那是你相信的，但你是否有权相信它？凭面前的证据，你是否有权相信那个日程安排？

只相信你有权相信的事，这就是风险管理。说到底，风险管理的核心就是克里福德的“信仰的伦理学”——尽管不确定性的存在使情况愈加复杂，但风险管理要求每个信念必须接受伦理的拷问。它将去除你工作（例如软件项目）中曾经充斥着的自欺欺人。除了“在早餐前相信六件不可能的事”之外，你还可以有另一种选择，一种更为明智的选择。