Fundamentals

I was excited to learn in late 1999, that Windows 2000 finally would introduce infrared support into the NT-world. A little later rumors started spreading, that e.g. my new Palm Pilot would not be compatible with that. Well, what now? Infrared or not infrared? Are there other layers? Palm assured me they were working with Microsoft on a solution for this problem (in the meantime, Palm at least resolved this for its Organizers).

But the "problem" would never have to become one, if Microsoft would not have caused it (without apparent need to do so...). Infrared communication between devices of different vendors is clearly standardized through the IrDA-standard. This standard specifies the basic framework, which outlines how data is transmitted and also a number of application protocols, which define where data gets transmitted to. One of these protocols is IrCOMM.

IrCOMM was built to replace the serial cable used to connect mobile devices. It entails a few sub-protocols, which either enable raw data transmission or transmit status lines, which are used by modems (for instance). It can even emulate a parallel-port (Centronics).

Within the Operating System that supports IrCOMM it is suggested to create a virtual COM or LPT-port, which operates just as a physical port. Unfortunately this was not defined in the IrDA-standard. An interface which could be utilized by a programmer of an application to address IrCOMM would make sense too. The advantage of the first solution comparing to the second is, that existing applications which can only address a real port will continue to work - as long as the implementation is complete.

Infrared in Windows 2000

One could guess which solution Microsoft chose for Windows 2000. Right - the second option. There exist fragments of the first option too. Some digital cameras communicate via IrCOMM, and Microsoft apparently wanted to avoid causing a great upset of those user, for some reason. Also, addressing a IrDA compatible printer is possible. More about this could be obtained from a document on Microsoft's website, IrDA Networking Support under Windows 2000. Well, only the small number of Handheld and Cell phone users are out of luck then, but there aren't many of those. 

It looks like Microsoft thought about it that way: those users who really want to work with IrDA, should modify their applications to be compatible with Windows 2000. An extension of the Windows Sockets provides a Application Programming Interface (API) for this purpose. The Windows Sockets are thought to be used for network communications, e.g. via TCP/IP. IrDA and as a component of this, IrCOMM allows -in essence- decent integration with this interface. The catch with that is, as mentioned above, that all existing applications have to be modified. And how long that process could take, if it will be started at all, one was allowed to observe last year. 

This entire aspect is -when looking closer- not really understandable. Microsoft documented the IrCOMM-programming very well and complemented it with examples. The development is quite easy, for someone who has worked with networks in the past when designing applications. It might be the case that implementing the enhancements into some applications is, respectively has been more complicated. 

Emulation of the status lines

The IrCOMM-protocol is relatively simple, the main purpose being data transmission. But in order to transmit (amongst others) the status line of the RS232 port, the protocol can entail a control channel, which contains this coded information. IrCOMM is a packet protocol, as all the IrDA-protocols are, which means, the data stream is broken into pieces in order to transmit it. Packets could be sized differently, their maxim length (depending on the device used and its abilities) varies between 64 and 2048 Bytes. Each packet could now contain one control channel. While its scope could be chosen, it will have direct impact on the user data.

Having gotten thus far, Microsoft faced now the challenge, to build IrCOMM compatible to the Windows Sockets. This API is based on data streams, which are hard to identify even while using packet transmission. In order to isolate the control channel within the the data, it is essential to enable reliable identification of the start sequence of each packet within the stream. To build IrCOMM compatible to the Windows Sockets it is therefore required, that Windows detects the control channel und separates it from the data. This function should be specifically enabled by the developer, since it is only related to and will only affect IrCOMM and not other IrDA-protocol:

int intvar = 1; /* 1: turn on filter, 0: turn off */
setsockopt(socket, SOL_IRLMP, IRLMP_9WIRE_MODE, &intvar;, sizeof(int));

One could think it would make sense to use an API in order to provide the information gathered from the control channel to the applications. Microsoft decided not to provide this (to make it a bit more complex for developers working with IrCOMM?). Windows 2000 signals to other IR devices that it does support the control channel, but the truth of the matter is, that it doesn't utilize it when sending data and discards all incoming packets. 

The concept for a solution

IrCOMM2k's purpose is now to bridge this "canyon". One side of the canyon there is an existing application, which anticipates a true COM port as an interface. On the other of this canyon side you have the Winsock-API, which provides the simplified IrDA-protocol. The specific problem here is -to stay within the context of the example- that both edges of the canyon are on different heights: a COM port can only be implemented as a Kernel driver, an application which will become integral part of Windows 2000. The Winsock API on the other side is meant for applications and can't be accessed directly by a Kernel driver. How I made both sides communicate is shown in below image:


Schema of IrCOMM2k's design (sorry, still untranslated)

In theory you could also contact the IrDA-Stack, since it was also implemented as a Kernel driver. But how you address this driver is Microsoft's secret - as a programmer this makes you think about Linux!

[... to be continued ...]