user32.dll unter Windows 7
-
Befindet sich eigentlich die user32.dll auch bei einem 'herkömmlichen' Start von 'Windows 7' jederzeit im Speicher, sodass mein WINAPI Programm die Funktionen aufrufen kann, und gilt das auch für die msvcrt.dll? Oder werden diese beiden dlls unter Windows 7 gar nicht 'standardmäßig' beim Hochfahren von Windows 7 in den Speicher geladen, sondern nur dann, wenn ein Programm im 'Kompatiblitätsmodus zu XP' ausgeführt werden soll?
-
Also bei der user32.dll weiß ich das sie immernoch geladen wird. Aber kannst du ja mal ausprobieren...
-
DLL werden in einen Prozess geladen und nicht pauschal!
Wenn Dein Prozess die user32.dll benötigt dann wird diese auch geladen. Gleiches gilt für msvcrt.dll...
-
thx
Warum weiß eigentlich der Linker von Visual Studio, dass er mein Programm mit der msvcrt.lib verlinken muss, obwohl diese Bibliothek gar nicht in der Linker-Befehlszeile steht?
-
Ich würde gerne verstehen, WARUM eigentlich scanf() funktioniert, und auf welcher Abstraktions-Ebene ich eigentlich programmiere, wenn ich diese Funktion in meinem Programm aufrufe.
Zwei plausible Theorien:
(a) scanf() wird durch (tiefer liegende) Winapi-Funktionen emuliert?
(b) Oder 'dekorieren' die Winapi-Funktionen scanf()?
Habe bemerkt, dass (zumindest unter Windows 7) die Prozesse csrss.exe und conhost.exe praktisch allgegenwärtig sind. Falls ich in meinem Programm scanf() Aufrufe, geschieht zur Laufzeit folgendes:
- Eine weitere Instanz von conhost.exe taucht im Task-Manager auf.
- Der Task-Manager belehrt mich bezüglich meiner Konsolen-Anwendung, dass diese gerade nicht ausgeführt wird, und stattdessen auf den Prozess conhost.exe wartet.Meine Theorie dazu: mit scanf() wird eine weitere Instanz von conhost.exe erzeugt.
Der Aufruf von scanf() in meinem C-Quelltext ist (durch den Compiler oder den Linker?) kurzerhand durch ein WaitForSingleObject(mutex/INFINITE)-Konstrukt ersetzt worden, und den mutex bekommt mein Prozess erst dann wieder zurück, wenn der Anwender seine Eingabe im Konsolenfenster bestätigt hat, worum sich die mysteriösen Prozesse csrss.exe oder auch conhost.exe zu kümmern scheinen.
Ist meine Theorie (teilweise?) richtig?
Programmiere ich (unter Windows 7) auf einem höheren Abstraktions-Level, wenn ich die Funktionen der C-Standardbibliothek verwende, als wenn ich mit den entsprechenden Funktionen der WINAPI arbeiten würde, also dass ich mir ein Handle zu dem Prozess conhost.exe 'manuell' anfordere (sowie das Shared Memory, wo er mit bitteschön hineinschreiben soll, was der Benutzer eingibt usw.)?
Andererseits sind diese Funktionen der WINAPI (CreateProcess usw.) doch auch in C implementiert, und rufen ihrerseits bestimmt auch oft die C-Standardfunktionen auf (memcpy usw.). Wie können also die WINAPI Funktionen die C-Standardfunktionen aufrufen, ohne dass von letzteren widerum WINAPI Funktionen aufgerufen werden müssten, die das ausführen?
Vielleicht kann mir da jemand helfen, den Knoten zu entwirren ?
mfg
-
1. Ich hoffe das scanf nirgendswo in der Windows API verwendet wird, warum auch.
2. scanf wird nicht emuliert, warum den das auch?
3. scanf steckt in der CRT drin. Diese ist aber entweder statisch gelinkt (codein er EXE), oder eben dynamsich (Code in der DLL). Der Source Code der CRT (ink. scanf) liegt dem Visual Studio bei.
4. conhost hat mit scanf gar nichts zu tun, sondern damit, dass Du einen Consolen-Prozess gestartet hast...
5. Was meinst Du bitte mit Asbtraktionslevel?
6. memcpy selbst wird durch den C-Copmpiler meistens sogar direkt in Assembler Code umgesetzt (inline). Und auch memcpy steckt in der CRT. Die WinApi Funktion ist CopyMemory, die aber z.B. durch memcpy nicht benutzt wird
Wie wäre es wenn Du mal ein Buch über Windows liest... Jeffrey Richter "Advanced Windows" z.B.
-
Dann ist scanf vermutlich in csrss.exe oder in conhost.exe vorhanden, und Windows 7 delegiert das scanf() aus meinem Programm an diese beiden System-Dienste, die zwar auch 'im User-Space' ablaufen - aber scheinbar trotzdem ausreichende Rechte haben, um das 'echte CRT-' scanf() <bzw. memcpy() oder sonstige CRT-Funktionen> zu verwenden, wenn es ein Client von conhost.exe gerne täte (so ein Client wäre z.B. meine Konsolen-Anwendung).
Normaler Weise dürfen ja die Hardware Interrupts von meiner Tastatur gar nicht 'direkt' in meinem Programm landen, sondern wohl nur über den Umweg eines OS-Systemdienstes (eben z.B. conhost.exe oder csrss.exe). Und im Hauptspeicher herumkopieren wird man ja auch nicht ohne weiteres dürfen, ohne Genehmigung durch OS. Vermutlich gibt's für memcpy einen anderen Systemdienst (es laufen bei Windows 7 ja ständig 50+ System-Prozesse mit 580+ Threads, und bestimmt ist einer von denen dafür zuständig, meiner Konsolen-Anwendung das Herumkopieren im Speicher überhaupt erst zu erlauben - schon möglich dass dann dieser System-Dienst auch wieder ausreichende Privilegien hat, das memcpy() aus der CRT direkt aufzurufen - ganz im Unterschied zu meiner Anwendung).Jedenfalls ist es schwierig genug, instruktive Bücher zu dem Thema zu finden, werde mir auch gleich Deinen Buch-Vorschlag bestellen
Es macht eben nur begrenzt Spaß, wenn man nach Maßgabe der Muster vieler Winapi-Tutorials im Netz das eine oder andere kleine Programm schreibt und dabei nicht weiß, wie es der Compiler fertigbringt, aus dem Quellcode ein funktionierendes Windows-Programm zu basteln. Welche Teile meines Programms gar nicht 'innerhalb' meines Programms stattfinden, sondern in Wirklichkeit in irgend einem System-Dienst, dessen Client mein Programm ist.
Man wundert sich nur noch, wie so ein Monster-Programm wie Windows 7 überhaupt funktionieren kann, und dass die Programmierer nicht den Überblick verloren haben inmitten ihrer abermillionen Zeilen an C-Quellcode.Thx jedenfalls für die Erläuterungen.
mfg
-
scanf (genauso auch printf) muss ja irgndwie mit dem BENUTZER kommunizieren, und das geht nun mal NUR über das OS...
memcpy, muss mit niemandem kommunizieren, somit wird auch das OS nicht benötigt.
