N
Der Assemblercode an sich bleibt unabhaengig vom Betriebssystem gleich, mit der Ausnahme, dass man bestimmte Befehle in Betriebssystemen, die im Protected Mode (alle Multitasking-Systeme wie Windows, Linux, usw.) laufen, nicht benutzen darf.
Allerdings aendert sich wie bei anderen nicht maschinenunabhaengigen Sprachen wie c++ (im Gegensatz zu zB. Java) auch bei Assembler natuerlich je nach Betriebssystem, fuer das Programmiert wird, die API, dh. die Schnittstellen mit dem Betriebssystem. Ein "nacktes" Assembler gibt es nicht. Du kannst wie gesagt entweder Programme in Assembler, C oder sonstwas fuer ein Betriebssystem schreiben, dh. ein Programm, das sich an Standards des Betriebssystems haelt und dessen APIs benutzt oder eben selbst in Assembler etc. ein Betriebssystem schreiben. Dann hast du keine APIs, die du benutzen kannst und bist auf dem System "der Boss". Macht prinzipiell aber keinen Unterschied, ist beides Assembler, c oder was auch immer.
zu a) Maschinencode, dh. was der Assembler fuer die CPU (MASM zB.) ausspuckt, laeuft immer auf der CPU. Das ist also iaR. auch das einzige Teil, das den Maschinencode "versteht".
zu b) Das BIOS ist nur ein Stueck Software. Ein Programm (Maschinencode fuer die CPU und Daten), das auf einem ROM-Chip liegt. Tut also von sich aus absolut gar nichts.
Dieses Programm stellt eine Art grundlegendes Mini-Betriebssystem dar, das nach dem Einschalten automatisch als erstes gestartet wird. Das Ding testet und initialisiert dann schnell die Hardware, startet je nach Einstellungen irgendeinen Bootsektor und stellt Funktionen wie den int 10h und int 13h zur Verfuegung. Daher der Name Basic I/O System.
Schlag mal nach, was eine CPU, ein Betriebssystem und ein BIOS ist.
zu c) Richtig. Assembler ist eine ziemlich direkte und "niedrige" Abstraktion des Maschinencodes in Form von Mnemonics. Jedes Mnemonic entspricht ziemlich genau einem bestimmten Maschinenbefehl, also den Binaeren Daten. Der Assembler macht dann nicht viel mehr, als die Syntax zu pruefen und die Mnemonics durch die jeweiligen Codes zu ersetzen. Kannst du auch mal nachschlagen. Bei Wikipedia ist das alles bestimmt recht schoen erklaert.
zu d) Wie gesagt, das BIOS bekommt in der Hinsicht nichts als Ausgangsdaten, das BIOS ist die Ausgangsdaten.
int 10h muesste AFAIR in Maschinencode die 2 Bytes CD 10 sein. Wie der Befehlssatz in Binaerform aussieht, steht in jeder besseren Befehlsreferenz. Der x86-Befehlssatz ist aber ziemlich wuest...
zu e) Diese Funktion scrollt AFAIR den Text auf dem Bildschirm irgendwie rum (habe den Quark nie benutzt).
Und im Grunde wissen sowohl das BIOS (das diese Funktion bereitstellt) als meist auch der Grafikchip was damit anzufangen... Allerdings implementiert so ein BIOS (Grafikkarten haben uebrigens ihr eigenes BIOS als eine Art auf der Hardware direkt mitgelieferten Treiber) AFAIK idR. keine Unterstuetzung fuer so abgefahrene Sachen wie Hardwareunterstuetzung von Scrolling etc.
zu f) Du meinst die unterste Ebene? Nein, da wie gesagt das BIOS auch nur eine Software ist. Software-Interrupt-Aufrufe (int-Befehl) sind eigentlich nichts anderes als Funktionsaufrufe. Die CPU springt an eine voreingestellte Stelle im Speicher und fuehrt den dort stehenden Code, in diesem Fall des Graka-BIOS, aus.
Tatsaechlich waere die unterste Ebene das direkte Schreiben in den Textbuffer. Das ist ein Speicherbereich, aus dem die Grafikhardware beim Bildschirmzeichnen liest, was gerade so auf dem Bildschirm stehen sollte.
C++ ist wie gesagt eine recht abstrakte oder "hohe" Sprache. cout ist Verglichen mit der niedlichen Prozedur in deinem Assemblercode ein reichlich kompliziertes Ungetuem aus zig internen verschachtelten Prozeduren und Funktionen und meilenweit von der untersten Hardwareebene entfernt.