FAQ

Gut zu wissen
 

Programmierung und Betriebssysteme Einfache Programmierung ohne DLL Wo Windows NT nichts taugt Linux & Messkarten Treiber ohne Ende ?   Zurück

Spass muss sein. Warum echte (Fortran-)Programmierer kein Pascal mögen?
Bitte lesen Sie hier: http://www.informatik.hu-berlin.de...

Einfache Programmierung
Oft wird vor einem Verkauf von Zusatzkarten sehr viel versprochen, sodass nach Erhalt des Produkts eine Enttäuschung bei der Installation folgen kann. Damit Ihnen das nicht passiert, wurden hier ein paar der Ursachen untersucht und zusammengestellt.

Sicherlich plagen sich schon viele Anwender und Programmierer mit der schwierigen Einbindung von PC-Karten in eine 32-bit Windows-Applikation herum. Üblicherweise bedient man sich eines DLL-Treibers, der bei der Programmierung der Anwendung angeblich "einfach" nur noch dazugebunden wird. Die Praxis zeigt oft einen weitaus schwierigeren Weg auf. Resultat: Oft klappt nichts, oder nicht so, wie es eben sein sollte. Dies liegt zum Teil daran, dass nicht jede DLL in jeder Betriebssystemumgebung funktioniert. Es gibt beispielsweise DLLs, die nur unter Windows 95/98 oder andere, die nur unter Windows NT4 oder 2000/XP funktionieren. Manche DLLs benötigen zusätzliche System-Treiber wie VXD oder SYS, die im Anwendungsverzeichnis oder im System/Driver-Verzeichnis angelegt sein müssen bzw. zusätzlich in der Windows-Registry eingetragen werden, damit sie überhaupt aus der Anwendung heraus funktionieren.

Auch die Integration einer noch so guten DLL in die eigene Programmiersprache bzw. Anwendung kann auf verschiedenen Rechnern bzw. Konfigurationen unterschiedlich ausfallen und zu erheblichen Schwankungen bezüglich der Port-read/-write Zyklen oder zu anderen Systemkonflikten führen. Um gute Treiber wirklich ohne "Wenn und Aber" dem Produkt beizufügen, bedarf es einer Reihe von mörderischen Tests auf ebenso vielen verschiedenen Rechnern mit unterschiedlichen Konfigurationen, daß es heutzutage schier unmöglich scheint, Fehler bzw. Inkompatibilitäten vermeiden zu können. Die quasi beste Art (schnellster Zugriff) eine I/O-Karte in eine bestehende oder noch zu programmierende Applikation zu integrieren, ist gleichzeitig auch der mühsamste Weg und sollte daher in Assembler vollzogen werden. Da aber zum größten Teil nur noch Hochsprachen wie Delphi, Visual-Basic oder Visual-C++ verwendet werden, ist oftmals die Programmierweise von Assembler unbekannt, auch wenn sich die ASM-Befehle in den meissten neuen Compilern als inline-code integrieren läßt. Doch gerade in dieser, etwas antiquarisch anmutenden Sprache, liegt das größte Potential, wenn es um echte Geschwindigkeit geht.

Tips für eine erfolgreiche I/O-Karten-Programmierung:

- Auswahl einer geeigneten Programmiersprache wie Delphi, MSVC, GNU-C
- direkte Einbindung der Messkarte in die Wandlungsroutine
- Anwendung von asm-, C-, o.a. direkten Port-Befehlen
- anwendungsnah programmieren, klare Programmstruktur
- keine unnötigen Abfragen oder "Dummy-Schleifen"
- übersichtliche Variablengrößen verwenden
- nur Betriebssysteme wählen, die einen direkten Portzugriff erlauben
- oder einen offenen Port-Driver bereitstellen (Beispiel NTP, KLibDrv...)

Betriebssysteme mit direktem I/O-Portzugriff sind beispielsweise:

• CP/M, CP/M 86
• MS-DOS, Free-DOS, Dr.DOS
• Windows 2.x, 3.xx
• Windows 95 / 98 / 98SE / ME
• Linux, Unix

• Windows NT
• Windows 2000
• Windows XP

Meiner Meinung nach, ist NT gegen 9x die bessere Wahl, wenn man bereit ist, einige Eigenheiten und Einschänkungen in mehr Stabilität einzutauschen. Soviel zur Theorie. Wer aber schon mal beide Systeme installiert und ausgiebig getestet hat, weiß anschließend mehr über die Inkompatibilitäten und Abstürze beider Fenster-Oberflächen. Windows 95/98/ME bietet gegenüber NT wesendlich mehr an Geräte-Performance. Installiert man Windows 98 ohne zusätzliche Media-Spielchen und fummelt nicht an der Registry herum, ist 98 genauso sicher wie NT. Windows-NT war immer etwas stabiler als Windows 95/98, und das aus einem ganz einfachen Grund: weil es so gut wie nichts konnte. Microsoft hielt aus NT alle unsicheren Anwendungen (insbesonders USB) herraus, mit denen die Windows 9x Benutzer fortwährend als Betatester mißbraucht wurden. NT konnte kein Plug&Play, NT unterstützte keine Multimediakarten und von Direct-X mit dreidimensionaler Spielerei wollte man in Redmond schon gar nichts wissen. NT unterstützte einfach nur die entscheidenden Komponeten so gut und stabil es ging - das ist alles. Da NT darmals mit seiner neuen 32-bit-Kernel-Struktur als Nachfolger von Windows 95 einzug hielt, glaubten viele Anwender, daß dieses BS absturzsicherer wäre. Dies, so scheint es, ist ein Gerücht das Microsoft selbst verbreitet hat, um Anwender auf die "geschützte Kernelversion" zu ziehen. Mit NT-Systemen lassen sich nunmal höhere Gewinne einfahren als mit Windows 3x/9x. Eine geschickte Marketingstrategie, die sich aber auch noch zu einem Bummerang entwickeln kann, denn anstatt endlich mal eine Bug-freie Version abzuliefern, wartet die Firma aus Redmond lieber mit immer neueren Versionen auf (bzw. Service-Packs), die die Anwender im Glauben auf eine bessere Stabilität fortwährend installiert und anschließend maßlos enttäuscht. Nicht gerade selten tauscht man bei diesen Packs einen alten Bug gegen zwei neue ein - und das traurige Spiel beginnt von Neuem.

Echtzeit-Applikationen unter Windows ?
Nicht nur Software-Entwickler von Echtzeit-Applikationen sehen sich vielfältigsten Herausforderungen gegenübergestellt, wenn sie Windows-basierende Lösungen anbieten sollen, anstatt auf speziell für diesen Zweck entwickelte Betriebssysteme zurückgreifen zu können. Während bei Echtzeit-Betriebssystemen Ereignisse und Interrupts in Prioritäten gegliedert sind und entsprechend diesen auch abgearbeitet werden, reagieren bei Windows NT sogenannte Device-Treiber auf die Interrupts. Obwohl die Multithreading-Technologie die Fähigkeit von Windows, auf Interrupts zu reagieren, weiter verbessert hat, eignet sich das Reagieren auf Interrupts über die Device-Treiber nicht ausreichend gut genug, um damit eine Gewichtung verschiedener Ereignisse vorzunehmen. In der Tat kommt es vor, daß einige Device-Treiber durchaus alle Interrupts sperren, sobald sie zum Zuge kommen. Folglich kann es bei Windows-basierenden Anwendungen immer wieder beobachtet werden, daß die Reaktionszeiten auf bestimmte Ereignisse variieren. Aufgrund dieser Tatsache gehört das Betriebssystem Windows NT / 2000 / XP auch nicht zu den Echtzeit-Betriebssystemen, die ja ein deterministisches Verhalten mit kurzen (< 100us), konstanten Zykluszeiten gewährleisten müssen. Die Schwankungen eines modernen Windows-basierenden Systems in bezug auf die Zykluszeiten eines Regelkreises liegen in der Größenordung von einigen 100 ms. Für die meisten industriellen Automatisierungsapplikationen, wie z.B. eine Temperaturkontrolle, ist eine derartige Unregelmäßigkeit durchaus akzeptabel. Der Begriff "Echtzeit unter NT" muss wohl hierbei nicht als absolutes Maß betrachtet werden, sondern immer innerhalb eines bestimmten Kontextes zu einer realisierenden Anwendung verstanden werden. Für schnelle, redundante Echtzeit-Ereignisse in der Mess.- und Regeltechnik, die oft mehrere kHz beträgt, ist Windows NT aber leider völlig unbrauchbar, da es nicht vorhersehbar ist, wann der Datenstrom von höherprioren threads unterbrochen wird.

Der Multithread im Schwitzkasten
Nun, was passiert denn so alles während eines I/O-Prozesses? In den 32-bit Windows-Betriebssystemen wird das sogenannte 'input output privilege level field' (IOPL) des Flag-Registers benutzt, um die Privilegstufe zu bestimmen, von der aus I/O-Zugriffe erlaubt werden. Das 'I/O permission bitmap' hingegen bestimmt zu quasi jedem I/O-Port, ob ein Zugriff auf dem Port erlaubt wird. Diese Kombination bewirkt üblicherweise den Schutz vor dem unerlaubten Zugriff auf die I/O-Ports von einer Anwendung aus. Für hardwarenahe Befehlssequenzen ist es jedoch in den meisten Fällen notwendig, mit Hilfe von I/O-Port-Befehlen die eingesetzte Slot-Hardware direkt anzusprechen. Die Bedingungen dafür unterscheiden sich jedoch auf den verschiedlichen Windows-Plattformen. Während unter Windows 95, Windows 98 oder ME die meisten Befehle von der Anwendungsebene ausgeführten Zugriffe auf die I/O-Ports des PCs abgefangen und ignoriert oder zeitaufwendig per Software nachgeholt werden, sind sie beispielsweise unter Windows-NT garnicht mehr zulässig. Hierfür war bisher auf jeden Fall ein echter Kernel-Treiber mit dem Mircosoft DDK zu schreiben. Falls der Programmierer es dennoch versucht, wurde das Anwendungsprogramm mit der bekannten 'Schutzverletzung' zwangsweise beendet. Leider sind Windows 95, Windows 98 und Windows NT Multithread-Betriebssysteme, die keine andere Programmierform zulassen. Beispielsweise unterstützt das 'priority based preemptive scheduling', eine prioritätsgesteuerte verdrängende Thread-Umschaltung. Für jeden Prozess wird vom System ein Thread (Faden) erzeugt (primärer Thread), dieser kann dann wiederum weitere Threads generieren. Neben denen der Anwendungsprogramme erzeugt das Betriebssystem u.a. auch eigene Threads, sowohl auf der Anwendungsebene als auch auf der Kernel-Ebene. Alle diese Threads konkurrieren um die Task-Zuteilung von CPU-Rechenzeit, die wie immer nicht üppig für diese Programmiertechnik ausgestattet ist. Wie auch immer. Einige Datenerfassungs- und Steuerungsaufgaben benötigen einen Echtzeit-Betrieb, der bis in einen Bereich von wenigen Mikrosekunden garantiert sein muß. Fazit: Mit allen Windows-Versionen, insbesonders aber NT und 2000/XP können derartig schnelle Regelstrecken keinesfalls realisiert werden.

Nach dem UPDATE - stille
Ein anderes Problem vieler Anwender von Windows NT Workstation betrifft vor allem Anwender, die von Windows 95 umsteigen. Gerade diese Gruppe wird bei Windows NT trotz der großen Anzahl an mitgelieferten Treibern nicht selten ohne passenden Treiber für diverse Hardwarekomponenten wie etwa Sound- und Grafikkarten dastehen. Das gilt vor allem für Spezialkarten und Billigkarten aus Taiwan. Auch Produkte, die überwiegend auf dem europäischen und/oder deutschen Markt Verwendung finden, sind beim Treiber-Lieferumfang von NT stark unterbesetzt.

Problemzone: DIREKTER HARDWAREZUGRIFF
Probleme gibt es immer dann, wenn Anwendungen direkt auf die Hardware zugreifen. Sollte eine Anwendung direkt auf die Hardwareports zugreifen, so gibt es zwei Alternativen. Bei der einen "versteckt" Windows NT den Hardwareport durch den vituellen x86-Modus des Prozessors. Für die Software sieht es dann so aus als ob das betreffende Gerät gar nicht vorhanden sei. Die andere besteht darin, daß der Zugriff durch einen sogenannten VDD (Virtual Device Driver) emuliert wird. Im ersten Fall ist klar, daß das entsprechende Gerät nicht richtig angesprochen wird. Im zweiten Fall ist ein erheblicher Performanceverlust zu verzeichnen. Einige VDDs sind in Windows NT bereits eingebaut. Sie haben beispielsweise Druckerports und serielle Schnittstellen, VGA-Ports und Timer-Bausteine. Modemapplikationen, die direkt auf die COM-Ports zugreifen, senken also die Systemperformance. Der Download einer Datei via Modem verhält sich beispielsweise langsamer oder bricht sogar wegen Time-Out ERROR völlig ab. Wer denkt, er könne das Problem mit dem neuen USB-Port umgehen, irrt. Der USB-Port wird von Windows-NT4 erst garnicht erkannt bzw. unterstützt. Erst das neuere Windows 2000 und XP ist dazu in der Lage.

Entwicklungswerkzeuge
Wer für ein Betriebssystem Anwendungen programmieren will, ist auf entsprechende Entwicklungswerkzeuge angewiesen. Der "Vater aller Windows-Entwicklungswerkzeuge" ist das Software Development Kit (SDK). Es besteht aus einer Reihe von Tools, wie zum Beispiel einem Resource Editor, einem Debugger und Zusatzbibliotheken, vor allem aber aus einer umfangreichen API-Dokumentation. Programmieren kann man mit dem SDK alleine aber noch lange nicht. Benötigt wird weiterhin eine Programmiersprache wie etwa C++ und sehr viel Zeit.

Arbeiten mit "C++"
Die mit Abstand wichtigste Programmiersprache für Windows NT ist C++ in Kombination mit der von Microsoft entwickelten Klassenbibliothek MFC, die inzwischen von jedem namhaften Compiler-Hersteller lizensiert wurde. Schätzungsweise mehr als 90 Prozent aller kommerziellen Windows-Programme dürften in C++ entwickelt worden sein. Auch Windows NT selbst besteht aus mehreren Millionen Zeilen C++ Quell-Code. Die bekanntesten C++ Compiler sind Visual C++ von Microsoft und Borland C++. Da bedingt durch die rasante Entwicklung im Windows- und Internet-Bereich in immer kürzeren Abständen neue Releases fällig werden, kann man Visual C++ bereits im Jahresabonnement erwerben, die aktuelle Versionsnummer spielt daher eine immer geringere Rolle, da sowieso jede Version immer wieder Fehler aufzeigt.

Resümee
C++ ist zwar sehr leistungsfähig, doch mit einem kleinen Nachteil behaftet: Es ist recht schwer zu erlernen - und die, die es können verhalten sich sehr still. In der Regel benötigt man mindestens 3...4 Jahre, um wirklich zur Gruppe der (halbwegs-) erfahrenen C++ Programmierer zu zählen. Zwar verfügt C++ (wie schon der Vorgänger C) nur über einen kleinen Befehlsvorrat,  die Schwierigkeit besteht jedoch darin, die Möglichkeiten der C++ Sprachelemente zu verstehen und sich an die recht kryptische, objektorientierte Syntax zu gewöhnen. Zu wissen, daß ein Sternchen an der falschen Stelle eines Befehls dessen Sinn komplett verändern und über Erfolg oder Absturz der Programme (samt Windows) entscheideiden kann,  ist nichts für schwache Nerven und hat nicht unwesentlich zum schlechten Ruf von C++ beigetragen.

Hier noch ein Link zum Thema:
http://www.lot-germany.com/magazin/unix-nt.htm

Die gute Nachricht  gleich vorweg : Unter Linux lassen sich generelle Hardwareinstallationen wie I/O-Karten, A/D- und D/A-Messkarten ganz einfach und ohne Probleme mit GNU-C programmieren.

Linux gehört heutzutage ins Portfolio und ist somit "State-of-the-Art". Jedoch ist aller Anfang schwer, so auch bei diesem umfangreichen Betriebssystem. Seit den ersten Anfängen hat Linux einen weiten Weg zurückgelegt. Anfangs ein reines Spezialisten-System, schlich es sich langsam, aber stetig in das Bewußtsein der User. Selbst im kommerziellen Einsatz scheint Linux sich als Alternative immer mehr zu etablieren und nicht zuletzt bei Lotus-Notes, wo AOL mit Lotus kooperieren will. Hier werden hohe Summen investiert, um neue Suchmaschinen bzw. Datenbanken unter Notes auf Linux zu portieren. Linux ist schon seit langem eine echte Alternative zu herkömmlichen Betriebssystemen. Erst recht zu Windows-NT. Grund dafür ist nicht nur der stabile und flexible Kern allein. Vielmehr geben die kompletten Systeme, sogenannte Distributionen, den Anwendern jede Menge Tools und zum Teil mächtige Applikationen mit an die Hand. Die Grundlage für die meisten Linux-Entwicklungen bildet die GNU General Public Licence, eine Software-Lizenz, die sicherstellt, daß jeder den Quellcode weiterentwickeln darf und daß die Arbeit der Autoren auch gewürdigt wird. Aufgrund des freien Copyrights gibt es in vielen Bereichen mehrere Programme, die bestimmte Aufgaben erfüllen, so daß der Anwender und Programmierer hier nicht einmal auf bestimmte Programme beschränkt sind. Mit X11 und KDE sind professionelle, grafische Oberflächen in den Paketen bereits enthalten. Zusammen mit der vom Hersteller der Distribution beigelegten Software wird das System zum wahren Multitalent für alle PC-Anwender und Programmierer.

Übrigens, wenn Sie von Windows auf Linux umsteigen wollen, sollte auf dem PC zunächst eine Linux-Testinstallation parallel zu Windows 95/98 laufen (am besten auf einer 2.ten Back-Up Platte). So können Sie sich in das neue Betriebssystem einarbeiten, sich von seiner Stabilität und Leistungsfähigkeit überzeugen und haben gleichzeitig noch das vertraute System zur Verfügung. Voraussetzung dafür sind zwei freie Partitionen auf der Festplatte: eine für das Linux-System selbst, eine weitere (kleinere) für die Linux-Swap-Datei. Sie können Linux dann entweder von DOS aus über das Programm LOADLIN.EXE oder über den Linux-eigenen Bootmanager Lilo (Linux Loader) starten. Mit Lilo erhalten Sie beim PC-Start ein Menü, um zwischen Windows und Linux zu wählen. Von Linux aus können Sie auf Windows-95/98- (FAT, FAT32) oder NT-Partitionen (NTFS - nur lesend) zugreifen und die dort abgelegten Daten benutzen. Wenn Sie bislang mit Microsoft Office gearbeitet haben, macht es keine Schwierigkeit, die damit erstellten Dokumente weiterzuverwenden. Die für Linux verfügbaren Office-Pakete StarOffice, WordPerfect und Applixware besitzen Importfilter für alle wichtigen MS-Dokumentformate. Mit dem Wine-Emulator (Gratis-Download unter http://www.winehq.com, rund 2 MB) läßt sich sogar die eine oder anderen Windows-Software unter Linux zum Laufen bringen.

Zurück zur Mess-Hardware. Es gibt zum Glück keine getarnte Zugriffmechanissmen, wie sie beispielsweise bei MS-Windows alltäglich sind. Im Gegenteil. Linux bzw. Linux-Anwendungen sind eben alle offen zugängig und zudem oft noch kostenlos. Vergessen Sie die umständliche Programmierung, die Ihnen andere MS-Betriebssysteme abverlangen. Der Hardwarezugriff ist dermaßen einfach, dass jeder ANSI-C Programmierer sofort Erfolg hat. Mit Befehlen wie ioperm und iopl kann die I/O-Port-Welt geöffnet werden, ohne daß zusätzliche device-Treiber von Nöten sind, oder nichteinsehbare, kryptische Includes dazugebunden werden müssen, die angeblich die Programmierung vereinfachen sollen - aber oft nur blauen Dunst vorgaukeln.

Die Programmierweise ist ähnlich wie mit einem ANSI-C-Compiler unter DOS und lässt aber neben 8-bit-Zugriffen auch 16-bit und 32-bit Zugriffe zu. Um in den direkten Genuß der Portprogrammierung zu kommen, wird lediglich ein offenes Include <io.h> aus dem Verzeichnis /asm dazugebunden und schon stehen die Befehle outb(wert,adresse) und inb(adresse) zur Verfügung. Die Compilierung kann mit XWPE unter KDE oder mit gcc auf der Linux-Konsole bash erfolgen. Auch andere C-Compiler können den Code compilieren und haben keinerlei Verständigungsprobleme, wie sie bei anderen Betriebssystemen geradezu üblich sind. Programmier-Einsteigern hingegen, sollte ein Komplettpaket wie Debian oder S.u.S.E. ans Herz gelegt werden. Beispielsweise sind ab S.u.S.E. Paket 6.2 alle notwendigen Programme für die erfolgreiche Compilierung des hardwarenahen C-Codes enthalten. Nach der ca. 45-minütigen Installation von S.u.S.E.s Linux, kann bereits das erste C-Programm eingegeben und compiliert werden.  Natürlich ist die Eingabe unter KDE wesentlich angenehmer als mit einem einfachen Emac-Texteditor auf Konsolenebene, macht in der Sache aber das Gleiche.

Ideal ist die Multitasking-Fähigkeit von Linux, da neben der stilvollen Eingabe unter KDE auch ein bash-Fenster auf dem Desktop geöffnet werden kann. So ist es möglich den Source im Fenster abzuspeichern, um ihn im bash-Fenster anschließend manuell mit gcc zu compilieren. Demnach verpasst man einerseits keine Compilerfehler und ist andererseits sofort in der Lage, das lauffähige Programm in seiner realen Umgebung auszutesten. Bei einem Absturz des Testprogramms kann das bash-Fenster auf der KDE-Oberfläche einfach manuell geschlossen werden, um es anschließend wieder aufzurufen. Linux und KDE müssen dazu nichteinmal verlassen werden. Die Oberfläche bleibt weiterhin stabil und kann der nächsten Eingabe zur Abänderung des Sourcecodes dienen. Hiermit  werden die Stärken von Linux ganz klar und deutlich.

Kurz um:
C programmieren unter Linux macht wieder Spass !

Gerade ältere Programmierer, die wie ich schon über 20 Jahre lang bei der Sache sind, werden sich hier wieder fast wie zuhause fühlen, denn unter Linux kommen so manche Abfolgen und Befehlsstrukturen wie sie früher mit CPM oder später unter DOS alltäglich waren, wieder zum Vorschein, gleichwohl unter der Premisse, dass Linux von Unix herrührt und doch noch eine Menge zu lernen gilt.

Die Entwicklung und Verbreitung von Linux ist einzigartig. Seit 1991 wird Linux von einer ungezählten Schar Computer-Freaks in der ganzen Welt weiterentwickelt. Das ganze passierte überwiegend in der Freizeit, nur so zum Spaß und gänzlich ohne Bezahlung. Nicht einmal der Riese Microsoft verfügt über eine solche Anzahl an motivierten und begabten Betriebssystem-Entwicklern. Fehler im System werden über das Internet sofort an den jeweiligen Programmierer weitergegeben und beseitigt. Dies erklärt die schnelle Weiterentwicklung und letztlich die Stabilität des Systems, da alle User ein eigenes Interesse daran haben, daß das System fortwährend verbessert wird. Der Betriebssystem-Kernel, der dann jeweils von Linus Thorvald freigegeben wird, läuft somit immer sehr stabil.

Somit ist es nicht verwunderlich, dass es an eine Zumutung grenzt, wieviele Treiber heute ein modernes Produkt beinhalten muss, dass  beispielsweise unter Microsoft eingesetzt werden soll, um allen Kundenwünschen einigermaßen gerecht zu werden. Dies hat mit Programmierfaulheit oder Arroganz nichts zu tun, denn es ist einfach schlichtweg zu viel und oft auch für den Hersteller nicht erkennbar, welche Treiber der Anwender vorraussetzt bzw. wirklich benötigt. Und nicht zu unterschätzen gilt der notwendige Aufwand, um vom Prototypenzustand zu einer robusten, serienreifen Gesamtlösung zu gelangen. Alles das kostet jedem Hersteller Entwicklungszeit und Resourcen (bsp. Mitarbeiter und Ausbildung, neue Compiler, MSDN-Support, schnellere und aktuelle Test-Rechner, Compliance-Tests, Dokumentationserstellung, Langzeituntersuchungen, Installationstest,  Web-Seiten-Support...). Die hierbei anfallenden Kosten werden auf das Produkt später wieder aufgeschlagen, um die damit verbundenen Vorleistungen bzw. Entstehungskosten wieder einzufahren. Die Hardware selbst fällt kostenmäßig somit immer weniger ins Gewicht, wenn es darum geht ein neues Produkt marktreif einzuführen. Momentan liegt sie im Vergleich zur Softwareentwicklung etwa gleich auf. Die Kostenschere spreitzt sich aber um so mehr, wenn das Produkt kaum einen Absatz am Massenmarkt erhält oder nur für eine kurze Dauer am Markt besteht.

Da wir die Software-Vorlieben unserer Anwender nicht im Einzelnen kennen, werden üblicherweise Delphi-5 Beispielprogramme zu unseren Produkten als Source-Code mitgeliefert. Ähnlichkeiten zwischen Delphi mit C++ und Visual-BASIC sind sofort erkennbar und für den erfahrenen Programmierer kein Problem, den Source in seine bevorzugte Programmiersprache umzuwandeln, sofern nicht bereits Beispiele für diese Programmiersprachen bereit stehen. Da es sich sowieso oft nur um ein paar Zeilen Treibersource handelt ist die Sache recht einfach: Komplexe Anwendungsprogramme werden in der Regel nur um diese Zeilen ergänzt, um die jeweilige I/O-Karte in das System einzubinden. Dazu ist im Normalfall (unter Windows 9x) auch keine SYS, DLL oder anderweitige Thread-Programmierung erforderlich und für Windows-NT, 2000 oder XP bieten wir bereits Device-Treiber an, um die benötigten I/O-Resourcen automatisch freizuschalten (siehe NTP und HWT mit klibdrv). Weiterhin bieten wir Ihnen zunehmend mehr Unterstützung hinsichtlich der Direktprogrammierung in Visual-BASIC und Delphi-5 bzw. als DLL- und SYS-Treiber für alle neuen Windows-Betriebssysteme an. Bitte fragen Sie uns möglichst vor dem Kauf, ob wir einen entsprechenden Treiber und/oder Source-Code für Ihren Vorzugs-Compiler anbieten können, denn wir bieten nicht für jedes Produkt das ganze Sortiment zu allen möglichen Programmiersprachen an.