Grenze zwischen System- und Anwendungsprogrammierung?

[Gast]

Hi Leute,

wo genau ist eigentlich die Grenze zu ziehen zwischen Anwendungsprogrammierung und Systemprogrammierung? Ich habe mal bei Wikipedia geschaut:

http://de.wikipedia.org/wiki/Systemprogrammierung

aber was dort steht vergrößert meine Verwirrung nur. Ich nehme an, wenn man Treiber programmiert, wird das defintiv in die Kategorie Systemprogrammierung fallen. Aber was ist z.B. wenn ich ein Programm schreibe, das auf den Comport zugreift und dazu (unter Windows) die Funktionen der Win32-API wie CreateFile, WriteFile, ReadFile,... nutzt. Geht das dann auch schon in den Bereich Systemprogrammierung? Die API-Funktionen müssen dann ja immer noch auf den Comport-Treiber zurückgreifen, der eine Schicht zwischen der API und der Hardware bildet...

Dann ist in dem Wikipedia-Artikel noch von Datenbanken die Rede. Da steht daß Datenbanken einen schnellen Zugriff auf Hardware-Ressourcen benötigen. Warum eigentlich? Wegen dem Lesen und Schreiben der Daten vom / auf den Massenpeicher? Ich habe schon öfters gehört, daß Datenbanken Treiber benötigen würden. Z.B installiert Delphi eine BDE-Verwaltung, in der es einen TreeView mit dem Einträgen wie Konfiguration -> Treiber -> ODBC gibt. Ich habe mich immer gefragt, was eine Datenbank wohl mit einem Treiber tun soll. Ist das vielleicht wegen diesem schnellen Hardware-Zugriff? Oder hat der Begriff "Treiber" hier eine ganz andere Bedeutung?

[bulla]

Ein Treiber ist dafür da, zwischen 2 Sachen zu vermitteln.

Beispiel: Grafikkartentreiber & DirectX
Der Grakahersteller erstellt einen Treiber, da nur er die Eigenschaften der Hardware kennt (Ansteuerung der Register, Shader usw.). Wenn das Betriebssystem z.B. die Funktionen drawBlackScreen(), drawWhiteScreen() und createShaderEffect() besitzt, muss der Treiber diese Anweisungen zur Graka lenken. Wenn die Graka z.B. createShaderEffect() nicht kann, da sie zu alt ist, gibts einen Fehler. Im Treiber wird dies umgesetzt bzw. abgefangen.
Ein Treiber muss somit die Funktionen beinhalten, die ein Betriebssystem verarbeiten kann (deswegen gibts nicht einen einzelnen Treiber für alle Linux/Win/etc.-Versionen). DirectX erweitert diesen Funktionsumfang durch neuere Versionen regelmässig, weswegen die Grakahersteller aktuellere Versionen nachschieben müssen, um kompatibel zu bleiben. Dem Progger ist dies egal, da er sich nur mit der Win/DirectX-Doku herumschlagen muss.

Bei Datenbanken verhält es sich ähnlich, nur sind diese keine Hardware, sondern Software. Wenn man eine Datenbank installiert, will man mit dieser ja ebenfalls kommunizieren können, diesmal auf Softwareebene. Der Datenbanktreiber (ODBC, JDBC usw.) muss somit ebenfalls speziell an die jeweilige Version angepasst sein, damit alle Kommandos verarbeitet werden können, genauso wie beim Graka-Treiber.
Willst du aus Java heraus eine Datenbank ansprechen, musst du somit den spezifischen Datenbank-Treiber reinladen, der die Anfrage zur Datenbank mit den korrekten Methodenaufrufen weiterleitet. Der Java-Entwickler muss sich somit nur um die Stringformatierung, Resultset usw. kümmern.
Oder man kann mit diesen Treibern bequem eine Datenbankanbindung z.B. in Excel erstellen; in dem Fall gehts nur darum, dass die Datenbank in der Registry eingetragen ist, damit andere Proggies drauf zugreifen können (gilt natürlich auch für die Java-Progger)

Mit Hardwareessourcen ist wohl gemeint, dass damit evtl. Optimierungen für div. Systeme gehandlet werden (autom. oder manuell), z.B. Ramausstattung, Festplattenverwaltung, CPU, Netzwerk, etc.
Es kann natürlich auch sein, dass damit spez. Datenbankserver gemeint sind, die für die jeweilige Datenbank optimiert sind, was aber ungefähr in dieselbe Richtung geht, da Datenbanken (zumindest die paar, die ich kenne) ausschliesslich auf Betriebssystemen (Solaris/Win/Linux/etc.) aufsetzen.

Kurz:
Das System ist für mich das, was den Anwendungsprogrammen zugrunde liegt. Eine klare Abgrenzung kann man somit nicht immer machen. Ein kleines Javaapplet ist somit reine Anwendungsprogrammierung, ein Hardwaretreiber klare Systemprogrammierung. Ich würde Datenbanktreiber eher im Bereich Anwendungsprogrammierung ansiedeln, da es in der Regel keine Hardware direkt anspricht, sondern nur die OS-Funktionen benutzt. Kann aber bei einer anderen DB, wie gesagt, anders aussehen.