Monthly Archives: June 2007

One of the most confusing things ever invented is time zones.  Well, they aren’t inherently confusing by themselves but when you start talking about different time zones and daylight savings, then things get messy.  Add in a factor of government zeal and you have daylight savings that can change dates depending on the laws and years that pass.

Microsoft has struggled with this for years with fairly regular updates based on regional changes.  As you probably already know, the US has changed the default dates this year in an attempt to save energy.

Obviously computers don’t care much about time zones themselves but obviously the applications and users do.  If the time zone is wrong then the time is wrong and all kinds of other bad things can happen from there.  Sometimes it is not obvious that it is the time zone settings that are incorrect.

Regardless of all this fanfare, time zones are usually right and do provide a useful service to the user.  When Windows correctly adjusts the time for daylight or standard times, it is actually a bit handy.

From a Citrix point of view, we had a new problem.  What if the client and server time zones do not match?  If a user logs into a Presentation Server, which time zone is he or she going to see?  In the old days, the user would get the server time zone and would just have to put up with it.  Around the year 2000, Citrix added support for using the time zone of the client on the server.  The enabled the user to see their time zone being used for all the applications on the server.  This includes applications that are time aware like Outlook to be able to display the meeting times in the correct local (user) time.

How was this accomplished?  Basically the client started to send its time zone information to the server during initialization.  Once the server starts the session, WFSHELL loads TZUSER which then starts the process of getting the client time zone and then configuring TZHOOK to actually change the time zone for that session.  TZHOOK, as it sounds, hooks the time zone API and reports the client time zone information instead of the server’s time zone.  This way, the applications things it is asking Windows for the native time zone information when really it is coming from the client.

The Presentation Server time zone support also supports clients that might not have the built in support for time zones.  It does estimation based on the client time.  It also has a policy defined that turns off time zone support if desired.

In PortICA we have a very different model.  Because we are a single user system, we can get away with changing the real time zone during the session.  This gets rid of the need to fool applications with the hook since it is already embedded with Windows with the server and client time zone matching.  We do not match the time itself.  This approach greatly simplifies the code which now really just to worry about saving and restoring the “real” time zone for the machine.

By the way, the time zone support does not use a virtual channel.  The information about the client time zone is embedded in the standard information used during the initial exchange between client and server.  Also, on PortICA, the PICASHELL component is responsible for loading TZUSER and there is no TZHOOK to process.

This is where I have to come clean and admit that I did not fully understand the model of how Presentation Server works related to Com Ports.  It turns out that doing a NET USE against a client COM port will automatically attempt to use the new way.

NET USE COM1: \\CLIENT\COM1:

This command is like saying that I want to get access to COM1 and I really don’t mind if it is being done the old or new way.  Internally, the provider code (cdmprov.dll) is checking to see if the COM port supports the new interface.  It if does, it uses it by assigning CLIENTPORT to the name in the symbolic link that is used to open the device within the CDM redirector driver.  If it cannot find the new interface, it will just go back to using the old interface.

So, I was wrong about how CPS does this externally but not internally.

Given this new news, now I have to go back and make PortICA more like CPS with the naming conventions for the NET USE.

This should not be a big deal since it will be all about changing our provider to be smarter about the COM ports so that it will do all of this automatically.  The biggest hassle is enumerating the COM ports which it does already.

Sorry for the confusion.  Just think of this as a journey shared through the inner workings of Client Device Mapping.
Thanks to Marco in Citrix Sydney for pointing this out.

In the last post I just talked about the differences between old and new Com Port Mapping.  This time I’m just going to focus on the old stuff.

First of all, the old Com Port Mapping only supports COM1 and COM2.  This is accomplished by giving each their own virtual channel.  These virtual channels are so old that they are given reserved channels 5 and 6.  This would have been inherited from the original Multiuser based product first designed in 1989.  LPT1 and LPT2 are treated very similar and given channels 1 and 2.

On these channels, the protocol is fairly simple.  The focus is on presenting data from the server to the client for the sake of printing (either COM or LPT).

The model only allows for writing these ports.  It also does not allow setting anything special with the COM port.  The list of possible operations is basically OPEN, WRITE, SET INFORMATION, GET INFORMATION, and CLOSE.  SET INFORMATION and GET INFORMATION are very limited and only support the concepts of printer status feedback.

It is good advice to consider the Old Way as being write-only with limited control support.  It is good for simple printing but absolutely no good at anything that requires bi-directional data.

In PortICA we still support this interface in the hopes of keeping things compatible with the older model.  Obviously it makes more sense to use the new model when dealing with more advanced operations than simple printing.

The PICAPAR driver in PortICA will handle these requests.  This driver is responsible for all the old ways of working with COM1, COM2, LPT1, and LPT2.  It is modelled after how CDM.SYS works in Presentation Server.

Some features in Citrix Presentation Server are mostly unknown to large groups of people.  COM Port Mapping is perhaps more the back water of the more traditional features.  The concept is that it is possible to use COM ports on the client from server applications.  This, in concept, is fairly easy.  Unfortunately things are never as easy as they sound.

There are two kinds of COM port mapping support in Citrix.  Why two?  Well, one is the old way of doing things and the other the newer.  Don’t ask me why the two ways weren’t combined.  I’m not sure about that.  It is similar to how there are multiple layers of supporting things related to printing.  The old way is very basic and is focused primarily as treating the COM port like a file destination for the sake of printing.  This was initially enabled to allow printing to simple printers on COM1 and COM2.  In the early days it was common to have these ports defined for Point of Sale (POS) to control a cash register drawer or print receipts.  Believe it or not, customers out there are still using it this way.  Perhaps Citrix was worried that merging the old and new way would potentially break the customers depending on the old way.  That’s my best guess.

The new way does much more work to make the COM port remote.  It supports (hypothetically) all the client COM ports and does so in a much more native fashion.  Instead of just acting like a basic DOS device, it actually supports all the IOCTLs like a normal serial driver.  This means that it covers a much broader range of applications.  The applications will think they are dealing with a normal local serial port when really it is doing work with the client’s serial port (note I’m going to use COM and serial port interchangeably even though Microsoft defines them differently).  With this level of support, things like HyperTerminal work with remote COM ports.

One of the key steps to getting this working is to enable COM port mapping in the policies and to map the COM ports in the logon script.  I recently noticed that CPS has a policy to automatically map the COM ports but this is a very recent development (as far as I know it is new to 4.5).  This is the whole reason I decided to write this post.  The mapping is where you decide what kind of COM port mapping code you are going to use.

If you do the most natural thing, you are going to end up mapping devices using the OLD way of doing COM ports.

NET USE COM1: \\CLIENT\COM1:

This invokes code in our CDM provider that parses the path and realizes that we are dealing with the old way.  It, in turn, asks for access to the device from CDM.SYS which also concludes that we are dealing with the old way.  The protocol for the old COM port code is fairly basic and is very similar to the old LPT port mapping code (which is limited to LPT1 and LPT2).

Where’s the the basic assumption goes wrong.  If you map to your COM port this way, you will not be able to take advantage of the applications that can access the more recent COM Port API (which translates to the COM Port API that were first included in Windows 95).  Things like HyperTerminal simply will not work.

So, this mapping is good for basic printing but not good for something that is more aware.  What is the alternative?

NET USE COM1: \\CLIENT\CLIENTPORT:COM1:

CLIENTPORT makes all the difference.  It is really just a tag to tell the provider and driver that it needs to treat the COM port as being more advanced.  I have often mentioned this during PortICA to the test people and others and it is very relevant to understanding how to select the right technique.

I’ll give you some some technical detail of how things are going to work in PortICA.

Instead of just having one monolithic driver for CDM (Client Device Mapping), PortICA will have four drivers.  This is for a couple of reasons.  First, splitting it up hopefully will make it easier to support when one device has trouble.  Secondly, the Client Drive Mapping has been completely redone for PortICA using the OSR FSDK toolkit.  The initial CDM driver was based on the NT file redirector and it was time to move the technology forward.  There has been good outcomes already from breaking from the old model already and it hopefully will make it easier to work with in the future.  The existing code will be used for COM and LPT ports as well as the Audio kernel support.  These last three drivers (known as PICACAM, PICASER, and PICAPAR) will share common code but will have specific code to support there devices.  It is much better this way.  Obviously there is still more that can be done.
The PortICA provider is new and now smart about splitting up the requests between the different drivers.  PICASHELL (derived from WFSHELL) is now driving how the resources get mapped and unmapped within the session.  The requests come from PICASHELL to the MPR to the PortICA provider who forwards it ultimately to the relevant drivers using the object manager to create symbolic links.

I know this is a bit technical but I thought someone out there would enjoy it.

As a side note, the PICA prefix is prevalent throughout the PortICA modules and obviously a shortened version of PortICA (the PortICA prefix was just too long).  Also obvious is that PICA really stands for Portable ICA but more recently we have concluded that perhaps Personal ICA is a better description of what this project is really about.  We’ll let someone outside of Engineering worry about the messages.