Thin Client Software Requirements (Windows CE 5.0)
The Windows Thin Client requires that the RDP Client is included in the Thin Client image.
The Windows CE RAM-based file system must be reset each time that the Windows Thin Client starts up. This ensures that the Windows Thin Client starts in a well-known state, following startup or reset.
Windows Thin Client uses a RAM-based registry, and must therefore restore the registry when the device is turned off or reset. If you implement the required functionality in the OAL, then the registry can be saved to an OEM-specified persistent storage. To do this, you must call RegFlushKey and WriteRegistryToOEM. If WriteRegistryToOEM succeeds, then RegFlushKey will succeed. If WriteRegistryToOEM fails, then RegFlushKey will fail.
**Note **When you call RegFlushKey in Windows CE, the hKey parameter is ignored, and the entire registry is flushed. Do not call RegFlushKey more than necessary, because this can be time-consuming, depending on the implementation of the OEM — for example, writing to flash — and the size of the registry.
You also must implement ReadRegistryFromOEM. The OS calls this function during initialization while the Filesys.exe file is being initialized. Therefore, after Filesys.exe loads, the OS updates the registry by calling this function.
Client Software Requirements
The following table shows the requirements of software that is developed for the Windows Thin Client.
| Requirement | Description |
|---|---|
| Client software must run full-screen. | Because the shell is designed for use with applications that run full-screen, the client window must occupy the full screen, have no border, and be immovable. |
| Client software must run single-instance. | Because the Windows Thin Client Shell keeps track of connections that are based on the process identifier, each instance must run in its own connection, or process space. If multiple connections are run from within the same process space, then it is not possible for the user to 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 key combination, the interface must not be obstructed by a top-level window that was created by a client. |
| Dialog boxes and message boxes must be child windows. | If the client posts a message box or a dialog box with the parent set to NULL, then there is no way to gain access to the user interface (UI) if a user brings the shell forward 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, if appropriate, by prompting the user for confirmation. The shell does not prompt for confirmation, because the client will prompt for confirmation, if appropriate. |
| The client software must not register hot keys. | The client software must not call the RegisterHotKey application programming interface (API). |
| The clients must synchronize the key state. | Generally, this requirement applies to presentation protocols in which the client is sending keyboard events to the host. The Windows Thin Client Shell uses the RegisterTaskBar and RegisterHotKey APIs to trap certain keyboard events. For example, if the user presses the CTRL+ALT+END key combination, then the Windows 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 type of keyboard synchronization issue. |
| Licensing agreements must be handled by the Add helper application. | If the user must agree to legal restrictions before using a client, then the Add helper application must handle the licensing agreement process. |
Additionally, Microsoft recommends that you provide a software-controlled power button that allows a registry flush operation prior to loss of power. This prevents any loss of persistent settings for the Windows Thin Client device.
User Interface Requirements
The Windows Thin Client UI consists of the Windows Thin Client Shell, client software helper applications, and the Windows Thin Client Setup Wizard and Properties Sheets.
Shell
Include the Microsoft Windows Thin Client Shell rather than the Windows CE shell. The Windows Thin Client Shell is designed specifically for Windows Thin Client, and does not expose an interface for starting arbitrary applications.
The Windows Thin Client Shell keeps track of connections by process identifier. 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 key combination. 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 is enumerated upon calling EnumerateWindows.
Hot-key support must be enabled, and the Windows Thin Client Shell must follows hot-key guidelines. For more information about hot key guidelines, see Thin Client Registry Settings.
Helper Application Requirements
The following table shows the requirements for Helper applications for Windows Thin Client 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 allowing a user to use the shell. If a helper application runs and does not exit, then a user cannot use the shell. |
| Helper applications must call RegFlushKey. | Microsoft Windows CE 3.0 supports saving the registry to a persistent data store by calling RegFlushKey. The Windows CE registry is maintained in RAM, and the default registry that is provided by the original equipment manufacturer (OEM) is restored each time that the device is reset. Any change that is made to the registry is lost upon reset unless steps are taken to ensure that it is not lost. To ensure that changes are not lost, helper applications must call RegFlushKey to save the registry. Windows CE ignores the key value when calling RegFlushKey, and saves the entire registry. This can take some time, depending on the OEM implementation. The helper application must minimize the number of times that RegFlushKey is called. |
| Delete helper application must run silently. | The Delete helper must run without UI. The delete connection UI is provided by the shell, and includes confirmation and error messaging. |
| Delete helper application must return 0, if successful, and nonzero, if an error occurred. | The shell will call the exit code of the Delete helper application to determine the success of the deletion. If Delete helper application sets its exit code to 0, then the delete operation was successful and the shell will delete the connection entry from its list. If nonzero is returned, then the shell will post an error to 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 delete the registry key of the connection completely. |
For information about configuring client information, see the "Connections" section in Configuring Client Information in Thin Client.
Setup Wizard and Properties Sheets Requirements
You must include a Setup wizard that runs the first time that a Windows Thin Client is turned on.
You must also include the Properties Sheets to change terminal settings after the Setup wizard has initially configured the target device. For information about customizing the Setup Wizard and Property Sheet, see Customizing the Setup Wizard and Property Sheets for a Thin Client.
See Also
Send Feedback on this topic to the authors