Windows: Zusammenspiel Compiler und Betriebssystem

Alex144 schrieb:
> Wenn ich mit der IDE Visual C++ programmiere, dann enthält diese IDE
> sowohl den Compiler als auch den Linker.
Kann, muss aber nicht. Eclipse oder das alte AVR Studio zB enthalten gar 
keine Compiler.
> Die IDE selbst ist eine WinApi-Anwendung, also auch der Compiler und der
> Linker.
Das sind im Endeffekt ganz normale Programme, ja.
> Würde ich nicht in IDE executen sondern eine .exe laden, so wurde ein
> LOADER im User-Mode die Datei analysieren, wiederum über einen System
> Call den Prozess anmelden und ab hier wie oben mit der IDE.
Fast; die IDE macht das immer so. Wenn du direkt von der IDE aus 
startest, wird im Hintergrund immer eine .exe erstellt und gestartet. 
Falls du im Debug-Mode startest, fragt die IDE das OS ob sie das 
Programm überwachen darf. Im Task-Manager siehst du auch den Namen der 
.exe Datei.
> Vor allem ob Compiler und Linker selbst Win-Api Anwendungen sind
Kommt drauf an was du unter einer WinApi-Anwendung verstehst?
>  und
> Compiler und Linker im User-Mode ihre Arbeiten verrichten, will ich
> wissen.
Ja, genauso wie der explorer, notepad, Browser, Word... Eigentlich quasi 
alles außer dem BIOS und dem Kernel.

Alex144 schrieb:
> Wenn ich mit der IDE Visual C++ programmiere, dann enthält diese IDE
> sowohl den Compiler als auch den Linker.
Oohps, hab das "Visual C++" überlesen. Visual C++ wird mit dem Microsoft 
C++ Compiler ausgeliefert, ja, der heißt (wimre) cl.exe. Der ist ein 
Konsolenprogramm und wird vom Visual Studio aufgerufen wenn du auf 
"Build" klickst. Den kannst du auch von Hand aus einem DOS-Fenster aus 
aufrufen und ihm sagen, dein Programm zu übersetzen (komplett ohne das 
grafische Visual C++).

Kindergärtner, lauf bitte nicht weg!

Wenn die IDE selbst keinen Compiler hat, wie kompiliert sie dann den 
Code?

Eine WinApi-Anwendung ist für mich einfach ein Programm, dass auf 
Windows läuft. Sind nicht alle Programme außer den Windows 
System-Services WinApi Anwendungen, sprich Programme, die die Funktionen 
aus den DLLs der WinApi nutzen (außer einigen wenigen Ausnahmen, die die 
native API nutzen).

Jeder mp3-Player, Blender, Crysis 1-3, Photoshop usw. usf. -> Alles 
WinApi-Anwendungen, oder?

Ist der Microsoft C++ Compiler den selbst eine Win32-Anwendung, die im 
Usermode ausgeführt wird?

Oder arbeitet der Microsoft C++ Compiler auf tieferen Ebenen, also bis 
in den Kernal-Modus hinein. Oder ist er selbst Bestandteil davon?

Das verwirrt mich so. Von wem und wo werden Programme übersetzt?

Alex144 schrieb:
> Kindergärtner, lauf bitte nicht weg!
Nicht wenn ich hier Kinder beaufsichtigen kann :3
> Wenn die IDE selbst keinen Compiler hat, wie kompiliert sie dann den
> Code?
Sie ruft ihn auf! So wie der explorer den notepad aufruft, wenn du ihn 
in einem Fenster anklickst.
> Eine WinApi-Anwendung ist für mich einfach ein Programm, dass auf
> Windows läuft. Sind nicht alle Programme außer den Windows
> System-Services WinApi Anwendungen
Ja.
>, sprich Programme, die die Funktionen
> aus den DLLs der WinApi nutzen (außer einigen wenigen Ausnahmen, die die
> native API nutzen).
Mir sind da keine Ausnahmen bekannt, denn das WinAPI ist das native 
API, die unterste Ebene, um mit dem Betriebssystem zu kommunizieren.

> Jeder mp3-Player, Blender, Crysis 1-3, Photoshop usw. usf. -> Alles
> WinApi-Anwendungen, oder?
Ja. Wobei sehr viele Anwendungen nur über den "Umweg" eines Frameworks 
auf das WinApi zugreifen, was die Programmierung erheblich vereinfacht. 
Solche Frameworks sind MFC (historisch), Gtk, Qt, .net Framework, Java 
libraries, etc. Das WinApi direkt zu verwenden macht man "heute" kaum 
noch, da allein das Öffnen eines leeren Fensters zig Zeilen WinApi-Code 
erfordert...

Rufus Τ. Firefly schrieb:
> Abgesehen davon, daß das kein DOS-Fenster ist, stimmt's.
Dann eben eine Eingabeaufforderung.

Alex144 schrieb:
> Ist der Microsoft C++ Compiler den selbst eine Win32-Anwendung, die im
> Usermode ausgeführt wird?
Ja!
> Oder arbeitet der Microsoft C++ Compiler auf tieferen Ebenen, also bis
> in den Kernal-Modus hinein. Oder ist er selbst Bestandteil davon?
Nein, nein! Das wäre auch völlig unnötig. Der Compiler öffnet deine 
C/C++ Dateien und spuckt .exe Dateien aus. Dazu brauchts doch nur ein 
paar Datei-öffnen/lesne/schreiben/-Funktionen, und die kann man 
wunderbar im Usermode verwenden. So wie notepad,Word,blender Dateien 
öffnen, lesen, bearbeiten, sonst nichts! Einen Compiler kann man auch in 
Javascript,Java,PHP,ruby,python schreiben, weit weg vom Kernel,vom 
WinApi...

Zum Glück, dann ist ja mein Verständnis korrekt. Compiler und Linker 
sind also einfach normale Programme, die aus meinem C-Code neue normale 
Programme machen und das ohne den Kernal, schön übersichtlich im 
User-Mode.

Wie groß sind den die Geschwindigkeitseinbußen beim .NET Framework? Ich 
wollte die WinApi-Programmierung mit OpenGL kombinieren, da ich das für 
recht lohnenswert halte.

Und Danke! Ich habe wirklich viel recherchiert, bevor ich hier gefragt 
habe. Ich konnte das aber einfach nicht restlos klären. Also, danke dir!

Alex144 schrieb:
> Wie groß sind den die Geschwindigkeitseinbußen beim .NET Framework? Ich
> wollte die WinApi-Programmierung mit OpenGL kombinieren, da ich das für
> recht lohnenswert halte.
Durch das Framework selber dürften sich praktisch keine Einbußen 
ergeben, da du ja im Programm genau das selbe machen würdest. Und ob 
dein Programm jetzt 10000 oder 15000 neue Fenster pro Sekunde aufmachen 
kann ist dann doch auch egal oder?
Das größere "Problem" ist eher die Umgebung, in der .NET-Code läuft (die 
CLR).
Deren Geschwindigkeit ist aber nicht so einfach zu pauschalisieren... 
Gut geschriebener .NET Code kommt sicherlich an mäßig gut geschriebenen 
C/C++ heran, perfektionistisch handoptimierter C/C++ Code dürfte aber 
noch ein Näschen vorraus sein, vor allem bei der Speicherverwaltung.
Deinen Fragen nach zu Urteilen wirst du aber, glaube ich, nicht so 
schnell an die Grenzen von CLR/.NET stoßen. Ähnliche Dinge gelten für 
Java/JVM, das hat aber den Vorteil der besseren 
Plattform&Hersteller-Unabhängigkeit. Man kann damit aufwändige 
3D-Anwendungen mit OpenGL schreiben, ohne irgendwas mit dem WinApi zu 
machen. Minecraft zeigt dass es geht, aber wäre gewiss wesentlich 
effizienter umsetzbar als es ist...

Ja, ich glaube aber, dass ich trotzdem bei der WinApi-Programmierung 
bleibe. Denn die Programme selbst sind für mich nur sekundäre Ziele, 
worum es mir eigentlich geht, sind die Abläufe bei Betriebssystemen. Die 
würde gern ein wenig mehr im Detail verstehen. Und da ist die WinApi, 
wenn ich das richtig verstehe, besser geeignet, da sie einfach keine 
zusätzliche Abstraktionsebene vom Kernal trennt.

Alex144 schrieb:
> Und da ist die WinApi,
> wenn ich das richtig verstehe, besser geeignet, da sie einfach keine
> zusätzliche Abstraktionsebene vom Kernal trennt.
Naja geht. Wenn du Betriebssysteme lernen willst, schau dir lieber was 
UNIX-Artiges, wie Linux an; da kann man viel mehr sehen und es wird 
nicht hinter bunten Oberflächen versteckt. Außerdem hat sich dort jemand 
tatsächlich Gedanken gemacht, wie man das API (POSIX) zusammenbauen 
könnte, und nicht wie bei Windows einfach wild irgendwelches Zeug 
zusammenprogrammiert, das so gerade eben funktioniert.

Obligatorisch: www.amazon.de/dp/1292025778

Den Tanenbaum habe ich hier liegen, aber ich will erst ein 
Grundverständnis haben, bevor ich das Buch lese. Sonst geht mir die 
Motivation zu schnell flöten.

Linux schau ich mir noch sicher an, dafür muss aber mein neuer Rechner 
erst eintrudeln. Bis dahin bleibe ich bei Windows (das klingt so 
unbelehrbar, wenn ich es lese; soll es aber nicht tun).

Nochmals vielen Dank Kindergärtner.

P.S.: Colonel. Ich meinte eigentlich den Colonel.

Alex144 schrieb:
> Den Tanenbaum habe ich hier liegen
Sehr gut ;)
> Linux schau ich mir noch sicher an, dafür muss aber mein neuer Rechner
> erst eintrudeln.
Naja mit Linux/Unix tust du dir selbst einen Gefallen, so bunt Windows 
auch ist und so viele Spiele es auch dafür gibt, aus Programmierer-Sicht 
ist Unix viel einfacher, logischer, transparenter...
> Nochmals vielen Dank Kindergärtner.
Jo büdde :)
> P.S.: Colonel. Ich meinte eigentlich den Colonel.
Hä :D

Kindergärtner schrieb:
> Naja mit Linux/Unix tust du dir selbst einen Gefallen, so bunt Windows
> auch ist und so viele Spiele es auch dafür gibt, aus Programmierer-Sicht
> ist Unix viel einfacher, logischer, transparenter...

Wenn man Windows nicht unbedingt braucht (business vendor lockin, also 
alte teure Programme, die nur unter Windows funktionieren, oder Spiele),
dann ist man gerade wenn man in Richtung Informatik (Programmieren, 
Datenbanken, Netzwerke, eben all dies Computerzeugs ;)
mit einem Unix/Linux sehr viel besser dran.

Kindergärtner schrieb:
> Naja mit Linux/Unix tust du dir selbst einen Gefallen, so bunt Windows
> auch ist und so viele Spiele es auch dafür gibt, aus Programmierer-Sicht
> ist Unix viel einfacher, logischer, transparenter...

Der ist gut ROFL
Wenn man nicht gerade Treiber programmiert und "nur" ein grafisches 
Programm mit sinnvoller Benutzerführung bauen will empfehle ich Qt mit 
C++, das funktioniert dann unter Windows-XYZ genauso wie unter 
LinuxDistri-XYZ und BSD-XYZ und MacOS-XYZ und es gibt sogar Varianten 
für smartphones :-P
Welchen Compiler Du dafür nimmst hängt vom Ziel ab, geht also auch mit 
VisualC++.
Wenn Du ausschließlich Windows programmieren willst/mußt empfehle ich 
trotzdem Qt, schau's Dir einfach mal an ;-)

@cppler

Crossplatform wird immer wichtiger! Auch ich würde das Qt Framework 
empfehlen. Trotzdem möchte ich hier nochmals auf die unterschiedlichen 
Qualitäten diverser Betriebssysteme hinweisen. Wenn du sehr 
rechenintensive Tasks (Compilieren, ggf mit make -j8) durchführst und 
gleichzeitig noch flüssig mit deinem System arbeiten willst 
(weiterprogrammieren, API/Doku lesen, Beiträge im Forum schreiben), dann 
brauchst du einen sehr guten Scheduler im Betriebssystem. Und gerade 
da ist Linux führend.

test (Gast) schrieb:

Kindergärtner schrieb:
>> Naja mit Linux/Unix tust du dir selbst einen Gefallen, so bunt Windows
>> auch ist und so viele Spiele es auch dafür gibt, aus Programmierer-Sicht
>> ist Unix viel einfacher, logischer, transparenter...

> Wenn man Windows nicht unbedingt braucht (business vendor lockin, also
> alte teure Programme, die nur unter Windows funktionieren, oder Spiele),
> dann ist man gerade wenn man in Richtung Informatik (Programmieren,
> Datenbanken, Netzwerke, eben all dies Computerzeugs ;)
> mit einem Unix/Linux sehr viel besser dran.

Beides gilt nur, wenn man sich zu den Konsolen-Nerds gesellen und auf 
schöne Entwicklungsumgebungen wie Visual Studio (Express) (C/C++/C#) 
freiwillig verzichten, dafür dann (zwangsweise) mit einer fetten 
Java-GUI wie Eclipse vorlieb nehmen darf. Wer sich das antun will, soll 
das tun (solange er weiß was er tut). Das gleiche gilt für 
Pascal/Delphi. Beides sind typische Windows IDE und dort gut mit 
Beispielcode unterstützt. Mit Kylix für Linux hat(te) Borland ja eine 
Bauchlandung hingelegt - wurde eingestellt.

Interessant ist auch, dass der Threadersteller hier nach der WIN-API 
fragte und sofort wieder von Foren-Nerds versucht wird ihn auf Linux 
umzupolen. Frage nach einem guten Fleischgericht und die Fraktion 
"Veggie Day" wird versuchen dích zum Vegetarismus zu bekehren.

test schrieb:
> @cppler
>
> Und gerade da ist Linux führend.

Klar und z.B. AIX ist Müll usw. usf.
Das Un*x allgemein ein besser durchdachtes Konzept ist ist unstrittig.
Leider sehen das die Marktführer anders und deswegen gibt es am meisten 
Wintel Systeme jetzt mit Windoof8 das sich auch auf Tablets gegen 
Android nicht so durchsetzt wie das geplant war.
Ist das gleiche Spiel wie mit Netscape gegen IE und die Strategie dabei.
Und Linux ist nicht unbedingt führend, es gibt genügend Distibutionen 
für alles mögliche allerdings war das kleine Teufelchen auch schon immer 
da :-P
Es gibt nunmal kein "perfektes" OS und die Marktführer setzen nunmal auf 
Kommerz was sich ja bei den SPS&Co. niederschlägt.
Schon mal gesehen was an japanischen Systemen so marktführend ist ?
Und Linux-Treiber hacken kann schnell in größeren Frust ausarten als 
sich der glorreichen 64k Selbstverwaltung von Windows anzuvertrauen ;-)
Es kommt immer darauf an was man braucht und tut, das OS spielt erstmal 
keine Rolle, das ist für funktionierende Hardware zuständig und sonst 
nix.

cppler schrieb:
> Der ist gut ROFL
> Wenn man nicht gerade Treiber programmiert und "nur" ein grafisches
> Programm mit sinnvoller Benutzerführung bauen will
Hättest du den Thread gelesen, wüsstest du, dass er nicht einfach nur 
ein olles GUI-Programm bauen, sondern über OS-Aufbau lernen will.
> empfehle ich Qt mit C++
Ja.

Herr werfe Verstand schrieb:
> Beides gilt nur, wenn man sich zu den Konsolen-Nerds gesellen und auf
> schöne Entwicklungsumgebungen wie Visual Studio (Express) (C/C++/C#)
> freiwillig verzichten
Durch herumklicken im VS lernt man nicht wie ein OS aufgebaut ist und 
wie das API funktioniert.
>, dafür dann (zwangsweise) mit einer fetten
> Java-GUI wie Eclipse vorlieb nehmen darf.
1. ist VS mindestens genauso schlimm und 2. zwingt dich keiner eclipse 
zu benutzen, es gibt noch 100 andere IDE's und Editoren.
> Interessant ist auch, dass der Threadersteller hier nach der WIN-API
> fragte und sofort wieder von Foren-Nerds versucht wird ihn auf Linux
> umzupolen.
Zu recht; er hat ja sogar den Tanenbaum rumliegen, und der erläutert nun 
nicht gerade das WinApi!
> Frage nach einem guten Fleischgericht und die Fraktion
> "Veggie Day" wird versuchen dích zum Vegetarismus zu bekehren.
Klar, vergleiche mal CreateProcess (WinApi) mit fork+exec (POSIX/Unix) 
und erkläre dann mal was hier Fleisch und was Wassersuppe ist :P

Kindergärtner schrieb:
> cppler schrieb:
>> Der ist gut ROFL
>> Wenn man nicht gerade Treiber programmiert und "nur" ein grafisches
>> Programm mit sinnvoller Benutzerführung bauen will
> Hättest du den Thread gelesen, wüsstest du, dass er nicht einfach nur
> ein olles GUI-Programm bauen, sondern über OS-Aufbau lernen will.
>> empfehle ich Qt mit C++
> Ja.

Das bezog sich auf Deine Aussage wegen Linux.
Wer Betriebssysteme verstehen will sollte sich einschlägige Literatur 
ansehen bzw. selber überlegen was das denn macht.
Ich hab's ja schon kurz zusammengefaßt:
Ein OS stellt eine standardisierte Schnittstelle zur Hardware zur 
Verfügung.
Ob da nun kooperatives Multitasking enthalten ist oder preemptives ist 
erstmal genauso egal wie Multiuser oder Cluster oder oder oder.
Aber wenigstens sind wir uns über gute Bibliotheken einig ;-)

Kindergärtner (Gast) schrieb:

Herr werfe Verstand schrieb:
>> Beides gilt nur, wenn man sich zu den Konsolen-Nerds gesellen und auf
>> schöne Entwicklungsumgebungen wie Visual Studio (Express) (C/C++/C#)
>> freiwillig verzichten

> Durch herumklicken im VS lernt man nicht wie ein OS aufgebaut ist und
> wie das API funktioniert.

Was sollen denn solche bescheuerten Ansichten? Das Win-API lernt man 
durch programmieren kennen und dazu benutzt man die Tools, die dafür 
extra von Microsoft entwickelt wurden. Visual Studio ist eine 
ausgezeichnete IDE. Dagegen ist deine Methode strunzdoofer Editor + 
Kommandozeilencompiler STEINZEIT und vor allem nur NERD tauglich. Oder 
du verwendest einen schlauen Editor wie emacs, den man sich erst mal 
hinstricken muss, der versucht der Hilfe von VS nachzueifern. Für 
Windows und Einsteiger ist das aber keine gute Wahl. Hier fragte ein 
ANFÄNGER nach und nicht einer wie DU, dem das alles bereits in Fleisch 
und Blut übergegangen ist.

>>, dafür dann (zwangsweise) mit einer fetten
>> Java-GUI wie Eclipse vorlieb nehmen darf.

> 1. ist VS mindestens genauso schlimm

Das halte ich für ein Gerücht. Meine HW ist mit AMD Doppelkern Proz 
nicht die schnellste, aber für VS reicht es locker. Compilieren in der 
(DOS-)Shell geht damit genauso. Dafür hat MS eine Batch mit den 
Umgebungsvariablen, die man ausführen kann. All das wird automatisch 
eingerichtet. Man braucht sich nicht erst wie bei Linux einen Nagel ins 
Knie schießen, um eine funktionierende Entwicklungsumgebung mit allerlei 
Skriptgedöns einzurichten.

> .. es gibt noch 100 andere IDE's und Editoren.

Die alle nicht besser sind. Ganz im Gegenteil.

>> Interessant ist auch, dass der Threadersteller hier nach der WIN-API
>> fragte und sofort wieder von Foren-Nerds versucht wird ihn auf Linux
>> umzupolen.

> Zu recht;

Danke das du das auch noch zugibst. Vielen Dank! Der missionierende 
Eifer der Linux Jünger ist mir schon öfter aufgefallen. Irgendwas habt 
ihr mit Claudia Roth gemein. Letztere gibt hingegen sogar zu trotz 
Veggie Day auch gerne Bratwurst zu essen. Wahrscheinlich haben die 
Linux-Nerds klammheimlich auch alle ihr Visual Studio laufen, sagen das 
nur nicht offen, weil "politically incorrect".

> er hat ja sogar den Tanenbaum rumliegen, und der erläutert nun
> nicht gerade das WinApi!

Das eine hat sowieso mit dem anderen nichts zu tun. Auf der Hochschule 
gibt es dafür ZWEI UNTERSCHIEDLICHE Vorlesungen. Die eine nennt sich 
Rechnerarchitektur und die andere Softwaretechniken. Der TE sollte 
erkennen, dass es Käse ist erst mal ALLES MÖGLICHE kennen lernen zu 
wollen, um sich dann ans Programmieren (die Win-API) zu begeben. Die 
Win-API anzuprogrammieren fängt man einfach an, indem man sich die 
Tutorials dazu anschaut und durcharbeitet und das Standardwerk 
schlechthin durchliest, nämlich den Petzold.

>> Frage nach einem guten Fleischgericht und die Fraktion
>> "Veggie Day" wird versuchen dích zum Vegetarismus zu bekehren.

> Klar, vergleiche mal CreateProcess (WinApi) mit fork+exec (POSIX/Unix)
> und erkläre dann mal was hier Fleisch und was Wassersuppe ist :P

Das überlasse ich dir, da du der tolle Hecht hier bist und ich nicht mit 
Linux programmiere.

Übrigens interessant, dass du hier zum Nick "Kindergärtner (gast)" 
greifst bei deinen Fähigkeiten. Traust du dich nicht deine tollen 
Programmierfähigkeiten mit deinem angemeldeten Nick zu vertreten?

A. K. (prx) schrieb:

Herr werfe Verstand schrieb:
>> Interessant ist auch, dass der Threadersteller hier nach der WIN-API
>> fragte und sofort wieder von Foren-Nerds versucht wird ihn auf Linux
>> umzupolen.

> Das hat vielleicht auch damit zu tun, dass der *ix Bereich wesentlich
> besser dokumentiert ist, was das Innenleben der Systeme angeht. Und
> damit, dass Grundlagen an einfacheren Systemen übersichtlicher erklärt
> werden können, weshalb das historisch aus sehr einfachen und offenen
> Systemen entwickelte Unix da einen gewissen Vorsprung hat.

Also ich weiß ja nicht wieviel Zeit der TE hat. Ich halte es für 
ausgeschlossen in überschaubarer Zeit SOWOHL die "Innereien" eines OS 
vollständig kennenzulernen ALS AUCH noch die Win-API umfänglich sich 
reinzuziehen respektive flüssig anwenden zu können. Dafür braucht es 
Jahre und ein Vollzeitstudium der Materie. Da sind selbst ein paar 
Semester RA und SW-Techniken gar nichts und den Lerneifer einer 
kompakten Vorlesung musst du selber erst mal auf die Reihe bekommen, 
zwischen all den Unterbrechungen in den heimischen vier Wänden (Telefon, 
Fernsehen, Futterage, Aufräumen, Freunde, Familie, Haustiere, 
I-NET-Foren Gedöns usw.). Intelligente Überflieger u. Einsplus-Schreiber 
mögen das vielleicht können. Nur stellen die erst gar nicht solche 
Fragen hier. Die wissen wie man das angeht. Allein den Petzold 
durchzuarbeiten kostet Zeit, viel Zeit. Das ist ein 1200 Seiten Buch und 
spiegelt auch nur den Stand von Windows 9x wieder bzw. enthält längst 
nicht alles. Hier kann man sich schnell komplett verzetteln und dann 
steht man in etwa ähnlich da, wie derjenige, der mal vorhatte hier im 
Forum sich seine eigene Layout-Software a' la eagle zu schreiben und 
meinte, mit einem Menügerüst sei die Aufgabe bereits quasi bewältigt.

Um ein Betriebssystem zu verstehen muß man nicht in die Interna 
verschiedener Varianten gehen, dazu reicht eine Schichtabstraktion:

1. Hardware
2. Hardwaretreiber
3. Standardisierte Schnittstelle für Hardwareansteuerung
4. Standardisierte Schnittstelle für Softwareausführung
5. Software

Das wäre ungefähr das was DOS abgebildet hat, ein User, ein Programm und 
via Treiber Zugriff auf die Hardware.
Aber selbst unter DOS gab es schon Tücken ;-)

Es ist nicht mein Ziel, Windows komplett verstehen zu können. Überhaupt 
bezweifle ich, dass irgendjemand ein modernes Betriebssystem in vollem 
Umfang kennt; selbst wenn jemand einen Teil davon entwickelt, braucht 
man sicherlich die Abstraktion der anderen Bestandteile. Zumindest 
wüsste ich nicht, wie jemand diese Menge an Millionen Zeilen Code 
verstehen will.

Insofern stört es mich nicht, wenn ich für Betriebssysteme nie über ein 
Verständnis als abstrahiertes Modell hinaus komme.

Und zu guter letzt bin ich E-Techniker mit Spezialisierung auf 
Nachrichtentechnik, ich habe andere Dinge, die ich im Detail verstehen
muss:-)

Nichts stört mich am Tanenbaum. Wie ist denn der Eindruck entstanden?

Ich will einfach nur ein wenig Grundverständnis haben und dann das 
Wissen mit dem Tanenbaum bestätigen und vertiefen. So finde ich Lernen 
allgemein effektiver. Das mache ich nicht nur hier so, sondern bei 
allem: Erst ein wenig eigenständige oberflächliche Recherche, und dann 
die Vertiefung.

Alex144 schrieb:
> Zumindest
> wüsste ich nicht, wie jemand diese Menge an Millionen Zeilen Code
> verstehen will.

Muss man ja auch nicht, den Source-Code ohnehin nicht, und auch die 
Schnittstellen nur soweit man sie eben braucht. Ich habe mich mal mit 
dem Telefon-API von Windows auseinandergesetzt (TAPI), weil ich unseren 
Telefonen im Betrieb das Anwählen von Kunden aus der Datenbank 
beibringen wollte, das ist ein ganzes API für sich, aber 99% aller 
Programmierer werden es nie brauchen und wissen wahrscheinlich nicht 
mal, dass es das gibt. Alle diese speziellen APIs zu kennen, die 
letztlich zusammen das Win32 bilden, bringt einen beim Verständnis des 
Betriebssystems nicht weiter, eher schon die Beschäftigung damit, wie 
man so ein spezifisches Problem unter Windows UND unter Linux löst. Mehr 
Auswahl steht ja praktisch nicht mehr zur Verfügung, das macht die 
Beschäftigung mit Betriebssystemen heute schwierig. Ausnahmen sind 
Realtime-Systeme, aber die kann man wiederum nicht sinnvoll mit Windows 
oder Linux vergleichen. Aber zu Lernzwecken vielleicht nicht schlecht, 
bei Realtime und Embedded ist auch die Vielfalt grösser.

Gruss Reinhard