Willkommen ~Gast!
Registrieren || Einloggen || Hilfe/FAQ || Staff
Probleme mit der Registrierung im Forum? Melde dich unter registerEin Bild.
Autor Beitrag
000
07.01.2002, 21:35
thinktank



Was passiert alles wenn eine .exe Datei aufgerufen wird ?
Natürlich wird sie in den Speicher gelegt etc. , aber das Betriebssystem muss doch da auch seine Finger im Spiel haben ( z.B. cout << " Hallo " wird in Windows im Dosfenster, in Linux afaik :) in der bash ausgegeben ).
Kapiert ihr was ich meine ?
Ich hoffe wieder auf einen langen Text von Kriz und Tron :D .
Oder sagt mir lieber gleich welches Buch dafür geeignet ist ( wahrscheinlich ein ASM-Buch)).

[EDIT]
Natürlich geht auch eine Homepäitsch D(:.
[/EDIT]

--


Dieser Beitrag wurde am 07.01.2002 um 21:55 von thinktank bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
001
07.01.2002, 21:58
Tron



ich muss erstmal bekennen, dass ich mich mit linux so gut wie nicht auskenne (ueber shutdown -h now komm' ich neicht raus)
in linux gibt es keine exe-dateien, aber etwas aehnliches wird es schon geben.

um zu deinem beispiel mit cout zu kommen:
wie das "Hallo" vom char-array auf den bildschirm kommt haengt von der implementierung der standard-bibliothken ab - und diese unterscheiden sich natuerlich von os zu os (und von rechnertyp zu rechnertyp, c gibt es ja auch fuer ataris, macs, commodore ...)

was garantiert ist, ist das interface:
du tippst cout << "Hallo"; und egal welcher rechner oder os, es erscheint "Hallo" auf dem bildschirm
wie das passiert ist sache der implementierung von cout dieses systems und sache des os (ich koennte fast wetten cout laueft ueber dos-interrupts, hab' das allerdings nie getraced)

ein anderes wichtiges beispiel sind new und delete (oder das gute alte malloc und free)
das interface ist stets das gleiche, aber WIE du an deinen speicherblock gelangst ist ganz allein das problem der implemetierung dieser operatoren/funktionen und diese bedienen sich logischerweise dem os, das ja als eniziges kontrolle ueber den (freien) speicher hat.

auch in diese kategorie der os-abhaengigen konstrukte faellt fstream, warum muss wohl nicht erlaeutert werden...

etwas ganz anderes, was beim laden von exe passiert ist das aufloesen der segmente, da deren adressen zur kompilierzeit ja noch nicht festehen (aber zu naeheren ausfuehrungen fehlt mir im moment die motivation und das referenzmaterial)

--

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

zum Seitenanfang zum Seitenende Profil || Suche
002
08.01.2002, 00:25
Kriz



Wenn ich mich dunkel erinnere, dann war das glaube ich so:

Bei C/C++ gibt es ja eine main()-Funktion. Und das ist schon der erste Schritt, denn eine Funktion braucht einen Aufrufer. In diesem Fall ist der Aufrufer das Betriebssystem (bzw. ein von der Implementierung der Runtime-Library erzeugter Prozeß). Nun geht das ganze Gejammer los: Der Maschinencode wird von der Datenquelle erstmal in einen addressierten (logisch =) und vom OS für diesen Prozeß zugewiesenen Speicherbereich des RAMs geladen. Während das OS mittels der Prozeßtabelle mit den diversen Prozesse rumhampelt und jedem Prozeß nach seiner Priorität soundsoviel Rechenzeit der CPU erteilt, wird beim Erhalt der Rechenzeit für unseren Prozeß der Maschinencode zuweilen erstmal in den L1-Cache geschoben (sofern einer vorhanden ist), wo die CPU mit ihren kleinen internen Helferleins dann den Inhalt des L1-Caches aufdröselt und in die Register einschleust, ehe die ALU mit den Berechnungen der Kommandos und Werten beginnt (bla bla bla)...

Nun soll etwas ausgegeben werden mittels cout. Die dafür zuständigen Interrupte im Maschinencode übergeben nun die Kontrolle des Codes an das Programm an sich, d.h. der Prozeß übernimmt die Gewalt, wobei natürlich nix ohne die CPU geht, klar. Der Prozeß erteilt nun der CPU die Anweisung, den Inhalt der Speicheradresse xyz auf dem Monitor (bzw. der Standardausgabe) auszugeben. Sobald das geschehen ist, gibt der Prozeß sofort wieder die Gewalt an das OS zurück, der Cache wird geleert und das OS versetzt den Prozeß wieder in einen Wartezustand, bis der nächste Bearbeitungszyklus wieder dran ist. So geht das im Prinzip bis zum Ende des Programms. Dann löscht das OS den reservierten RAM-Bereich, killt den Prozeß aus der Tabelle und datt war's.

Das war jetzt grob umrissen der Ablauf. Der ist natürlich noch viel feiner und es kann sein, daß ich etwas vergessen habe.

--

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

zum Seitenanfang zum Seitenende Profil || Suche
003
08.01.2002, 15:47
Prefect



Mmmkay, bei Linux sieht das wie folgt aus (unter Windows ein bißchen anders):

- die ausführbare Datei wird geöffnet; wenn sie gültig ist, wird der gesamte virtuelle Speicher des aufrufenden Prozesses gelöscht, andernfalls gibt's nen Fehler. Das ist dann quasi der point of no return
- die einzelnen Segmente der Executable werden in den Speicher geladen. Eigentlich ist es aber komplizierter: Die meisten Programme geben einen sog. ELF-Interpreter (normalerweise /lib/ld-linux.so.?) an. Der Kernel lädt dann erstmal diese simple, kleine Executable in den virtuellen Speicher und startet dieses Programm.
- der ELF-Interpreter öffnet erneut die Executable und untersucht sie, lädt dann alle Segmente der Executable und die benötigten Bibliotheken in den Speicher.
- wenn das alles erledigt ist springt er zur Startadresse des Programms. Diese Startadresse ist allerdings nicht main(), sondern eine Assemblerroutine, die quasi Bestandteil der RTL ist (die aber in die Executable selber mit eingelinkt wird). Naja, und die richtet dann die Kommandozeilenargumente etc.. her, initialisiert ein paar Variablen und führt letztendlich main() auf.

Unter Windows gibt's AFAIK kein exec() in dem Sinne, da kannst du nur über CreateProcess() einen neuen Prozess erzeugen. Windows verwendet auch soweit ich weiß keine Executableinterpreter im Userspace.

Übrigens ist Windows dumm, weil's kein reines exec() gibt (es sei denn ich täusche mich), und Linux ist dumm weil es einen ELF-Interpreter verwendet. Naja, die haben alle so ihre Macken.

cu,
Prefect

--

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

zum Seitenanfang zum Seitenende Profil || Suche
004
08.01.2002, 20:03
thinktank



ALU = Algorithm Unit oder so ?

--

zum Seitenanfang zum Seitenende Profil || Suche
005
08.01.2002, 21:28
Tron



Arimethical and Logical Unit
teil des prozessor, der fuer integer-arithmetik (add, sub, mul, div) und fuer logische operationen (and, or, xor) zustaendig ist

--

'KEINE PANIK' - aus der Triologie in fuenf Baenden von Douglas Adams

'FÜR DEINN FERD' - aus 'Gevatter Tod' von Terry Pratchett

zum Seitenanfang zum Seitenende Profil || Suche