- Wenn Du den Fehler nach 30 Minuten nicht gefunden hast, ist es wahrscheinlich nicht Dein Fehler, sondern ein Fehler in der Bibliothek oder im Compiler.
- -- Azundris' Grundregel des Debuggings
Achtung jetzt kommt mal wieder etwas aus dem Programmiereralltag. Ich hacke seit einiger Zeit an einem Programm rum, in dem ich auf die
Qt-4 Bibliothek aufsetze. Das ermöglicht es mir, ohne viel Aufwand dieses Programm sowohl unter Linux als auch unter Windows laufen zu lassen. So zumindest in der Theorie. In der Praxis habe ich circa einen Monat gebraucht, um drei Fehler zu finden, die zwar unter Windows, aber nicht unter Linux auftreten.
Der erste Bug, mit dem ich zu kämpfen hatte war, das eine selbstgestrickte Routine zum kopieren von Dateien nicht funktioniert hat. Ich habe dabei nicht auf Qt aufgesetzt, sondern direkt mit den POSIX Funktionen open, read, write und close gearbeitet. Diese werden in meinem Fall durch das
MinGW System zur Verfügung gestellt, welches von der Qt/Open Souce für Windows verwendet wird. Leider kam so nur Datenmüll auf der Zielseite an. Eine nähere Analyse dieses Datenmülls zeigte, dass Anscheinend die Daten im Text Modus von Windows kopiert wurden. Wieso das denn? POSIX kennt so einen Schwachsinn gar nicht. Beim Suchen in den Headerdateien von MinGW wurde ich dann in fcntl.h fündig:
/\* NOTE: Text is the default even if the given _O_TEXT bit is not on. \*/
#define _O_TEXT 0x4000 /\* CR-LF in file becomes LF in memory. \*/
#define _O_BINARY 0x8000 /\* Input and output is not translated. \*/
#define _O_RAW _O_BINARY
Bitte? Da baut jemand einen Layer mit dem sich POSIX/UNIX Programme einfacher unter Windows kompilieren lassen sollen, und nimmt dann als Standardwert die Windowswelt?
Der zweite Bug war dem ersten sehr ähnlich, nur dass eine Bibliothek, die ich zum Ändern von mp3-Tags wie Interpret, Titel, Album, etc. benutze ebenfalls nicht binär arbeitete. Der Fehler war schnell gefunden, auch wenn er doch etwas anders gelagert war, als der erste: der Autor arbeitete mit fopen, fread, fwrite und fclose. Bei denen muss der Binärmodus durch Erweiten eines Parameters explizit eingeschaltet werden. Nur dass Unix und Linux den Textmodus und Binärmodus gleich behandeln, und somit auch im Textmodus funktionieren. Das habe ich dem Autor mal in einer kurzen E-Mail geschrieben, und bekommt als Antwort gleich drei Schelten:
- gehört ein solcher Hinweis in die Entwicklermailingliste
- wird Windows offiziell gar nicht unterstützt
- ist der Fix schon in aktuellen Subversion-Version enthalten, und wird beim nächsten Release mit ausgeliefert
Trotz allem war die Mail sehr freundlich geschrieben. Und ja, alle Fehler lagen bei mir. Ich hätte natürlich vorher mir die aktuelle Entwicklerversion holen können, hätte im Netz nach dem Weg suchen können wie ich denn offiziell Bugreports einzuschicken habe. Und nein, ich werde ich auch beim nächsten Mal nicht tun, sondern weiterhin den "kleinen Dienstweg" wählen.
Der dritte Bug war aber das größte Problem von allen: ich setze massiv die
SQLite Datenbank für die interne Verwaltung der Daten ein. Unter Linux funktionierte alles Einwandfrei, unter Windows gab es Fehlermeldungen wie "Datenbank nicht vorhanden". Den genauen Grund konnte - beziehungsweise wollte - ich nicht ausmachen, habe aber eine Abhilfe gefunden: die Datenbank, welche mit Qt ausgeliefert wird ist in der Version 3.3.6, aktuell ist die Version 3.3.12. Also habe ich mit etwas Aufwand die aktuelle Version der Datenbank in Qt integriert und siehe da, alle Probleme waren beseitigt. Allerdings befürchte ich, dass mein Bugreport bei Trolltech, dem Hersteller von Qt verpuffen wird. Die gepatchte Version der Qt Bibliothek gibt es auf Anfrage bei mir, Open Source verpflichtet schließlich. ;-)
Kommentare