Meine erste verkaufte Anwendung

Was immer wieder zu verwunderten Nachfragen bei Personalern führte, war ein Eintrag in meinem Lebenslauf, der wie folgt aussah:

Jun. 2002 – Erste verkaufte Anwendung, erstellt mit Borland Delphi 6

Datenbankanbindung (dBase IV) und –Web-Upload für Sage „GS-Auftrag“ als Schnittstelle zu einem PHP-Webshop für ein mittelständisches bayerisches Unternehmen auf dem Gebiet der Hydraulik- und Forsttechnik.

Inzwischen habe ich mich entschlossen, diesen Eintrag ersatzlos zu streichen, möchte über diese ungewöhnliche Geschichte dennoch bloggen.

2002 besuchte ich die gymnasiale Mittelstufe und hatte mich (blöderweise) für die Differenzierungsfächer Biologie und Chemie entschieden. Bereits damals lag mein Interessensschwerpunkt zwar stärker auf der Informatik. Jedoch befürchtete ich, dass die Mathematik, die die Informatik zwangsweise voraussetzt, mir zuviel abverlangen könnte, zumal ich kein guter Mathematikschüler war. Mein damaliger Beratungslehrer, der in späteren Jahren auch mein Informatiklehrer und eine sehr prägende Figur wurde, empfahl mir daher „Bio-Chemie-Diff“.

Mein Herz schlug in den Jahren 2001 und 2002, wie oben erwähnt, unweigerlich für die Programmierung. Ich hatte den Ehrgeiz (und die Zeit!) so viele Programmiersprachen wie möglich zu lernen. Also begann ich mit Pascal, später Delphi, lernte parallel Perl und JavaScript. Später Visual Basic und C#. Meiner Kreativität waren damals kaum Grenzen gesetzt. Verstand ich z.B. nicht wie eine Datenbank funktionierte, entwickelte ich einfach selber eine. Zwar eine sehr primitive und fehleranfällige auf Textdateibasis. Aber ich lernte viele wichtige Lektionen durch bloßes Ausprobieren, zum Beispiel warum Datenbanken heute so konzipiert sind, wie sie sind. Dasselbe mit Socketverbindungen, Netzwerkprotokollen (die ich anfangs händisch implementierte), Stringverarbeitung, Betriebssystemzugriffen, WebServices (SOAP) usw.

Borland Delphi war ein mächtiges Produkt. Es bot „out-of-the-box“ die Möglichkeit Windowsanwendungen mit ansprechender GUI in wenigen Handgriffen zu entwickeln. Im Gegensatz zu dem damaligen Konkurrenten Visual Basic, wurde kein Runtime Environment, also Zusatzsoftware, die zusätzlich auf dem Zielcomputer installiert werden musste, benötigt. Anwendungen konnten als einzelne .EXE-Datei ausgeliefert werden und funktionierten auf nahezu jeder Windowsversion!

Im Juni 2002 befand ich mich mit meinen Eltern im Sommerurlaub in Oberbayern. Da wir dort regelmäßig Urlaub machten, wussten unsere Freunde vor Ort, dass ich ein kleiner Geek war. Wie der Zufall es so wollte, führte einer dieser Freunde gerade einen neuen Webshop auf PHP-Basis ein. Dort sollten Kunden seinen Warenbestand, vornehmlich Ersatzteile für Hydraulik- und Forsttechnik, einsehen und kaufen können. Man diskutierte am Tisch, wie man denn den Datenbestand seiner Auftrags- und Lagerverwaltung, der sich im Intranet des Unternehmens befand, mit dem Webshop synchronisieren sollte.

Der Blick fiel auf mich. Ich erklärte, dass ich in Delphi die Möglichkeit habe, Dateien mittels Dateitransfer (FTP) auf einen entfernten Webserver hochzuladen. Um den Warenbestand korrekt abzubilden, müsste ich vier oder fünf Datenbanktabellen anzapfen, den Inhalt konvertieren, in eine CSV-Datei schreiben und hochladen.

Meine erste verkaufte Anwendung machte also folgendes: Sie öffnete jede Nacht die vorgegebenen dateibasierten Datenbanktabellen (dBase IV) – ich erinnere mich heute nur noch an die sog. „Rabattmatrix“ – konvertierte den Zeichensatz von ANSI zu ASCII, schrieb den Inhalt sequentiell in CSV-Dateien und pumpte diese dann zum FTP-Server des Webshops. Nachdem der Upload vollständig war, rief sie noch eine URL auf, die dem Webshop mitteilte, dass er nun mit dem Import beginnen kann.

Nach drei veranschlagten, aber fünf benötigten Tagen war die Anwendung fertig: Schlank, kompakt und funktional. Da ich damals den Windows-Scheduler noch nicht kannte, entwickelte ich selbst einen rudimentären Scheduler, der periodisch prüfte, ob die eingestellte Uhrzeit bereits erreicht wurde. Die FTP-Logindaten wurden verschlüsselt in einer INI-Datei hinterlegt. Damals wusste ich eben auch noch nicht, dass das FTP-Protokoll in seiner ursprünglichen Art die Logindaten unverschlüsselt überträgt. FTPS war mir gänzlich fremd. Aus heutiger Sicht hätte ich die Logindaten also ebenso gut unverschlüsselt in die INI-Datei schreiben können, da ein Angreifer die Loginsequenz nur hätte mitprotokollieren müssen.

Ironischerweise war das, was ich 2002 programmiert habe, ungefähr das, womit ich heute meine Brötchen verdiene: Datenintegration und -migration. Natürlich verwende ich heute bessere Werkzeuge (ETL-Tools, SQL-Datenbanken, Reporttools), aber im Grundsatz ist das schon sehr ähnlich.

Die Anwendung wurde irgendwann 2006 oder 2007 abgeschaltet, als das Unternehmen eine Softwarelösung kaufte, die den Warenbestand ohnehin „in der Cloud“ hielt.

SMSAlerter 0.2 USV- und Akkualarm via SMS

2008 schrieb ich eine Anwendung die einem Windows Serveradministrator den Versand von SMS bei einem niedrigen USV-Akkustand ermöglichte. Sie ist denkbar einfach aufgebaut: die USV muss als Akku im System installiert sein, dies ist ein Standard und bei allen mir bekannten Herstellern der Fall. Ebenfalls muss ein AT-Hayes kompatibles GSM-Modem (zB ein Handy, verbunden via USB oder COM) netzfähig sein – eine UMTS-Karte ist ebenfalls einsatzfähig.

Der SMSAlerter 0.2 prüft regelmäßig den Ladezustand der Akkus und sendet bei eintreffen eines definierten Zustandes eine SMS über das Handy an einen Empfänger.

Die Konfiguration geschieht folgendermaßen:
1. Anwendung öffnen
2. die Alarmierunghemmschwelle auswählen (Hoher, niedriger oder kritischer Ladezustand)
2. den COM-Port auswählen (COM 1 bis 5)
3. den Empfänger eintragen
4. die Anwendung schließen

Beim Schließen der Anwendung werden die Einstellungen übernommen und sind beim nächsten Programmstart aktiv. Der GSM-Status sollte: „im Netz eingebucht“ sein.

Um die Anwendung unsichtbar zu machen, klicken Sie mit der rechten Maustaste auf das Symbol in der Taskbar. (Links: Öffnen, Rechts: Verstecken).

Getestete Betriebssysteme: Windows XP; Windows Server 2003; Windows Server 2008; Windows 7 x64

Download: SMSAlerter 0.2

Großhochzeit: C#, Delphi, Assembler und COM

Ein Feature das mit großer Wahrscheinlichkeit in zukünftigen Versionen von .NET noch implementiert werden wird, ist (managed/inline-) Assembler in seine Projekte einzubinden. In einigen Hochsprachen mit „echtem“ Compiler ist dies bereits seit vielen Jahren Standard: C++, TurboPascal, FreePascal, Delphi, freeBASIC, usw.

Zudem findet man in alten mächtigen Source-Code-Archiven oft bis zur Perversion optimierte Algorithmen, die der Autor bereits in Inline-ASM implementiert hat. Es wäre doch zu schade diese nicht weiter nutzen zu können…

Folgenden Code fand ich im SwissDelphiCenter:
http://www.swissdelphicenter.ch/de/showcode.php?id=2049
(Ein Instring-Algorithmus von Vanja Fuckar, 100% inline-ASM)

Delphi erlaubt es mit sehr wenig Aufwand einen Quelltext direkt als COM-Programmbibliothek zu kompilieren. Heraus kommt eine dll-Datei (hier: „InString_dll.dll“) die ich nun in mein .NET-Projekt einbinde mittels:


[System.Runtime.InteropServices.DllImport("InString_dll.dll", CallingConvention = System.Runtime.InteropServices.CallingConvention.StdCall, CharSet = System.Runtime.InteropServices.CharSet.Unicode)]
private static extern int InString(int StartPosition, string Source, string Pattern);

Aufgerufen wird diese externe statische Funktion wie üblich z.B. mit:


Console.WriteLine(InString(0, "Testautotesttesttest", "auto").ToString());

Einen Haken hat das (vor)kompilieren von Inline-Assembler: Es gibt keine Gewährleistung, dass diese Programmbibliothek auch auf anderen Prozessorarchitekturen bzw. -familien ausgeführt werden kann, als auf der sie kompiliert wurde.
Exemplarisch habe ich dafür die .NET-Anwendung auf einem AMD Athlon X2 64bit ausgeführt: der JIT-Debugger spuckt eine Exception aus, die mir eine ungültige Typenumwandlung bestätigt.
Auf einem Intel Pentium 4 HT wiederum lief der Quelltext einwandfrei.
Anmerkung dazu: Die Programmbibliothek habe ich auf einer Intel Pentium M kompiliert, die bekannterweise nicht aus der Familie der NetBurst-Architekturen stammt.

Nachtrag: Auf einem Pentium Xeon (NetBurst) lief die Anwendung ebenfalls einwandfrei.

Delphi: Winamp-Titel auslesen

Winamp-Titel in Delphi auslesen
Winamp-Titel in Delphi auslesen

Um mit Delphi den aktuellen Winamp-Titel auszulesen benötigt man nur eine kleine Funktion. Der Zugriff erfolgt über die WinAPI.


function GetWinampFilename(): String;
var
    hwndWinamp, ProcessHandle: THandle;
    dat2: array[0..500] of Char;
    temp, MPointer: Cardinal;
begin
  //Bitte nicht wundern, die Fensterbezeichnung ist korrekt und funktioniert bei allen Winamp-Versionen:
  hwndWinamp:=FindWindow('Winamp v1.x',nil);
  MPointer:= SendMessage(hwndWinamp,WM_USER,SendMessage(hwndWinamp,WM_USER,0 , 125), 212);
  GetWindowThreadProcessId(hwndWinamp,ProcessHandle);
  hwndWinamp:= OpenProcess(PROCESS_ALL_ACCESS,False,ProcessHandle);
  ReadProcessMemory(hwndWinamp, Pointer(MPointer), @dat2,500,temp);
  CloseHandle(hwndWinamp);
  Result:= String(dat2);
end;

Parse/Split in Delphi 6

Ein großes Manko an Delphi (bis zur .NET-isierung) war/ist eine fehlende Funktion für das zuverlässige und schnelle Parsing von Strings. Folgende Funktion begleitet mich bereits seit 2002 durch fast alle Delphi-Projekte:


function Parse(Char, S: string; Count: Integer): string;
var
  I: Integer;
  T: string;
begin
  if S[Length(S)] <> Char then
    S := S + Char;
  for I := 1 to Count do
  begin
    T := Copy(S, 0, Pos(Char, S) - 1);
    S := Copy(S, Pos(Char, S) + 1, Length(S));
  end;
  Result := T;
end;