Grundlagen

Mit Freude hörte ich Ende '99, daß mit Windows 2000 endlich Infrarot-Unterstützung in die NT-Welt Einzug haben wird. Dann machten bald irgendwelche Gerüchte die Runde, daß aber z.B. mein neuer Palm damit nicht funktionieren sollte. Ja, was nun? Infrarot oder nicht Infrarot? Gibt es da noch Zwischenstufen? Palm versicherte mir, man arbeite gemeinsam mit Microsoft an dem Problem (inzwischen hat es ja wenigstens Palm für seine Organizers gelöst).

Das "Problem" wäre aber eigentlich keines, wenn es Microsoft nicht ohne erkennbare Not dazu gemacht hätte. Die Infrarot-Übertragung zwischen Geräten verschiedener Hersteller ist durch den so genannnten IrDA-Standard eindeutig geregelt. Dieser Standard besteht neben dem Grundgerüst, das sagt, wie Daten übertragen werden, aus einer Vielzahl von Anwendungsprotokollen, der regeln, wozu Daten übertragen werden sollen. Eines dieser Protokolle heißt IrCOMM.

IrCOMM wurde geschaffen, um das serielle Kabel zum Anschluß von mobilen Geräten zu ersetzen. Es besteht aus einigen Unterprotokollen, die entweder nur die reine Datenübertragung ermöglichen oder auch zusätzlich die Steuerleitungen übermitteln, die z.B. von Modems verwendet werden. Es existiert sogar eine Nachbildung des Parallel-Ports (Centronics).

Auf der Seite des Betriebssystems, das IrCOMM unterstützt, liegt es nun nahe, einen virtuellen COM- oder LPT-Anschluß zu schaffen, der sich genauso wie ein realer Port verhält. Es ist aber (leider) nicht im IrDA-Standard vorgeschrieben. Ebenso ist auch eine Schnittstelle denkbar, die man als Programmierer einer Anwendung ansprechen kann, um IrCOMM zu nutzen. Der Vorteil der ersten Lösung gegenüber der zweiten ist der, daß bestehende Programme, die nur einen realen Anschluß ansprechen können, dennoch funktionieren - sofern die Nachbildung vollständig ist.

Infrarot in Windows 2000

Man ahnt es schon, wofür sich Microsoft bei Windows 2000 entschieden hat. Richtig, der zweite Weg. Das heißt, eigentlich existieren auch Teile des ersten Ansatzes. Einige Digitalkameras kommunizieren mittels IrCOMM, und deren Besitzer wollte Microsoft aus irgendwelchen Gründen nicht vergraulen. Ebenso ist das Ansprechen eines IrDA-tauglichen Druckers möglich. Mehr dazu ist auf der Microsoft-Homepage in einem Artikel über die IrDA-Unterstützung von Windows 2000 zu lesen. Tja, nur die wenigen Handheld- und Handy-Nutzer haben also Pech gehabt, aber das sind ja nicht viele.

Microsoft dachte sind das wohl nun so: Wer unbedingt mit IrCOMM arbeiten möchte, dar möge auch seine Anwendung an Windows 2000 anpassen. Dazu steht mit einer Erweiterung der Windows Sockets ein Application Programming Interface (API) zur Verfügung. Die Windows Sockets sind zur Netzwerkkommunikation z.B. per TCP/IP gedacht. IrDA und als Teil davon IrCOMM läßt sich im Prinzip auch gut in dieses Interface integrieren. Der Haken ist aber wie gesagt, daß alle bestehenden Anwendungen expizit angepaßt werden müssen. Und wie lange das dauern kann, falls es überhaupt angegangen wird, konnte man ja im letzten Jahr beobachten.

Dieser Umstand ist wiederum bei näherer Betrachtung auch nicht ganz verständlich. Microsoft hat die IrCOMM-Programmierung recht gut dokumentiert und mit Beispielen versehen. Die Programmierung ist für jemanden, der schon einmal mit Netzwerken in seinen Anwendungen gearbeitet hat, ziemlich simpel. Es mag aber sein, daß sich die Erweiterung bei einigen Programmen aus internen Gründen schwieriger darstellt bzw. darstellte.

Nachbildung der Statusleitungen

Das IrCOMM-Protokoll ist relativ schlicht aufgebaut, sein Hauptzweck ist ja auch nur die reine Datenübertragung. Um aber auch u.a. die Statusleitungen des RS232-Ports übermitteln zu können, kann das Protokoll einen Steuerkanal enthalten, in dem diese Informationen codiert sind. IrCOMM ist wie alle IrDA-Protokolle paketorientiert, d.h. der Datenstrom wird zum Versenden in kleine Stücke aufgebrochen. Diese Pakete können verschiedene Größen haben, wobei ihr Maximum zwischen 64 und 2048 Bytes liegt (je nach Fähigkeiten der beteiligten Geräte). Jedes Paket kann nun einen Steuerkanal enthalten, dessen Umfang auf Kosten der Nutzdaten wählbar ist.

So weit, so gut. Microsoft stand nun vor dem Problem, IrCOMM auf die Windows Sockets abbilden zu wollen. Diese API basiert auf Datenströmen, denen man selbst bei paketorientierter Übertragung dieses nicht ansehen kann. Um den Steuerkanal aus den Daten herauszufischen, ist es aber zwingend notwendig, den Anfang der einzelnen Pakete im Strom zu kennen. Für die Abbildung ist es also erforderlich, daß Windows intern den Steuerkanal erkennt und aus den Daten herausnimmt. Diese Funktion, da sie nur IrCOMM und nicht auch andere IrDA-Protokolle betrifft, ist vom Programmierer für seine Anwendung explizit einzuschalten:

int intvar = 1; /* 1: Filter einschalten, 0: ausschalten */
setsockopt(socket, SOL_IRLMP, IRLMP_9WIRE_MODE, &intvar;, sizeof(int));

Nun liegt es ja eigentlich nahe, die gewonnen Informationen aus dem Steuerkanal den Anwendungen über eine geeignete Schnittstelle zur Verfügung zu stellen. Microsoft hat allerdings darauf verzichtet (damit es ein Programmierer mit IrCOMM bloß nicht zu leicht hat?). Windows 2000 gibt dabei anderen Infrarot-Geräten vor, den Steuerkanal zu unterstützen. In Wahrheit läßt es ihn beim Senden einfach leer und ignoriert alles, was in eintreffenden Paketen enthalten ist.

Das Lösungskonzept

Die Aufgabe von IrCOMM2k ist nun, ein Brücke zu schlagen. Auf der einen Seite der Schlucht liegt die bestehende Anwendung, die einen realen COM-Port als Schnittstelle erwartet. Auf der anderen Seite steht die Winsock-API, die das vereinfachte IrCOMM-Protokoll bereitstellt. Das besondere Problem ist dabei, daß - um im Bild zu bleiben - die beiden Seiten der Schlucht sich auf unterschiedlicher Höhe befinden: Ein COM-Port läßt sich nur als Kernel-Treiber realisieren, also einem Programm, das Bestandteil des Systemkerns von Windows 2000 wird. Die Winsock-API hingegen ist für Anwendungen gedacht und kann von einem Kernel-Treiber nicht direkt genutzt werden. Wie ich nun beide Seiten zusammengebracht habe, ist unten dargestellt.


Schematischer Aufbau von IrCOMM2k

Theoretisch könnte man ja auch den IrDA-Stack kontaktieren, da auch er als Kernel-Treiber realisiert wurde. Doch wie man sich mit diesem unterhält, ist Microsofts Betriebsgeheimnis - da wünscht man sich als Programmierer Linux herbei!

[Fortsetzung folgt]