Hallo Leute, ich habe mir mal in den Kopf gesetzt, ein Windowsprogramm in Assembler zu schreiben. Dazu benutze ich den MASM32, der ja mitlerweile frei ist. Erste Fenster, Dialogboxen etc. kann ich schon erstellen und ich bin echt begeistert, wie extrem einfach und kurz sich so ein Assemblerprogramm gestaltet. Wenn man dann noch die high level syntax von MASM beherrscht, kommt man schon recht nah an C ran und programmiert aber trotzdem in reinem Assembler. Nun zu meinem Problem: ich habe ein kleines Tool geschrieben, welches mir in einer Messagebox die Anzahl der Millisekunden ausgibt, die seit dem letzten Windowsstart vergangen sind. Funktioniert auch perfekt, im Anhang Source und exe-File. Was mir aber nicht in den Kopf will ist, warum das exe-File nicht größer wird, wenn ich weitere Befehle einfüge. Z. B. ändert sich nichts an der Dateigröße, wenn ich 10 NOPs im Quelltext einfüge und neu kompiliere. Oder wenn ich mir dreimal hintereinander die Messagebox anzeigen lasse, ändert sich nichts. Hat da jemand eine Erklärung? Das zweite wäre, wie kann man das exe-File größenmäßig verkleinern? Ich habe mir es mal mit einem Hexeditor angesehen und festgestellt, daß sehr viele Nullen enthalten sind. Wenn man das File packt, gibts nur ein paar hundert byte. Vielleicht kann man das aber bereits vom Assembler/Linker machen lassen. Leider habe ich nichts gefunden. Wenn jemand eine Idee hat, wäre super. Ich vermute ja, daß die erwähnten 10 NOPs an die Stelle kommen, wo die Nullen stehen. Wäre dann aber nicht sehr effektiv vom Assembler. Danke! Gruß Jens
Ich sehe zwar nichts in Deinem ZIP-File, aber eine Vermutung: Die einzelnen Segmente werden vom Linker an 4 KB Grenzen ausgerichtet (<-- Linker, hat nichts mit dem Assembler zu tun!). Wenn Du weniger Code produzierst, wird entsprechend aufgefüllt. Du kannst also noch 100 NOPs tippen, und die Datei wird trotzdem nicht größer. BTW: Wenn du mit dem Schalter /OPT:NOWIN98 linkst, wird an 512 Byte Grenzen ausgerichtet.
Danke für den Tip, dieser Schalter scheint aber per default aktiv zu sein. Wenn ich ihn in /OPT:WIN98 ändere, wächst die Datei von 2560 Bytes auf 16384 Bytes an. Habe mit dem Hexeditor auch nochmal geschaut, die 512 Byte Grenzen kommen hin. Es geht dann also nicht kleiner?
Habe rumprobiert: mit den Schaltern /DRIVER und /ALIGN:4 lässt sich die Dateigröße auf 984 Byte reduzieren **FREU**
Unter DOS ging's noch kleiner. Da gab's nämlich .com-Files, die keinen Header hatten und dadurch WIMRE 256 bytes einsparen konnten.
.COM Dateien sind auch unter Windows XP/2000/98 noch ausführbar ob daraus aber Windows-Funktionen aufrufbar sind weiß ich nicht. Gruss
im prinzip würde ich ja einfach hergehn und z.b upx uber die .exe drüberjagen.. dann ist sie schön klein und alle sollten glücklich sein... wobei damit da was kleiner wird müsstest du ein prog haben, dass schon ein paar 100k groß ist.... dann wäre da noch die lustige idee selbst den header usw zu bastln ;) damit wirds dann wirklich klein... G und zum thema com files.... http://vx.netlux.org/lib/vlj02.html ist aufwendig G wobei ich mir nicht sicher bin, obs nicht schon hinhaut wenn du die lustigen libs reinholst.... wie gesagt bin mir nicht sicher... ich bevorzuge nochimmer inline asm beim reversen*g* und da auch nur die glue-logic um meine c/c++ dlls zu laden ... wie gesagt... probieren geht über studieren... mache eine .com und schau ob du das mit den win-libs compilieren kannst... wenn ja sollts eigetnlich kein problem geben... 73
> mache eine .com und schau ob du das mit den win-libs compilieren > kannst Jetzt überlegt Euch bitte mal, was ein COM File ausmacht. Dann sollte auch klar sein, daß das so nicht gehen kann. BTW: Aus rein nostalgischen Gründen suche ich gerade nach dem Thunk-Compiler. Ist der bei den aktuellen SDKs gar nicht mehr dabei?
Das mit UPX ist zwar gut, funktioniert jedoch bei den kleinen Dateien nicht. Der Packer bringt eine Fehlermeldung aus der hervorgeht, daß das File nicht packbar ist. Das mit den COM-Dateien kenne ich auch noch aus DOS-Zeiten, funktioniert aber unter Windows definitiv nicht, ich habs probiert.
> Das mit UPX ist zwar gut,
Das ist nicht gut, IMO. Du verschwendest damit jede Menge RAM,
besonders wenn Du mehrere Instanzen Deines Programmes laufen lässt.
Dagegen kannst Du die paar Bytes mehr auf der Platte locker
verschmerzen.
Bitte 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.