Seit mit Kylix eine Delphi-Version für Linux zur Verfügung steht, wird gefragt, wann denn auch der C++Builder seinen Weg von Windows zu Linux findet. Jetzt ist mit Kylix 3 mehr als nur ein C++Builder für Linux erschienen. Unter diesem Namen verbergen sich zwei eigene Produkte, nämlich Kylix 3 für Delphi und Kylix 3 für C++. Nach der Installation befinden sich im Startmenü der KDE- bzw. Gnome-Oberfläche unter dem Eintrag Kylix 3 dementsprechend zwei Punkte, nämlich Kylix 3 (C++ IDE) und Kylix 3 (Delphi IDE). Es ist also nicht so, dass man ein Programm startet und am Anfang gefragt wird, ob man in C++ oder Delphi (der Begriff Object Pascal wird in Zukunft nicht mehr verwendet werden) programmieren will, sondern es handelt sich um zwei eigenständige Programme. Hier soll im weiteren Verlauf nur die C++-IDE beschrieben und mit dem C++Builder 6 verglichen werden, die Delphi-IDE wird nicht betrachtet.
Startet man Kylix 3 für C++ das erste Mal , bietet sich dem C++Builer 6-User ein vertrautes Bild. Der Objektinspektor mit seinen verschiedenen Farben, die Objekthierarchie sowie die Komponentenpalette sind wie gewohnt vorhanden. Auch die Form und das Editor-Fenster sehen nicht anders aus. Der erste Unterschied wird deutlich, wenn man sich die Tabs der Komponentenpalette anschaut. Diese sind in geringerer Anzahl vorhanden, da alle Windows-spezifischen Komponenten fehlen. Das ist aber auch der Fall, wenn man beim C++Builder auf CLX-Anwendung umschaltet (die CLX ersetzt die VCL für Linux- bzw. CrossPlattform-Anwendungen), und wenn man hier die Komponenten vergleicht, so ist nur ein kleiner Unterschied zu Kylix 3 festzustellen: Es ist ein Tab System hinzugekommen, und die Indy-Komponenten sind erweitert worden. Letztere sind jetzt in der Version 9.0 vorhanden, dementsprechend sind die Tabs Indy Intecept und Indy I/O Handler hinzugekommen. Unter dem System-Tab befinden sich Komponenten zur Darstellung von Datei- und Verzeichnisinformationen wie zum Beispiel die Komponente DirectoryTreeView und FileListView. Da diese Komponenten nicht beim C++Builder 6 vorhanden sind, ist es natürlich klar, dass sie nicht portierbar sind. Das selbe gilt für einige wenige Funktionen, die in einigen Units neu hinzugekommen sind, zum Beispiel Funktionen der Finanzmathematik in der math.h . Weitere interessante Neuerungen sind unter anderem auch die dbExpress-Treiber für Oracle9i und Informix SE.
Kylix 3 bietet natürlich auch die XML- und Web Services-Unterstützung per BizSnap sowie die Entwicklungsplattform WebSnap für das Erstellen von Webserver-Anwendungen und auch DataSnap zur Entwicklung von mehrschichtigen Datenbankanwendungen. Zu DataSnap ist zu sagen, dass MIDAS natürlich nur unter Windows funktioniert, so dass sich DataSnap hier auf die Anbindung an den Anwendungsserver per SOAP reduziert. Da BizSnap, DataSnap und WebSnap für den C++Builder 6 schon in zahlreichen Artikeln behandelt worden sind und die Funktionalität von Kylix 3 sich in dieser Hinsicht nicht von der des C++Builder 6 unterscheidet, soll die Benutzung der entsprechenden Komponenten hier nicht noch einmal demonstriert werden. Statt dessen steht die Portierbarkeit des Codes zwischen Linux und Windows im Vordergrund.

Abb. 1: Kylix 3 für C++ mit der Liste der Komponenten-Tabs.

Portierung einfacher Anwendungen
Den Anfang soll ein einfaches Beispiel machen. Ich ziehe einen Button auf die Form und in dessen OnClick-Ereignis kommen drei Zeilen, die dafür sorgen, dass der Wert einer statischen Integer-Variable bei jedem Anklicken erhöht und auf dem Button angezeigt wird. Dabei kommt die Code-Vervollständigung ins Spiel, die sehr schnell zum Beispiel die Methoden des Buttons in einem in der Größe veränderlichen Fenster anzeigt. Das Kompilieren funktioniert problemlos und schnell und ich sehe meine Anwendung mit der entsprechenden Funktionalität. Interessant ist jetzt, wie ich dieses Projekt mit dem C++Builder 6 unter Windows weiterbearbeiten kann. Also wird es abgespeichert und mit dem C++Builder 6 per Projekt öffnen geladen. Das geht problemlos, die Form wird angezeigt und der Quellcode ist vorhanden. Beim Kompilieren aber kommt es zu zahlreichen Fehlermeldungen. Man kann also die Linux-Projekte in den C++Builder laden, aber nicht kompilieren. Dass man Projekte einfach zwischen den beiden IDEs austauschen kann, war aber auch nicht zu erwarten. Der Grund hierfür liegt in der BPR-Datei, welche eben plattformspezifische Informationen enthält. Allein die Tatsache, dass die Angaben z.B. für den Include-Pfad in einer plattformspezifischen Notation erfolgen (und der Pfad unter Linux natürlich ein anderer als unter Windows ist), macht ein Laden der BPR-Datei der einen IDE in eine andere unmöglich.
Wie bekommt man aber sein Projekt von Linux zu Windows portiert? Nun, da die BPR-Datei nicht portierbar ist, muss also mit dem C++Builder eine neue angelegt werden. Das geht am einfachsten, indem eine neue CLX-Anwendung gestartet wird. Dadurch wird eine entsprechende BPR-Datei erzeugt. Mit dem Menüpunkt Aus dem Projekt entfernen ... unter Projekt werden alle Units entfernt. Im selben Menü werden mit dem Menüpunkt Dem Projekt hinzufügen ... alle Units des Kylix-Projektes diesem Projekt hinzugefügt. Die Form mit dem Button wird sichtbar, und wenn jetzt kompiliert wird, funktioniert alles problemlos. Die Portierbarkeit besteht also darin, dass die Units und Formulare der einen IDE in die (CLX-) Projekte der anderen eingefügt und weiterbearbeitet werden können. Von Linux zu Windows ist eigentlich gar nichts zu beachten (bis auf die oben erwähnten Neuerungen von Kylix 3). Von Windows zu Linux ist zu beachten, dass man keine Windows-Spezifischen Funktionen benutzt. Durch Starten von CLX-Anwendungen wird man aber schon so weit eingeschränkt, dass dieser Fehler nur passieren kann, wenn man per Hand nicht portierbare Units mit einbindet.

Portierung von dbExpress-Anwendungen
Um zu zeigen, welcher Aufwand noch anfallen kann, wenn man Codes portiert, soll als nächstes eine kleine Datenbankanwendung geschrieben werden. Im C++Builder starte ich ein neues CLX-Projekt und ziehe eine SQLConnection, ein SQLClientDataSet, eine DataSource und ein DbGrid auf die Form, die alle, wie in einer dbExpress-Anwendung üblich, miteinander verbunden werden. Bei der SQLConnection wird der ConnectionName auf IBConnection gesetzt, LoginPrompt auf false und unter Params die Datenbank eingetragen. Dazu wird ein Eintrag auf einen Interbase-Server unter Database festgelegt und zwar nach dem Format :, also zum Beispiel 192.168.216.128:c:\employee.gdb. Ich trage also meinen Server und den Pfad auf die Employee.gdb-Datenbank ein. Wenn die SQLConnection und der SQLClientDataSet aktiviert werden (nachdem man unter CommandText eine Tabelle ausgewählt hat), wird im DbGrid die entsprechende Tabelle angezeigt.
Dieses Projekt wird gespeichert und anschließend in Kylix 3 geladen. Im Gegensatz zum C++Builder, der Kylix-Projekte zwar lädt, aber nicht kompiliert, bekomme ich von Kylix gleich zu Anfang eine Fehlermeldung, die mir sagt, dass das Projekt mit einer inkompatiblen C++Builder-Version erstellt wurde. Daher wird, wie oben beschrieben, ein neues Projekt angelegt, alle Units entfernt und die eben gespeicherten hinzugefügt. Das führt erneut zu der Fehlermeldungen, dass eine DLL nicht gefunden werden kann. Damit wird deutlich, wo ein weiteres Problem liegen kann, wenn man Codes portiert. Wenn eine Komponente auf Dateien zugreift, die auf der anderen Plattform nicht vorhanden sind, so wie in diesem Fall die DLL, so ist eine einfache Portierung natürlich ebenfalls unmöglich. Hier hat man zunächst die Möglichkeit, die entsprechenden Einträge abzuändern. Es empfiehlt sich aber ein anderes Vorgehen. Man entfernt die SQLConnection und ersetzt sie durch eine neue, in der man dann den ConnectionName auf IBConnection setzt. Dadurch sind die ganzen Bezüge auf externe Dateien automatisch gesetzt worden. Anschließend muss natürlich unter Params die Datenbank erneut eingetragen werden. Das kann man aber umgehen, indem man die Verbindungsdaten zur Laufzeit lädt. Dazu kann man die Daten in der Datei Dbxconnections.ini eintragen und LoadParamsOnConnect der SQLConnection auf true setzen. Eine flexiblere Möglichkeit bietet die Methode LoadParamsFromIniFile von dieser Komponente, welche auch einen frei wählbaren Dateinamen für die Parameterdatei zulässt. Auf diese Art und Weise gibt man einfach die Verbindungsdaten in einer externen Datei der Anwendung mit und jegliches Eintragen per Hand entfällt. Eine letzte Möglichkeit ist auch das Setzen der entsprechenden Werte per Programmcode, da die Params-Eigenschaft vom Typ TStrings ist und über die Add-Methode beliebige Zeilen eingefügt werden können.
Für welche Möglichkeit man sich auch entscheidet, der Aufwand (pro SQLConnection) ist sehr gering. Wenn man im vorliegenden Beispiel die Anpassung vorgenommen hat, so kann man die SQLConnection und den SQLClientDataSet aktivieren, und wie gewohnt erscheinen die Daten der Tabelle im DbGrid. Das zeigt auch, dass eine Datenbankanbindung per dbExpress voll portierbar ist.

WebSnap
Auch Kylix 3 bietet mit WebSnap eine bequeme Möglichkeit, komplexere Webserver-Anwendungen zu schreiben. Diese können entweder als CGI-Anwendung oder als Apache-DSO erstellt werden. Ebenso wie beim C++Builder gibt es auch die Möglichkeit, eine Web-Debugger-Anwendung zu schreiben, die keinen externen Server benötigt und das debuggen von Kylix aus ermöglicht. Zur Demonstration soll hier eine kleine Anwendung erstellt werden, die es erlaubt, durch eine Tabelle mit dem Webbrowser zu navigieren. Diese Anwendung wird unter Linux als CGI-Anwendung angesetzt und dann unter Windows in eine ISAPI-DLL für den IIS umgewandelt. Zuerst wird wie üblich mit DATEI | NEU | WEITERE unter dem WEBSNAP-Tab eine neue WebSnap-Anwendung ausgewählt. Als Server-Typ wird CGI-Einzelanwendung gewählt und unter Seitenoptionen als Generatortyp der AdapterPageProducer gewählt. Dieser erlaubt es, mit Hilfe von entsprechenden Adaptern, auf einfache Weise Darstellungen und Funktionalitäten zu erzeugen. Da die Daten einer Tabelle dargestellt werden sollen, müssen dem WebAppModul erst mal Komponenten zum Ansprechen einer Datenbank hinzugefügt werden. Als solche kommen wieder die SQLConnection und der SQLClientDataSet zum Einsatz. Sie werden in dem WebAppModul platziert und wie im vorherigen Abschnitt beschrieben eingerichtet. Als Tabelle wähle ich die Customer-Tabelle. Beide Komponenten werden aktiviert. Damit WebSnap die Daten darstellen kann, müssen sie über einen entsprechenden Adapter, den DataSetAdapter, an den AdapterPageProducer weitergeleitet werden. Also ziehe ich einen DataSetAdapter auf das WebAppModul und setze dessen Eigenschaft DataSet auf den SQLClientDataSet. Jetzt muss noch die Darstellung generiert werden. Also klicke ich in der Objekt-Hierarchie, die mir unter anderem den Zugang zu speziellen Funktionen von Komponenten vereinfacht, mit der rechten Maustaste auf den AdapterPageProducer und wähle Editor für Webseiten. Hier kann ich jetzt meine Webpage zusammenstellen. Ich klicke mit der rechten Maustaste in dem Editor auf AdapterPageProducer und wähle Neue Komponente. Hier klicke ich auf AdapterForm, klicke, mit der rechten Maustaste, auf den neuen Eintrag AdapterForm1 und wähle erneut Neue Komponente. Jetzt kann ich zwischen mehreren Elementen wählen. Zuerst sollen die Daten dargestellt werden, darunter dann Buttons zum Blättern. Also klicke ich zuerst auf AdapterFieldGroup, deren Eigenschaft Adapter ich im Objektinspektor auf den DataSetAdapter setze. Zusätzlich klicke ich im Editor mit der rechten Taste auf den Eintrag der AdapterFieldGroup, um festzulegen, welche Spalten der Tabelle sie darstellen soll. Es sollen alle Spalten sein, darum wähle ich Alle Felder hinzufügen. Jetzt sollen die Buttons ausgewählt werden, also beginnt das Spiel, mit der rechten Maustaste auf AdapterForm1 zu klicken, erneut. Nur diesmal wird es eine AdapterCommandGroup, deren Eigenschaft DisplayComponent auf die AdapterFieldGroup gesetzt wird. An Stelle von Feldern werden jetzt Befehle hinzugefügt, also mit der rechten Maustaste auf den Eintrag AdapterCommandGroup1 geklickt und die Befehle FirstRow, PrevRow, NextRow und LastRow ausgewählt. Wenn jetzt im Code-Editor die Unit ausgewählt wird, so hat man am unteren Rand verschiedene Tabs, die den generierten HTML-Code zeigen. Unter Unit1.html kann man jetzt den HTML-Code verändern, wobei die Code-Vervollständigung bei der Auswahl von HTML-Tags hilft. Unter dem Tab Vorschau sehe ich die Darstellung der Webpage. Das ganze Projekt wird abgespeichert und kompiliert. Die (ohne Runtime-Packages und RTL/STL, muss vorher eingestellt werden) erzeugte Anwendung wird mit der Unit1.html in das cgi-bin-Verzeichnis des Webservers (ich benutze den Apache) kopiert und kann sofort getestet werden (in der httpd.conf muss der LD_LIBRARY_PATH auf das bin-Verzeichnis von Kylix gesetzt werden, damit die Javascript-Unterstützung funktioniert). Man kann sich jetzt die Daten der Tabelle ansehen und mit den Buttons durch die Einträge blättern und das, ohne eine Zeile Code geschrieben zu haben, wobei über Ereignisse natürlich noch individuelle Anpassungen möglich sind.

Abb. 2: Die Vorschau auf die WebSnap-Anwendung
Die Anpassung, welche hier jetzt interessieren soll, ist, die Linux-CGI-Anwendung in eine Windows-ISAPI-DLL umzuwandeln. Auch hier gilt natürlich, dass das Projekt nicht einfach mit dem C++Builder 6 geöffnet werden kann. Zunächst wird deshalb eine neue WebSnap-Anwendung gestartet, wobei der Typ jetzt ISAPI/NSAPI-DLL ist. Alle anderen Einstellungen sind egal, weil sie durch die des Kylix-Projektes ersetzt werden. Anschließend wird die Unit1.cpp (die Unit des Web-Moduls) aus dem Projekt entfernt und die des Kylix-Projektes hinzugefügt. Der C++Builder beschwert sich über einige SO-Dateien, die nicht geöffnet werden können. Das liegt an der SQLConnection, die wie oben beschrieben ersetzt werden muss. Wenn jetzt alles gespeichert wird, kann die Anwendung kompiliert werden. Die so erzeugte DLL (mit dem Namen .dll) und die Unit1.html werden in das Scripts-Verzeichnis des IIS kopiert und können mit einem Browser aufgerufen werden. An dieser Stelle wird deutlich, dass aufgrund des modularen Aufbaus der Projekte eigentlich kein Unterschied besteht, ob man eine normale oder eine WebSnap-Anwendung portiert. Der Schritt ist der selbe: Erst ein entsprechendes Projekt anlegen, anschließend die generierten Formulare entfernen und durch die des jeweils anderen Projektes ersetzen. Die Units, die für eineWebSnap-Anwendung eingebunden werden müssen, heißen auf beiden Systemen gleich, so dass hier keine Anpassung notwendig ist. Allerdings gibt es eine kleine Einschränkung, wenn man in die andere Richtung geht, also von Windows zu Linux. Die Windows-WebSnap-Anwendung bindet die vcl.h, die Controls.hpp und die StdCtrls.hpp mit ein. Auf der Linux-Seite müssen in den #include-Anweisungen diese Dateinamen in clx.h, QControls.hpp und QStdCtrls.hpp umbenannt werden.

Web Services
Der letzte Fall, der hier gezeigt werden soll, ist die Erstellung von Web Services. Da gibt es zwei Seiten zu betrachten, nämlich den Web Services-Server und den entsprechenden Client. Zuerst wird der Web Services-Server mit dem C++Builder erstellt und zu Linux portiert. Dazu erstelle ich eine neue SOAP-Server-Anwendung und lasse mir vom C++Builder das Interface für das SOAP-Modul erzeugen. Der Service soll der Einfachheit halber TestService heißen. In der generierten Header-Datei TestService.h füge ich in das Interface eine rein virtuelle Methode mit dem Namen echo ein, die einen AnsiString entgegennimmt und diesen einfach wieder zurückliefert. Die entsprechende Implementierung schreibe ich in der zugehörigen .cpp-Datei in die ebenfalls vom C++Builder generierte Klasse TTestServiceImpl. Das Projekt wird gespeichert und kompiliert und die so erzeugte DLL in das Scripts-Verzeichnis des IIS kopiert. Wenn ich sie mit einem Browser aufrufe, bekomme ich die WSDL zum Benutzen des Services angezeigt.
Dieses Projekt soll jetzt unter Linux benutzt werden, um einen entsprechenden Web Services-Server für den Apache zu schreiben und auch dieses Mal als CGI-Anwendung und nicht als DSO. Die ersten Schritte sind die selben wie im C++Builder. Also wird eine neue SOAP-Server-Anwendung erstellt. Die Frage, ob ein Interface erstellt werden soll, wird mit nein beantwortet, da wir ja das aus dem Windows-Projekt benutzen wollen. Die Unit des Web-Moduls wird dazu aus dem Projekt entfernt und die des Windowsprojektes hinzugefügt, ebenso die .cpp-Datei des Services TestService.cpp. Das Kompilieren führt jedoch zu zahlreichen Fehlern. Der erste ist mal wieder das #include in der TestService.cpp, das durch #include ersetzt werden muss. Als nächstes ist der Typ ULONG nicht in Kylix definiert und muss durch int ersetzt werden. Dieses findet man dadurch heraus, dass man sich einen Web Services-Server mit Kylix erzeugt und die generierten Dateien mit denen des C++Builders vergleicht. Nun sind noch ein paar Symbole undefiniert. Daher müssen der .cpp-Datei folgende Zeilen vor der Klassendeklaration hinzugefügt werden:

#ifndef STDMETHODCALLTYPE

#define STDMETHODCALLTYPE __stdcall

#endif

#ifndef S_OK

#define S_OK 0

#endif

#ifndef E_NOINTERFACE

#define E_NOINTERFACE -1

#endif

Diese erhält man ebenfalls aus einem entsprechenden Kylix-Projekt. In der Praxis dürfte es sinnvoller sein, diese Zeilen in einer separaten Header-Datei abzuspeichern und in die von Windows portierten Dateien einzubinden. Das sind alle notwendigen Änderungen, danach kann man die CGI-Anwendung problemlos kompilieren und testen.
Und wie sieht die andere Richtung aus? Um das herauszufinden, wird mit Kylix zunächst der selbe Web Service erstellt. Mit dem C++Builder wird anschließend eine neue SOAP-Server-Anwendung vom Typ ISAPI/NSAPI-DLL erstellt und das Web-Modul aus dem Projekt entfernt. Wenn man jetzt das Web-Modul und die .cpp-Datei des Kylix-Web Services dem Projekt hinzufügt, bekommt man eine neue Fehlermeldung. Der C++Builder beschwert sich, dass der in der Eigenschaft Converter des HTTPSoapCppInvoker eingetragene Converter auf eine Eigenschaft Encoding verweist, die nicht existiert. Dahinter verbirgt sich die Tatsache, dass die Web Services-Untertützung im Vergleich zum C++Builder bei Kylix bereits weiterentwickelt und um die Unterstützung von Attachments und verschiedenen Zeichensätzen bei kodierten Methodenaufrufen erweitert wurde. Dazu wurde der OPToSoapDomConverter mit zusätzlichen Eigenschaften versehen, die bei der entsprechenden Klasse des C++Builder noch nicht vorhanden sind (aber vielleicht in einem zukünftigen Update). Das bedeutet jedoch nicht das Aus für die Portierung der Server-Anwendung, denn man kann die Hinweise des C++Builders ignorieren, solange man nicht die entsprechenden Eigenschaften (Attachments, Encodings) verwendet hat. Das haben wir hier nicht, deswegen sehe ich nach einem Klick auf ignorieren das vertraute Web-Modul. Dann tritt noch ein Fehler auf, weil bei dem Kylix-Projekt der Xerces-Parser benutzt wird. Man kann einfach die entsprechende Zeile zur Xerces-Initialisierung aus dem Konstruktor entfernen, ebenso das Xerces-Include aus der Header-Datei, um die Anwendung erfolgreich zum Laufen zu bringen. Sicherer ist es aber, das Web-Modul vom Anfang nicht zu entfernen, sondern nur die Web Services-CPP dem Projekt hinzuzufügen. In dieser Datei muss auch noch eine Kleinigkeit angepasst werden: Es ist von Kylix schon der Fall vorbereitet worden, dass sie in einem Windows-Projekt benutzt wird, deswegen gibt es eine entsprechende #ifdef-Sektion. Damit die richtige aufgerufen wird, muss __windows__ vor der Klassendeklaration definiert werden (geht auch über das Setzen der entsprechenden Bedingung bei den Projekt-Optionen):

#if !defined(__windows__)

#define __windows__

#endif

Damit wäre der Web Services-Server abgehandelt. Es fehlt nun noch die Betrachtung von Clients, die diesen Service benutzen. Den Anfang macht wieder der C++Builder. Ich starte eine neue CLX-Anwendung, auf deren Form ich einen HTTPRIO, ein Edit-Feld und einen Button ziehe. Der RIO bekommt unter der Eigenschaft WSDLLocation im Objektinspektor die URL der WSDL eingetragen. Für den eben erstellten Web Services-Server im cgi-bin-Verzeichnis des Apache-Servers heißt diese zum Beispiel http:///cgi-bin//wsdl/ItestService. Unter Service und Port werden die angebotenen Einträge ausgewählt. Mit dem WSDL-Importer wird noch eine Unit aus der WSDL erstellt (die URL ist die selbe wie für den RIO) und diese in die Unit der Form mit eingebunden. In das OnClick-Ereignis kommen ein paar Zeilen, die den Service aufrufen und das Ergebnis im Edit-Feld anzeigen:

_di_ITestService service;

HTTPRIO1->QueryInterface(service);

Edit1->Text=service->echo("Testaufruf");

Die ersten beiden Zeilen sind Standardcodes zum Benutzen eines Web Services. Diese Anwendung wird kompiliert und durch Drücken des Buttons getestet.
Bei Kylix wird ein neues Projekt angelegt und die Unit der Form aus dem Projekt entfernt. Dafür wird die Unit des Formulars des Windows-Projektes und die aus der WSDL generierte Unit diesem Projekt hinzugefügt. Beim Kompilieren kommt es erneut zu einem kleinen Fehler: Kylix beschwert sich, dass die Header-Datei SoapHTTPClient.hpp nicht geöffnet werden kann. Das liegt daran, dass sie hier unter Linux SOAPHTTPClient.hpp heißt. Da Linux Groß- und Kleinschreibung bei Dateinamen unterscheidet, kann Kylix die Datei nicht finden. Also wird der Dateiname entsprechend geändert, und die Client-Anwendung funktioniert problemlos.
Um die Portierung zu Windows zu testen, wird die selbe Anwendung nun noch einmal unter Linux erstellt. Mit dem C++Builder wird danach eine neue CLX-Anwendung erstellt und wieder einmal die Unit der Form entfernt. Anschließend wird die Formunit des Kylix-Projektes und die vom WSDL-Importer erzeugte Unit dem Projekt hinzugefügt. Es kommt zu der bekannten Fehlermeldung, daß die Converter-Eigenschaft des RIOs auf einen Converter mit der nicht vorhandenen Eigenschaft Encoding zeigt. Die Ursache ist die gleiche wie bei der Server-Anwendung, und auch hier kann man diese Meldung ignorieren. Da Windows keinen Unterschied zwischen Groß- und Kleinschreibung bei Dateinamen macht, kommt es nicht zu dem Fehler mit der SoapHTTPClient.hpp. Es sind daher keine Anpassungsarbeiten nötig, man kann die Anwendung kompilieren und testen.

Zusammenfassung
Mit Kylix 3 für C++ hat der C++Builder nun auch sein Pendant auf der Linux-Plattform erhalten. Zu der sehr großen Bedeutung von Kylix 3 als erste C++-RAD-IDE für Linux braucht man wohl keine Worte zu verlieren. Zum Funktionsumfang kann man vereinfacht sagen, dass die gesamte Funktionalität des C++Builders bzw. die zum Schreiben von CLX-Anwendungen auch in Kylix 3 enthalten ist, wobei Kylix sogar noch erweitert wurde.
Plattformunabhängige Entwicklung ist damit für Windows und Linux auch in der Sprache C++ möglich. Man kann zwar nicht einfach die Projekte austauschen, aber der Aufwand, der nötig ist, um die Projekte entsprechend anzupassen, ist, wie an den Beispielen gezeigt wurde, sehr gering. Wenn man bedenkt, dass es vorher unmöglich war, komplexe Anwendungen mit einem Code für Windows und Linux zu schreiben, so fällt das gar nicht ins Gewicht. Zudem könnte man die Code-Anpassungen für große Projekte auch mit einem kleinen, selbstgeschriebenen Programm problemlos automatisieren. Der Vollständigkeit halber soll noch gesagt werden, dass im Kylix-Handbuch auch Vorschläge gemacht werden, wie man Projekte unter dem C++Builder und unter Kylix so anlegen kann, dass man quasi zeitgleich mit beiden IDEs arbeiten kann, also ohne das Projekt in der einen IDE fertigzustellen und dann in der anderen zu importieren. Aber dieses Vorgehen erschien komplizierter, so dass in der Praxis wohl eher doch erst ein Projekt auf einer Plattform vollständig entwickelt wird und dann auf der anderen nur noch kompiliert wird.
Abschließend bleibt festzustellen, dass Kylix 3 dem C++-Entwickler zahlreiche neue Pforten geöffnet hat und es wird interessant sein zu sehen, wie sich die Programmierlandschaft gerade unter Linux dadurch verändern wird.