Thin Client Software Requirements (Windows Embedded CE 6.0)

Article
01/05/2012

1/5/2010

After you create the Windows Embedded CE powered thin client operating system (OS) design by using either the Windows Thin Client design template or the Enterprise Terminal design template, you can configure the modules and components in the OS design by using Platform Builder. However, several software components must always be present in a thin client OS design and are therefore considered requirements. These requirements are covered in this topic.

System Software Requirements

A Windows Embedded CE powered thin client requires that the Remote Desktop Protocol (RDP) Client is included in the thin client run-time image.

In the OS, the Windows Embedded CE RAM-based file system must be reset every time that the thin client starts. This makes sure that the thin client starts in a known state, after the device starts, or after the device is reset.

A thin client uses a RAM-based registry, and must therefore restore the registry when the thin client is turned off or reset. If you implement the required functionality in the OEM Adaptation Layer (OAL), the registry can be saved to persistent storage specified by an OEM. To do this, you must call RegFlushKey and WriteRegistryToOEM. If WriteRegistryToOEM succeeds, RegFlushKey will succeed. If WriteRegistryToOEM fails, RegFlushKey will fail.

Note

When you call RegFlushKey in Windows Embedded CE, the hKey parameter is ignored, and the whole registry is flushed. Do not call RegFlushKey more frequently than necessary. For example, writing to flash can be time-consuming, depending on the implementation of the OEM, and the size of the registry.

You must also implement ReadRegistryFromOEM. The OS calls this function during initialization, while the Filesys.exe file initializes. After Filesys.exe is loaded, the registry is updated by calling this function.

Client Software Requirements

The following table lists the requirements for software that is developed for a Windows Embedded CE powered thin client.

Requirement	Description
Client software must run in full-screen mode	Because the shell design is for use with applications that run in full-screen mode, the client window must occupy the full screen, must have no border, and must be immovable.
Client software must run single-instance	Because the thin client shell keeps track of connections based on the process identifier, each instance must run in its own connection, or process space. If multiple connections run in the same process space, the user cannot switch between sessions.
Client software must not create top-level windows	When the user brings the shell interface forward by pressing the CTRL+ALT+END keyboard shortcut, a client-created top-level window must not obstruct the shell interface.
Dialog boxes and message boxes must be child windows	If the client posts a message box or a dialog box that has the parent set to NULL, to the child window cannot gain access to the user interface (UI) if a user brings the shell forward in the z-order and then switches back to the connection.
The client software must respond to WM_CLOSE	The End button on the shell UI will post a WM_CLOSE message to the client. The client software must respond to this message by exiting or by prompting the user for confirmation. The shell does not prompt for confirmation because the client will prompt for confirmation.
The client software must not register keyboard shortcuts	The client software must not call the RegisterHotKey function.
The client software must synchronize the key state	Generally, this requirement applies to presentation protocols in which the client sends keyboard events to the host. The Windows Thin Client Shell uses the RegisterTaskBar and RegisterHotKey functions to trap specific keyboard events. For example, if the user presses the CTRL+ALT+END keyboard shortcut, the thin client shell UI comes forward. The client recognizes a WM_KEYDOWN event for the VK_CONTROL and VK_MENU keys, but does not recognize the corresponding WM_KEYUP message. Clients must be able to deal with this kind of keyboard synchronization issue.
Licensing agreements must be handled by the Add helper application.	If the user must agree to legal restrictions before a thin client is used, the Add helper application must handle the licensing agreement process.

Warning

We recommend that you provide a software-controlled power button that enables a registry flush operation before loss of power. This prevents any loss of persistent settings for the thin client device.

User Interface Requirements

The thin client UI consists of a thin client shell, the client software helper applications, and the Setup wizard and properties sheets. The following describes each of these UI component requirements.

Shell Requirements

The thin client shell can be either the Windows Thin Client Shell or the Standard Shell. The Windows Thin Client Shell is a shell designed specifically for the Windows Embedded CE powered thin client that includes the Setup wizard, the Remote Desktop Connection client, and the thin client property sheets. It does not expose an interface for starting client applications. The Standard Shell is a shell for Windows Embedded CE powered devices that includes a desktop with program icons, a start menu, a taskbar, and a system notification area.

The Windows Thin Client Shell keeps track of connections by using process identifiers. When a connection is started, the shell changes the status of the connection from inactive to active. The shell then starts the connection by calling CreateProcess on the application that is associated with the StartExe entry of the connection. The shell passes StartCmdLineArgs as the command-line arguments. When the connection starts, the client software comes to the foreground.

The user can switch to the shell by pressing the CTRL+ALT+END keyboard shortcut. Then, the user can start other connections or switch to an active session. If the user chooses to switch to an active session, the shell calls SetForegroundWindow on the top-level window that is associated with the process identifier of the connection. If multiple top-level windows are associated with the connection, the shell calls SetForegroundWindow on the first valid window that enumerates upon calling EnumerateWindows.

Support for keyboard shortcuts must be enabled, and the Windows Thin Client Shell must follow keyboard shortcut guidelines. For more information about keyboard shortcut guidelines, see Thin Client Registry Settings.

For overview information about the two shell options, see Windows Thin Client Shell Overview and Standard Shell Overview.

Helper Application Requirements

The following table lists the requirements for helper applications that are designed for Windows Embedded CE powered thin clients.

Requirement	Description
Helper applications must run and exit	When the shell calls the helper application of a client, it waits for the helper application to exit before it lets a user to use the shell. If a helper application runs and does not exit, a user cannot use the shell.
Helper applications must call RegFlushKey	Windows CE 3.0 supports saving the registry to a persistent data store by calling RegFlushKey. The Windows Embedded CE registry is maintained in RAM, and the default registry that is provided by the OEM is restored every time that the thin client is reset. When the system is reset, any change that is made to the registry is lost unless an event makes sure that the registry change is not lost. To make sure that registry changes are not lost, helper applications must call RegFlushKey to save the registry. Windows Embedded CE ignores the key value when it calls RegFlushKey, and saves the whole registry. Saving the registry is a time-consuming process, depending on the OEM implementation. Therefore, the helper application should reduce the number of times that it calls RegFlushKey.
Delete helper application must run silently	The Delete helper application must run without a UI. The delete connection UI is provided by the shell and includes confirmation and error messaging.
Delete helper application must return 0 if it is successful, and nonzero if an error occurs	The shell will call the exit code of the Delete helper application to determine the success of the delete operation. If the Delete helper application sets its exit code to 0, the delete operation was successful, and the shell will delete the connection entry from its list. If a nonzero value is returned, the shell will post an error message for the user stating that the connection could not be deleted.
Delete helper application must delete the registry key completely for the connection that is being deleted.	For a delete operation to be successful, the Delete helper application must completely delete the registry key of the connection.

For more information about how to configure client information, see Configuring Client Information and Connections on a Thin Client.

Setup Wizard and Property Sheet Requirements

When the Windows Thin Client Shell is included in a run-time image, you must include a Setup wizard that runs the first time that a user turns on a thin client.

You must also include the property sheets so that a user can change terminal settings after the Setup wizard has first configured the thin client. For information about how to customize the Setup wizard and property sheets, see Customizing the Setup Wizard and Property Sheets for a Thin Client.

Share via