Hallo liebe Leute, bisher habe ich Windows-Anwendungen (professionell) mit Visual C und WIN-API programmiert. Mikrocontroller-Programme habe ich immer in Assembler geschrieben, bis ich vor kurzem den C18 für mich entdeckt habe. Es ist eine wahre Freude, wie einfach und logisch die Bibliotheken aufgebaut sind. Mit 1 Statement wird die serielle Verbindung geöffnet und ist danach bereit für die Übertragung. Sehe ich mir hingegen das gleiche in der WIN-API an, wird mir schwindelig. Erstmal nen Handle, Dann ne Funktion und als Parameter nen Pointer auf Struct, das natürlich zuvor sauber gefüllt werden muss. Und das Ganze bis zum Erbrechen, bis man endlich mal nach draussen kommt. Wieso muss das denn alles so komplizier gehen. Müssen Funktionen wirklich 10 und mehr Parameter haben? Gruß Christian
> Wieso muss das denn alles so komplizier gehen. Müssen Funktionen > wirklich 10 und mehr Parameter haben? Nein, müssen sie nicht. In VB ist das wieder ganz einfach gelöst.
Gerade bei der seriellen Schnittstelle verstehe ich das auch nicht ganz. Die direkte Initialisierung des UART-Bausteins würde deutlich weniger Code-Zeilen in Anspruch nehmen. Klar, die OS-Hersteller versuchen natürlich, ein hardwareunabhängiges API zu schaffen, dabei aber trotzdem sämtliche Features der Hardware dem Programmierer verfügbar zu machen. Idealer aus Programmierersicht wäre sicher ein API, bei dem mit einer Funktion mit wenigen Argumenten die häufig benutzten Schnittstellen- parameter (Baudrate, Parität, Stoppbits) eingestellt werden. Für den Rest sollten sinnvolle Defaultwerte vorhanden sein, die bei Bedarf über weitere Funktionen verändert werden können. Aber Betriebssystem-APIs sind nicht primär auf einfache Benutzung ausgelegt. Da spielen andere Aspekte eine Rolle, wi z. B. Abwärts- kompatibilität zu irgendwelchen Uraltversionen oder leichte Erweiterbarkeit ohne Kompatibilitätsprobleme. Immerhin sind es für die meisten Programmiersprachen und Betriebs- systeme programmiererfreundliche Wrapperbibliotheken zu finden. Dann hat man es so leicht wie in VB. Das Problem ist, dass man in der Zeit, in der man diese Bibliotheken sucht, meist auch die direkte Variante hinbekommt.
MS ist aber auch bekannt für aufgeblasene APIs. Das Starten eines neuen Programms gehört wohl mit zu den größten Horrorgeschichten. Im Vergleich dazu braucht das Unix-API zwar zwei separate Funktionsaufrufe (fork und exec), aber dafür konzentrieren diese sich auf das Wesentliche. Werden zusätzliche Dinge benötigt (wie z. B. das Erzeugen einer Pipe), dann kann man diese dazwischen schieben.
>Das Starten eines neuen Programms gehört wohl mit zu den größten >Horrorgeschichten. ? Result := WinExec(ExeName, SW_ShowNormal); oder besser ShellExecute(MainForm.Handle, 'open', <Programmdatei>, <Aufrufparameter>, '', SW_SHOWNORMAL); Fertig. Natürlich kann man das beliebig kompliziert machen, vor allem wenn der aufrufende Prozess auf das Ende des aufgerufenen Prozesses warten soll. Aber generell ist das Starten eines Programms trivial.
Ich hatte das als Funktion mit 9 oder 10 Parametern in Erinnerung. Ist aber schon lange her, dass ich mir das zum letzten Mal angeguckt habe. Damit sind wir natürlich beim nächsten Punkt: es gibt für jede Aufgabe x verschiedene APIs (x: Anzahl der Programmierer, die damit jemals beschäftigt waren :-o).
>Ich hatte das als Funktion mit 9 oder 10 Parametern in Erinnerung.
Jetzt wo du es sagst, es gibt da noch CreateProcess() und diese Funktion
erwartet tatsächlich 10 Parameter :)
> ShellExecute(MainForm.Handle, 'open', <Programmdatei>, > <Aufrufparameter>, '', SW_SHOWNORMAL); Naja, um ein Programm in einer Shell zu starten, gibt es ja auch noch
1 | int system(const char *string); |
aus der C-Standardbibliothek. Der Aufruf ist maximal einfach und sollte in jedem Betriebssystem funktionieren. Aber es ging ja ursprünglich um das OS-API für die serielle Schnittstelle. Und das ist sogar unter Unix/Linux ziemlich kompliziert.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.