Assembler auf Windows?

[Baw 10]

Hallo zusammen

 

Jetzt sind alle gefragt die Windows wirklich "verstehen";)

 

Erst mal etwas Grundlage:

Grundsätzlich sind ja alle Programme die ich als EXE-Datei oder DLL etc. habe in Maschinensprache kompiliert. Sprich die meisten davon sind in irgendeiner High-Level Programmiersprache geschrieben und wurden danach auf Maschinencode kompiliert, sprich in Assembler "konvertiert".

Assembler auf der Stufe von Chip-Programmierung ist ja noch relativ einfach zu verstehen; Ich habe z.B. acht Inputs die kann ich verarbeiten und an meine Outputs weitergeben. Diese sind jeweils fest auf die Platine eingelötet und werden für jeden Chip vom Chiphersteller beschrieben.

Wenn wir jetzt ein Beispiel auf Windows machen, etwa Notepad, habe ich auch Assembler Code den ich ansehen kann.

 

Und hier beginnt mein Verständnisproblem:

Welche Schnittstellen stellt mir z.B. Windows zur Verfügung, damit ich etwa eine Text-Datei von der Festplatte lesen kann? Schliesslich greife ich mit meinem Programm nicht direkt auf die Hardware zu. Die Reihenfolge ist ja Programm - Betriebssystem - Treiber - Hardware. Das heisst, dass mir Windows irgendeine Möglichkeit geben muss auf die Datei die auf der Harddisk liegt zuzugreifen und zwar auf Assembler-Ebene, da mein Programm ja auch als Assembler vorliegt.

 

Es geht mir hier in erster Linie um die Verständnisfrage, nicht dass ich es programmieren will x).

 

 

Danke für die Antworten.

 

 

Gruess Baw

 

PS: Lektürenempfehlungen zu dem Thema werden auch gerne entgegengenommen :)

[Cybquest 36]

Um welche Art Verständnis geht es denn?

Windows bietet entspr. IO-Schnittstellen an, d.h. die Programme rufen einfach die entspr. Routine auf.

Z.B. einfach mal den API-Guide ansehen, welche Aufrufe allein die Kernel32-Library bietet.

 

Ein Buch grad er"amazon"ed (nicht von mir gelesen):

Assembler: Maschinennahes Programmieren von Anfang an. Mit Windows-Programmierung: Amazon.de: Reiner Backer: Bücher

[marka 584]

Richtig!

 

Microsoft hat für Entwickler so genannte APIs (Accessible Program Interface) geschaffen.

 

Wenn Du z.B aus einem Programm heraus den Öffnen-Dialog aufruft, dann sieht das ja, sofern korrekt programmiert, immer gleich aus. Genauso beim Speichern unter...

 

Diese Dialoge werden über APIs abgebildet. D.H. ein Programmierer muss das Rad nicht neu erfinden, sonder ruft in seiner Applikation lediglich das passende API auf.

 

Um zu erfahren, welches API für welche Funktionen/Dialoge zuständig ist, kann ich nur das MSDN-Webportal bei Microsoft empfehlen (msdn.microsoft.com).

[Cybquest 36]

... Ich habe z.B. acht Inputs die kann ich verarbeiten und an meine Outputs weitergeben. ...

 

nur zur Vervollständigung: Ganz so läufts bei X68-Prozessoren nicht.

Es gibt u.a. einen Adress- und einen Datenbus.

Ganz vereinfacht ausgedrückt wird zum lesen und schreiben (Festplattencontroller, RAM, Grafikkarte...) am Adressbus vom Prozessor die entspr. Adresse geschaltet und am Datenbus die Daten bereitgestellt (schreiben) bzw. abgeholt (lesen).

Diese "Daten" können Befehle oder "Nutz"daten sein.

[lefg 276]

Wie ist das denn beim Versuch mit dem direkten Zugriff auf die Hardware von einer (auch selbsterstellten) Anwendung aus; war da nicht etwas bei Windows, eine Trap?

–

.....Grundsätzlich sind ja alle Programme die ich als EXE-Datei oder DLL etc. habe in Maschinensprache kompiliert. Sprich die meisten davon sind in irgendeiner High-Level Programmiersprache geschrieben und wurden danach auf Maschinencode kompiliert, sprich in Assembler "konvertiert".

Programme können in einer höheren oder in einer niederen Programmiersprache erstellt werden, höhere sind beispielsweise C und Pascal, die niedere ist Assembler. Bei höheren Programmiersprachen wird der Quellkode in den Maschinencode compiliert, dieser greift zur Laufzeit auf eine von der Programmiersprache beigefügtes Laufzeitsystem zu, dieser wiederum auf Schnittstellen des Betriebssystems. Bei Assembler wird der Quellcode assembliert in den ablauffähigen Maschinencode, dieser greift auf die Schnittstellen des OS zu. Früher zur Zeiten von MSDOS wurde ganz oder teilweise auf die Hardware zugriffen, das lief bei Spielen schneller und die einfachen Betriebssystem wie CP/M und MSDOS boten auch noch keine Grafikroutinen oder Farbverwaltung.

[Baw 10]

Danke für eure schnellen antworten!

 

Hab kurz ein kleines Beispiel gemacht und ich glaube, dass ich schon einen guten Schritt weiter gekommen bin:

 

Erst einmal habe ich kurz eine Mini-Konsolen Anwendung in C# erstellt und kompiliert.

 

namespace ConsoleApplication1
{
   class Program
   {
       static void Main(string[] args)
       {
           Console.WriteLine("A");
       }
   }
}

 

Anschliessend habe ich die Datei wieder mit einem entsprechenden Dekompiler in Assembler übersetzt und war erstaund über das Ergebnis:

 

  
.method private hidebysig static void  Main(string[] args) cil managed
{
 .entrypoint
 // Code size       13 (0xd)
 .maxstack  8
 IL_0000:  nop
 IL_0001:  ldstr      "A"
 IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
 IL_000b:  nop
 IL_000c:  ret
} // end of method Program::Main

 

Entsprechend wird in C# vorher der System Namespace und in Assembler die mscorlib geladen.

Das heisst, dass ich auf Assemblerebene genau gleich auf die von Microsoft zur Verfügung gestellte DLL zugreife wie auf einer höheren Ebene.

 

Habe leider jetzt gerade keine Zeit um weiter zu schreiben, wo ich momentan noch ein ? habe: Woher weiss denn mein Programm (auf Assembler-Ebene) woher es den mscorlib nehmen soll?

[CPL386 10]

Darf ich auch mal was dazu sagen? :D

 

Wichtig zu verstehen ist dabei (meiner Meinung auch) dass Windows stark COM, DCOM und COM+ verwenden. Die sind Binärkompatibel aufgebaut, daher werden diese Funktionen auch direkt verwendet!

Das bringt ne menge "Bequemlichkeit" und auch Schutz da du auf die Funktionen von MS zugreifst die dann mit dem Kernel, Treibern usw. agieren können.

 

Zum Verständnis direkt wirst du (leider) kaum etwas finden aber bei MSDN findest du ne menge Infos über die Teile drum rum.

Ich fand Windows Internals und das Com-Komponentenbuch von Dr. Schwichtenberg zum Verständnis recht gut.

[Baw 10]

Natürlich darfst du ;)

 

Der Teil drum rum ist ja auch das was man benötigt, es sei denn du bist entwickler bei Microsoft o.Ä. ^^

Bin auch schon auf das Buch Windows Internals gestossen, soll angeblich recht gut sein, werde aber wahrscheinlich noch gleich auf die neue Version warten, erscheint im März 09, ausserdem werde ich mir vermutlich die deutsche Version kaufen wollen (bei 1300 Seiten für mich einfach angenehmer zu lesen) sprich werde nochmal etwas länger warten müssen...

 

Wie auch immer, für den Moment reicht mir das so (bin ja kein Entwickler :))