@hustbaer
Stimmt, den Assembler hatte ich überhaupt nicht mehr auf dem Schirm. Ich habe den ganzen Übersetzungsprozess in zwei Schritte eingeteilt: Übersetzen und Linken. Dass das Übersetzen in mehreren Schritten passiert habe ich nicht erwähnt, weil ich das, was intern passiert und nur Zwischenprodukte erzeugt/benutzt, für nicht relevant halte, zumindest in diesem Thread.
@tomycat2009
Du hast da sehr, sehr naive Ansichten. Nach dem Kompilieren wird aus WinMain nicht main, nach dem Kompilieren ist eine Funktion nur noch eine Adresse, sie hat nicht einmal mehr ihren Namen.
Jede Windows Anwendung hat einen, ich nenn´s mal "Starter-Stub", der die Umgebung für den zu startenden Prozess vorbereitet. Je nach Projekttyp gibt´s da unterschiedliche Stubs, die unterschiedliche Einsprungsfunktionen haben. Deshalb ist es bei Windowsprogrammen WinMain und bei Standard-C++ Programmen halt main. Der Compiler macht aus einer Funktion keine andere (macht ja auch keinen Sinn, weil eine Funktion nach dem Kompilieren ja eh nur noch eine Adresse ist).
Ich weiß auch nicht, warum du ständig von Textblöcken redest... das Einzige, das als echter Text vorliegt, ist der Quelltext. Der taucht im Executable aber nicht mehr auf, man kann aus einem C++ Executable den Quelltext nicht mehr rekonstruieren. Das, was du im Debugger siehst, sind Debug Informationen, die zusätzlich zum Binärcode vom Compiler erzeugt werden, und auch nur dann, wenn man dem Compiler sagt, dass er das tun soll (Debug-Build). Debug Builds sind häufig größer und langsamer als der Release-Build, deshalb benutzt man den Debug-Build zum Testen und Bugfixing, der Release-Build ist dann das, was man auf die Welt loslässt.
Das, was du als "Textblock II" bezeichnest, ist das, was der Debugger zusammen mit den Debug Informationen für dich visuell aufbereitet. In Wirklichkeit gibt es diesen "Textblock II" überhaupt nicht, das sucht sich der Debugger/IDE aus dem Binärcode, Quelltext und Debug-Informationen für dich zusammen.
