Navigation
Virtualization Solutions ... Articles and Whitepapers ... Downloads ... Internet Resources Books ... Windows Server 2008 Terminal Services ... Windows Server 2003 Terminal Services My Profile ... About this Web Site ... Benny's Biography ... Presentations 2008, 2007, 2006, 2005, 2004 and earlier

	Awards

Finding out about Ericom's Seamless Windows Engine

Posted by Benny Tritsch on May 6, 2005

Introduction

During the preparation of my session on seamless windows technologies at BriForum 2005, I asked some software manufacturers competing with Citrix about their seamless windows implementation details. I did not expect that anyone would answer all my questions. But I did not expect that none of them – except Ericom – was willing to answer any of my questions.

But anyway, I did my session at BriForum and now I want to share with you what Ericom answered.

IMPORTANT: In this document, I forward information as I received it from Ericom. I was not able to review the latest Ericom product in a way that I can make sure that all technical facts mentioned below are described in an accurate manner.

I MAKE NO WARRANTIES, EXPRESS OR IMPLIED, WITH RESPECT TO THE COMPANY DESCRIPTIONS, AND/OR PRODUCTS, SERVICES, OR CONTENT STATED IN THIS DOCUMENT. Product and company names mentioned herein may be the trademarks of their respective owners.

The Questions

Things I wanted to know about the implementation of the seamless engine.

Terminal Server Enhancements

• Give a brief description of the enhanced user shell features (= server-side seamless engine)
• Provide the file names including all components of the enhanced user shell
• Briefly describe the hooking mechanism used for tracking the creation, modification, hiding, disabling and destruction of application windows
• What mechanisms are used to extract application resources like icons, menu items and bitmaps from the application running on the server?
• How is this implemented? Managed code or unmanaged code?

RDP Client Enhancements

•  Provide the file names including all components which extend the functionalities of the standard RDP client (or did you implement the client from scratch?)
• How is the client extension implemented? Control, component or Windows application (WinForm)?
• Are all window frames, window captions, menu bars and tool bars of the remote applications created by the local window manager after receiving the appropriate data from the enhanced user shell? Is there support for all window properties?
• Are all standard dialog boxes initiated by remote applications (like Message Boxes) created and handled by the local window manager? Is the proper handling of modality (app modal or system modal) and focus guaranteed?
• How can you control the task bar and the tray icons of the local window manager? Is there a system tray service which allows the usage of the Shell_NotifyIcon API from a remote application? What about the FlashWindow API for notification messages?

Virtual Channels

• How many Virtual Channels are used for the communication between the enhanced user shell and the extended RDP client?
• Which functionalities are related to the individual Virtual Channels?
• Is there any option to change the data transmission priority of individual Virtual Channels?

Handling of Known Challenges

• How can you handle orphaned main windows, this means windows with no owner window or with no valid parent (like Dephi applications)?
• Can you control windows Z orders, windows positions and windows sizes?
• Is session sharing guaranteed when multiple seamless application are launched by the same user?
• How do you handle invisible or hidden windows (created by IE, VB, Delphi, Office XP or others)?
• What happens to windows with 0 window size or coordinates completely outside the client area?
• Can the seamless server session inherit the client system color setting?
• Is it possible to control the refresh rate of the mouse events?
• Can full window drag be enabled and disabled?

Answers from Ericom

I received valuable feedback which I really appreciated from Ericom’s CEO Eran Heyman and from their VP Software Development Dan Shappir. All answers are related to Ericom’s new version of Ericom PowerTerm WebConnect.

Well, let’s start with some marketing messages before Eran Hyeman and Dan Shappir will explain some technical details of their product.

Marketing statements by Eran Heyman

We have technology under patent pending which allows seamless integration of several seamless remote windows applications (over a single RDP connection) into the local desktop. No other company has such technology.

For example, other companies can run several applications via a single RDP session but those applications are not seamlessly integrated into the local desktop. The brief explanation is that if you have three remote applications and you would like (over a single RDP connection) to bring just one of them to the foreground ALL three remote applications will move to the foreground covering other local applications, instead of just bringing the one single remote application to the foreground.

We have developed our technology over a long period of time with full management of all local and remote applications and windows to achieve this level of desktop integration. One of the additional benefits of our new technology is that if you have a popup window in the background in a remote application such as a popup meeting alert from outlook, other companies' solutions will not show this important popup alert and Ericom PowerTerm WebConnect will.

We believe that this is a significant breakthrough that will bring RDP based technology much closer to the level of remote applications integration into the local desktop that currently only Citrix supports and now Ericom support with the standard remote display protocol by Microsoft.

Marketing statements by Dan Shappir

As Eran wrote to you, we have invested significant effort in providing a very high level of seamless functionality, including some innovations, which we have submitted for patents. In addition to the innovation which Eran has already mentioned regarding the proper handling of the z-order of remote windows on the local desktop, I would like to mention the following features:

1. Very high performance and low latency for screen updates – remote desktop background doesn’t show even for high resolution sessions with lots of colors
2. Extremely light communication overhead compared to the basic RDP
3. Support for very high resolutions and non-standard screen resolutions
4. Disconnect and reconnect to seamless sessions, even from a different computer, without loosing any attributes of the seamless session
5. Proper interlacing with local windows that have non-rectangular shapes, e.g. Media Player in skin mode
6. Proper ALT+TAB behavior (correct window order is always maintained)
7. Proper window placement relative to local taskbar, also doesn’t cover local taskbar when it is set to “always on top”
8. Does not interfere with taskbar’s autohide functionality
9. Remote top-most windows always accessible
10. Proper window order is maintained even when more than one remote session is accessed from the same local desktop
11. Does not disable local Windows Messenger (other seamless implementation often put it in “busy” mode)

Technical information provided by Eran Heyman

Question: Give a brief description of the enhanced user shell features (= server-side seamless engine)
Answer: We have components that have to be installed on each and every terminal server. This is a hook that captures each and every Windows movement, resize and other events and transmits them to the client side. The client/server communication is done using the RDP channels.

Question: Briefly describe the hooking mechanism used for tracking the creation, modification, hiding, disabling and destruction of application windows? What mechanisms are used to extract application resources like icons, menu items and bitmaps from the application running on the server?
Answer: The hook on the server side tracks all the events. The icons are being transferred from the server to the client to be displayed (for example on the Windows XP bar).

Question: How is the client extension implemented?
Answer: The client is based on the MS RDP control in Windows XP and Windows CE. The basic functionality is using a clipping region. Most of the components are treated by using their window coordinates so they are handled by the remote window manager not the local one; however we do an accurate job in managing the clip regions so to the user it looks perfect. We control all Windows whether modal or not. We focus and un-focus ALL relevant windows. We control the task bar icons and send the relevant notifications to our remote server.

Question: Can you control windows Z orders, windows positions and windows sizes?
Answer: We control the Z orders.

Question: Is session sharing guaranteed when multiple seamless applications are launched by the same user?
Answer: We guarantee session sharing when multiply applications are launched by the same user, unless the domain name is different or the application that the user would like to activate is located only on a different Terminal Server. In any case the administrator can make sure to guarantee that there will not be any exceptions and all applications for the user will be launched within the same RDP session.

Technical information provided by Dan Shappir

All our components, both on the server and the client, are written in C++ and compiled directly to native code. We do not use managed code and the .NET framework in any way.

Components are installed on the Terminal Server in order to provide the following functionality:

1. Seamless windows
2. Load balancing

The seamless windows components monitor window and process events and transmit notifications to the client through virtual channels.

The clients utilize the information encapsulated in these notifications to clip the displayed region of remote desktop so as to seamlessly integrate the remote windows into the local desktop. In addition, this information is used to associate taskbar and ALT+TAB icons with the remote application windows. The client also sends notifications to the components on the Terminal Server in response to user events, for example to activate a remote window when the user clicks on the taskbar icon.

The components and communication protocol have been optimized so as to provide the highest degree of compatibility between the behavior of local and remote windows, while placing a minimal load on the Terminal Server and the network. The total size of the components installed on the server is under 300Kb.

We use a system-wide hook to monitor most Windows events. We use additional mechanisms to monitor process for which a system-wide hook is inappropriate, such as Console windows. We also use a mechanism based on a device-driver to monitor process creation and destruction.

The only graphical resources sent by our components are the icons for the seamless applications. These icons are extracted from the executable files on the Terminal Server, serialized and downloaded via a virtual channel. The icons are selected based on the client operating system and screen attributes.

On the client side, we use the Microsoft RDP ActiveX Control for both Windows and Windows CE. Our executable loads the control, and embeds it in its own window.

In seamless mode, the client receives and sends notifications to the components Terminal Server through the RDP Control using virtual channels. Using the information received from the components on the Terminal Server, it clips the control’s displayable area in order to seamlessly integrate the remote windows into the local desktop. It also manages additional visual components such as taskbar icons for the remote application windows. Most of the graphic elements, such as windows, dialogs and menus, are created and managed on the server.

The client component manages the displayable region and attributes of the local window in order to give them the proper look and behavior. Visual components that are managed locally include the taskbar icons, and ALT+TAB icons.

We use two virtual channels for communicating between the server and the client, one for downstream messages from the Terminal Server to the client, and one for upstream messages from the client to the Terminal Server.

We have found that this configuration works best for Terminal Server 2000 and does not adversely impact Terminal Server 2003. Since the volume of network traffic going through these channels is minute, we did not provide a facility for managing their priority.

Full window drag can be enabled and disabled per session. By default, remote sessions inherit the behavior of the local desktop. Session sharing is utilized automatically when seamless windows are used (session sharing is not applied to non-seamless sessions, which can be used along-side seamless sessions).

1. The same user (username and domain) is used for login to the Terminal Server.
2. The same Terminal Server or server farm (host address) is used.

The administrator can also selectively disable session sharing for particular applications, users or groups.