Handle Tables: Windows CE 5.0 vs. Windows Embedded CE 6.0
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/28/2008
In previous versions of Windows Embedded CE, a handle to an event, a thread, a process, a mutex, and so on, could be passed to a different process and be usable by that process. If two handles were opened to the same object, the handle value, which is the 32-bit identifier that an application holds onto, was the same for both handles. There was one global list of handles that was shared by all processes. For information about creating a registering a handle-based API set, see Creating, Registering, and Using a Handle-based API Set.
Benefits of the Handle Tables
In Windows Embedded CE 6.0, each process has its own individual handle table. If two handles to the same object are opened, they have different values, even within the same process. A handle value in one process cannot be used to access that object in another process. This includes the kernel.
The kernel process, including the kernel-mode servers running under it, has its own handle table, and cannot use a handle that was opened by a different process. If you try to pass a handle from one process to another, that handle value may already be used by the other process to refer to a different object. If that other process tried to use the handle value, it would access a different object. This improves security because handle guessing is eliminated.
Handles are looked up in the handle table, which the user cannot access. This prevents users from generating handle values. In Windows CE 5.0, generated handle values could elevate user privileges.
Handle objects are locked before they are used, and unlocked after they are used. The locking mechanism is a reference counter, which is incremented before the handle is used and decremented after the handle is used. Handle objects are destroyed only when their reference counter equals zero, so handle objects in use are never destroyed. In Windows CE 5.0, a handle object could be destroyed while it was still in use, for example, in the middle of a call to an API.
Handles cannot easily be reused because there is a 16-bit reuse count. Therefore, about 64,000 operations to create and close handles would be required to exhaust the reuse count. In Windows CE 5.0, the reuse count was only 3 bits, so a handle could easily be reused. Therefore, stale handles could be a problem.
Similar to Windows desktop-based operating systems, every newly created handle, including newly duplicated handles, has a unique value. Previous versions of Windows Embedded CE returned the same handle value for duplicated handles, or a named handle of the same name.
Tradeoffs of the Handle Tables
Handles are only valid within the process that created them. Handles cannot be passed between processes. Existing code that passes handles from process to process must be changed to use DuplicateHandle to create a new handle that the other process can use. If necessary, use OpenProcess to access the other process.
See Also
Other Resources
Kernel Functionality Modifications: Windows CE 5.0 vs. Windows Embedded CE 6.0
Kernel API Modifications: Windows CE 5.0 vs. Windows Embedded CE 6.0