ich beschäftige mich zur zeit mit folgenden überlegungen: Ein Betriebssystem führt ja ein Programm aus, weist ihm Speicher zu usw. Wenn jetzt aber ein Programm auf Systemrecourcen zugreifen will, sei es eine Ausgabe oder ein Dateizugriff.. woher weiss das Proramm wo es das anfragen soll? Bekommt das Programm beim Start einen Pointer auf eine universelle verwaltung für anfragen oder so? Oder werden die funktionen immer auf die gleiche speicheraddresse gelegt? Sorry wenn die Fragen etwas komisch klingen aber ich hab bei Google nichts genaues gefunden...
Das programm weiss das nicht. Du sagst dem Programm das, in dem du definierte Funktionen aufrufst. Die gehören dann zu einer Programmbibliothek, oder DLL, die dann auf die User-Schnittstelle des Betriebssystems zugreifft (das ist dann z.B. der alte INT21) Gerhard
Unter Windows ist das: http://de.wikipedia.org/wiki/WinAPI Jemand, der ein Windows-Programm schreibt teilt Windows über diese Schnittstelle mit, was Windows machen soll. Ein anderes Framework (=Bibliotheken um z.B. in Windows zu programmieren) bildet die Befehle auch letztendlich auf die WinAPI ab. Es gibt z.B. QT dessen Programme dann unter Windows oder KDE bei Linux lauffähig gemacht werden können. Ich hab da noch keine praktische Erfahrung, aber ich möchte wohl mal irgendwann mit QT anfangen um n Windows-Prog. zu schreiben, dass Daten von nem Datenlogger erfassen soll und grafisch darstellen. Hab da noch ANGST, wegen Serielle Schnittstelle ansprechen, wegen WinXP und kein dierekter Zugirff undso :(
Also werden die Funktionen beim Programmstart angefordert und via DLL in den Speicher geladen.. Danke! @XA: Warum benutzt du nicht .Net bzw Mono? Läuft unter Win und Linux (zumindest in .Net1). Programmieren lässt sich ganz gut mit C#, komponenten für die RS232 sind dabei.. (kP ob die dann auch unter Mono implementiert sind)
Wie das gemacht wird, hängt doch sehr stark vom System ab. Unter Linux wird so gut wie alles, was an Peripherie da ist, durch eine Art virtuelle Datei (Device Indoe) repräsentiert. Diese Datei kann man dann einfach öffnen. Wie man das Gerät dann anspricht, hängt vom Gerätetyp ab. Manche kann man einfach mit read/write lesen und schreiben, andere in den Adressraum des Programms mappen mit mmap. Dann gibt es noch den Systemcall mit Namen ioctl, mit dem man meist weitere gerätespezifischen Funktionen ansprechen kann.
Die Frage, ist, was abgefragt werden soll. Unter Linux/Unix läuft das "eigentlich" alles über die Gerätedateien (alles ist eine Datei [auch due Graka ;) ]). Aber da gibts auch noch verschiedene andere möglichkeiten a'la parport, wo man direkt die Hardware des lp manipulierten kann.
Direkter Hardwarezugriff unter Linux geht zwar, sollte aber wann immer möglich vermieden werden. Solche Programme laufen nacher nur als root und sind damit immer ein potenzielles Sicherheitsrisiko und auch nicht von Leuten einfach so benutzbar, die keinen Rootzugang haben. Solche Programme können sich mit Treibern beißen und eine Instabililtät des Programms kann zum Systemabtürz führen. Für den Parallelport gibt's seit Jahren einen Treiber.
mir ist gerade etwas aufgefallen: Wenn ein ein Prozess in einem virtuellem Speicher läuft.. und von allen anderen Dingen im Speicher abgeschottet ist - Wie kann es/er Funktionen von "ausserhalb" aufrufen?
Die Abschottung gilt nicht "allen anderen Dingen im Speicher" sondern anderen Prozessen. Beim Kompiliervorgang wird zum Schluß der Linker aufgerufen, welcher die Bibliotheken (*.dll/*.so/*.dylib - je nach Betriebssystem) mit der ausführbaren Datei verlinkt. Beim statischen Linken wird der Code der gebrauchten Funktionen aus den Bibliotheken direkt in das endgültige Programm kopiert. Dynamisch verlinkte Programme beinhalten eine Art Tabelle mit Verweisen, welche Bibliotheken zur Laufzeit gebraucht werden. Diese Tabelle wird beim Starten des Programms ausgewertet, und der dynamische Linker lädt dann die gewünschten Bibliotheken in den virtuellen Speicher des Programms nach. Das Resultat in beiden Fällen: Die gewünschten Funktionen sind im Adreßraum des Prozesses gemappt. Die Aufrufe erfolgen somit "lokal" im virtuellen Speicher des Programms. Damit ein eventuell fehlerhaftes Programm keinen Unsinn mit dem Speicherbereich der dynamischen Bibliotheken treibt, wird dieser gegen Schreibzugriffe geschützt. Vorteil von dynamischen Bibliotheken ist, daß sie in viele virtuellen Speicherbereiche (d.h. viele Prozesse) eingeblendet werden können, während sie nur ein Mal im physischen Speicher exisiteren. Zugriff auf alles, was "außerhalb" liegt, erfolgt wie schon oben beschrieben über Interrupts, System-Calls, jedoch in der Regel nicht direkt, sondern eben über die Funktionen der verfügbaren Bibliotheken. Erst so kann der Kernel-Modus erreicht werden, welcher unbegrenzten Zugriff auf alle Resourcen hat. Darin wird die gewünschte Operation ausgeführt (z.B. Laden einer Datei in den Speicher), beim Beenden des Interrupts/System-Calls wird der priviligierte Modus wieder verlassen und das Programm fortgeführt. Das ist nur eine grobe Beschreibung und jedes Betriebssystem verhält sich hier in den Details anders. Für einen Überblick sollte es trotzdem reichen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.