Tag Archives: PortICA

Brian Madden Writes about PortICA (XenDesktop ICA)

Brian Madden was in Sydney recently and got the chance to gather more detail about PortICA from the actual developers.  As expected, he has taken the time to summarize his findings in a recent post about PortICA.  It is a fair and comprehensive assessment of Citrix’s new ICA technology for XP and Vista.

What is really cool is that the industry is starting to catch on to the fact this is actually new technology.  The catch phrase “same but different” rings true and I am pleased to see that Brian gets it and has captured it so well in this post.

If you are following XenDesktop, this is a perfect opportunity to understand the technology a bit more and contrast it with other vendors in the VDI space.

Besides that, I have worked on PortICA over the last two years and it feels good to get some outside feedback.  The rest of the PortICA team feels the same way.

Techniques for Generating Fake COM Ports

I wrote this last July on an internal blog.  Now it seems that it should be made available outside as well.  It is only meant for testing COM port mappings with Citrix but the ideas could be applied elsewhere with regards to building fake device names.

Original Post:

Since I am doing testing with PortICA and COM ports, I needed a way of constructing COM ports to test the full range of Client ComPort Mapping (CCM) support.  CCM can support up to 32 COM ports from the client and normally this would be difficult to create.

With some games within symbolic links, it actually is not that bad.

I only started working on this on Tuesday so please excuse the roughness of how it is laid out.

//
// FAKECOM.cpp : Incredibly simple program to generate fake COM ports for the sake of testing.
//               This program will create all the COM ports from COM1 to COM32 in the current session.
//               All of these COM ports will point to the standard serial driver with the first port (\Device\Serial0)
//
#include “stdafx.h”

#define MAX_COM_PORT_NUMBER         32
#define MAX_COM_PORT_NAME_LENGTH    10
#define MAX_DEVICE_NAME_LENGTH      500
#define SERIAL_DRIVER_PATH          L”\\Device\\Serial0″

WCHAR g_ComPortName[MAX_COM_PORT_NAME_LENGTH];
WCHAR g_DeviceName[MAX_DEVICE_NAME_LENGTH];

void RemoveDeviceDefine(LPCWSTR ComPortName);

int wmain(int argc, WCHAR * argv[])
{
int i;
BOOL bRet;
DWORD Size;

for(i=1; i <= MAX_COM_PORT_NUMBER; i++)
{
swprintf(g_ComPortName, MAX_COM_PORT_NAME_LENGTH, L”COM%u”, i);

// make sure to remove all other entries first
RemoveDeviceDefine(g_ComPortName);

bRet = DefineDosDeviceW(DDD_RAW_TARGET_PATH, g_ComPortName, SERIAL_DRIVER_PATH);

if(bRet == FALSE)
{
wprintf(L”DefineDosDeviceW failed index(%u) rc(%x)\n”, i, GetLastError());
}
else
{
wprintf(L”Device %s defined\n”, g_ComPortName);
}
}

// now go prove that it is set correctly
for(i=1; i <= MAX_COM_PORT_NUMBER; i++)
{
swprintf(g_ComPortName, MAX_COM_PORT_NAME_LENGTH, L”COM%u”, i);

Size = QueryDosDeviceW(g_ComPortName, g_DeviceName, MAX_DEVICE_NAME_LENGTH);

if(Size == 0)
{
wprintf(L”QueryDosDeviceW failed index(%u) rc(%x)\n”, i, GetLastError());
}
else
{
wprintf(L”Device %s defined as %s\n”, g_ComPortName, g_DeviceName);
}
}

return 0;
}

void RemoveDeviceDefine(LPCWSTR ComPortName)
{
DWORD Size = 0;
BOOL bRet;

do
{
bRet = DefineDosDeviceW(DDD_REMOVE_DEFINITION, ComPortName, NULL);

// check to see if there is anything left to remove
if(bRet)
{
Size = QueryDosDeviceW(ComPortName, g_DeviceName, MAX_DEVICE_NAME_LENGTH);
}

} while((bRet != FALSE) && (Size != 0));

return;
}

Enjoy!

Cursor Blinking

There is a feature in operating systems that most of us take for granted.  This is the simple text cursor.   There is a bit of confusion within Windows whether it is called a caret or a cursor (based on the API) but for most people it would just be called a cursor.  The definition of what a cursor is and does is summarized at Wikipedia(cursor).

Blinking Cursor example

Even though computer systems are very different, the cursor remains essentially the same.  Wikipedia makes a good point that there are two cursors typically involved.  One belongs to the mouse pointer and the other shows where the text input will go.  It’s a simplistic explanation but I wanted to make sure that you know I’m talking about the text cursor this time.

The mouse was invented in 1963 by Doug Englebert so it is easy to guess that the mouse cursor was invented then as well.  The text cursor was invented in 1954 as part of the IBM 610 project.  At the same time the first video console was created, so was the first text cursor.

I don’t know when the blinking cursor first came into being.  There is a chance that it existed at the beginning.  It would have been pretty obvious that a cursor isn’t much good unless you can find it.  Blinking things tend to get your attention.  It is clever that it blinks at a frequency that gets your attention but does not annoy you.  It has been known to cause problems for people who have epilepsy.  Microsoft recommends turning off the cursor blinking to avoid seizure.

Cursor Blink-Rate Options

Users who have seizures might be sensitive to the blink rate of screen images, such as the cursor. You can use the Keyboard option in Control Panel to adjust the rate at which the cursor blinks, or you can prevent it from blinking at all. On the Speed tab, move the Cursor blink rate slider all the way to the left to prevent the cursor from blinking.

However, there is another reason why cursor blinking should be off.  In a Terminal Services environment (including Citrix), the cursor blinking can actually be a drain on the system and network.  Each cursor flash (on or off) is sent as a video update to the client.  This can create a sizable amount of traffic if hundreds of users are involved.  In fact, both the network bandwidth and CPU cycles would be wasted.  This is especially true for when there is no user there.  Idle sessions with blinking cursors can create activity that is essentially wasteful.  Usually the cursor is turned off in Terminal Services environments but sometimes it can still be active.  For example, in Windows XP, the cursor flashes as if it would do on the console but going through RDP.  The easiest way to disable the flashing is to use the keyboard control panel applet and shift the blinking rate to none.

CursorBlinkRate

The cursor to the left of the slider will show you how fast the cursor will blink.  The default is to cycle the cursor every 1060ms (1.06s).  This is for both the on and off stages.  The default I quoted is from Windows 2003 and Windows XP.  Windows 2000 had it at 1000ms for some reason.  The real question is why 530ms was chosen over 500ms for each stage.  If you know the answer, I’m curious to know.

There is one downside to turning off the blinking however.  It makes the cursor blend in with the rest of the screen.  It also looks a bit strange if you are used to flashing cursors.  We had a bit of a debate about this with PortICA and the ultimate decision has yet to be reached.  The current bias is towards not adjusting what the administrator or user has chosen.  In other words, respect the settings and make it look just like how it would normally.  Microsoft and Citrix have a history of wanting to turn off the blinking.  There were lots of good arguments against it in the past.  Many of those reasons aren’t as valid as they used to be based on the exploding capacity of network bandwidth and CPU cycles.

In PortICA we want to make it as normal an experience as possible.  We also have the luxury of claiming a workstation for ourselves (unless we are being virtualized).  This means that we prefer the user experience over worrying about resource usage.  Rest assured, we do not want to waste resources but we do want to present the best face.  This means that the user should see what they normally see.  Based on my own experiences, the cursor does add a lot of value to doing text input and it feels like something is just not right when it doesn’t act like it normally does.

All of this was recently triggered by the problem that was found with HyperTerminal.  Some applications just don’t like having the cursor being non-blinking.

As this post comes to an end, I realize that what would normally be considered a boring topic is actually interesting.  Well, maybe not that interesting but at least relevant.  I could have dived into the realm of the Windows API related to the cursor (caret) blinking or even the place in the registry where the user profile stores the blink value for Windows.  Not that, for most, would truly be boring so I’ll just skip it.

If you have opinions about what PortICA should do for this, please leave a comment.  Assume for now that we will fully respect the user’s setting for blink rate.

PortICA Time Zone Support

This post is really about trying to catch up with what has been going on with PortICA Time Zone Support. For those of you that haven’t read about Citrix Time Zone Support, please look at my previous post. The idea is to preserve the user’s local time zone while working on a potentially very distant machine. Time is very important to the user and even though a server might be in London, the user in Sydney can’t accept the time difference from their sense of time.

Personally, even though I live in Australia, I still have trouble adjusting to remembering time differences between locations especially with daylight savings in effect in opposite directions. The point is that I don’t want to see a different time zone in effect on systems I would use remotely.

With PortICA, we use the same framework as Presentation Server for changing the time. However, there is a key difference. PortICA changes the time zone for real versus Presentation Server which virtualizes it per user. This means that when a user connects, PortICA will automatically re-adjust the time zone based on the client’s time zone. When the user logs off or disconnects, PortICA will automatically restore the time zone.

This implementation is much simpler than a virtual method. It also gives you full compatibility with all applications. There is a catch however. Now that PortICA really changes the time zone, the user must have the privilege to change the time (in XP). By default, only administrators and power users have the rights to change the time. It is possible to give other users the rights to change the time, but it requires two different categories of changes.

First, you must have the privilege to change the time on that system. This can be changed with GPOs (policies) or the local policies (if not in the domain). This privilege isn’t necessarily a light weight thing to be giving out but it is necessary to allow the time zone support to work with users in PortICA.

Secondly, you must change the registry rights for the time zone information on the machine to allow the user to change the time zone. This isn’t known as well. There is a Microsoft support knowledge base article about this.

Earlier in PortICA development we had a service that would do the work of changing the time zone for the users that didn’t have the rights to do so. This avoided the need to set policies or change registry security rights but was not considered a secure enough solution. The idea is that the administrators need to be responsible for privilege allocation. It’s the classic balance between usability versus security.

In a way this post is a heads up to the potential complexity of supporting time zone support on PortICA for XP. The good news from this story is that Vista doesn’t have this problem due to users given the rights to change the time zone isolated from changing the actual time. From this move, it appears Microsoft has considered the decision to connect changing the time and changing the time zone incorrect. I would agree. Changing the time zone does not change the core time and therefore is much less sensitive to security threats.

My bit of advice for this is to setup a group that has rights to the privilege and registry areas. Then it is just a matter of adding users into that group (which might be a different group like remote users) to get them access to changing the time zone for PortICA.

Overall PortICA is progressing very well and should be talked about a fair amount at the upcoming iForum in Las Vegas. It has been great to see this project reach critical mass and reach wider audiences.