Hallo, ich wollte mich an die WinApi machen, habe aber beschlossen, zuerst sauber zu verstehen, was eigentlich im Hintergrund geschieht, bevor ich eine Anwendung programmiere. Meine Frage ist, ob das folgende richtig ist: Wenn ich mit der IDE Visual C++ programmiere, dann enthält diese IDE sowohl den Compiler als auch den Linker. Die IDE selbst ist eine WinApi-Anwendung, also auch der Compiler und der Linker. Wenn ich nun in der IDE execute, so wird der Code übersetzt und gelinkt IM USERMODE, und die IDE meldet für mein Programm einen Prozess an (User-Mode geht kurzzeitig über in Kernal-Mode). Der Code, der im User-Mode erzeugt wurde, wird in den zugewiesenen Prozess-Speicher geladen und ausgeführt. 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. Vor allem ob Compiler und Linker selbst Win-Api Anwendungen sind und Compiler und Linker im User-Mode ihre Arbeiten verrichten, will ich wissen. Vielen Dank Alex
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?
Kindergärtner schrieb: > Den kannst du auch von Hand aus einem DOS-Fenster aus aufrufen Abgesehen davon, daß das kein DOS-Fenster ist, stimmt's.
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.
da war doch mal was mit "Kernal" ... http://de.wikipedia.org/wiki/Kernal oder meintest du gar den Kernel? http://de.wikipedia.org/wiki/Kernel_%28Betriebssystem%29
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
Alex144 schrieb: > Den Tanenbaum habe ich hier liegen, aber ich will erst ein > Grundverständnis haben, bevor ich das Buch lese. Ulkiger Ansatz. Traditionell liest man Lehrbücher, um eben gerade das Grundverständnis zu gewinnen. Sogar in heutiger Zeit, in der man dann anschliessend bei entsprechender Suche mit Details realer Systeme überschüttet wird.
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.
Kindergärtner schrieb: > 1. ist VS mindestens genauso schlimm Es hat unbestritten einen der besten Debugger. Und warum das Nutzen einer IDE für Dich "herumklicken" ist, das wirst nur Du wissen. Die API und die Funktionen des Betriebssystems lernt man durch Programmieren, ob man das Programm nun in vi, Emacs oder einer IDE schreibt, ist zweitrangig -- allerdings ist die Integration einer Online-Hilfe schon ein Vorzug, der bereits in der ersten Hälfte der 90er Jahre des letzten Jahrhunderts erkannt wurde, und den zumindest ich nicht missen möchte. Nein, man-pages sind keine Online-Hilfe.
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 ;-)
test schrieb: > 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. Selbst wenn hier (W7/8 x64) Prime95 alle Cores ausnutzt, merkt man davon weder etwas im Browser, noch in der IDE noch sonstwo. > Und gerade da ist Linux führend. Da ist Linux bei weitem nicht führend insb. nicht wenn man sich mal die Forschung auf diesem Gebiet ansieht. An den TO: Ein guter Startpunkt wären kleine Kernel wie z.B. der L4 http://www.l4ka.org/ http://www.ertos.nicta.com.au/research/sel4/ (das sind gerade einmal 8700 Zeilen Quelltext)
Arc Net schrieb: > Selbst wenn hier (W7/8 x64) Prime95 alle Cores ausnutzt, merkt man davon > weder etwas im Browser, noch in der IDE noch sonstwo. Die CPU aufzuteilen kriegt bei reinen userlevel CPU-Burnern wie Prime95 jeder nicht völlig verblödete Scheduler hin. Knackig sind Background-Tasks mit intensiven Diskzugriffen, zumal bei HDDs, und Speicherfresser. Wenn dann noch bestimmte Filesysteme (z.B. yaffs2 in Android) sämtliche Cores lahmlegen...
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:-)
Alex144 schrieb: > Insofern stört es mich nicht, wenn ich für Betriebssysteme nie über ein > Verständnis als abstrahiertes Modell hinaus komme. Sinnvoller Ansatz. Aber was stört dich dann am Tanenbaum? Zur abstrakten Modellierung kommst du jedenfalls nicht über den API, egal welchen.
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
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.