Compiler mit kleinsten Executables
-
Original erstellt von volkard:
DAber ne eigene Startup, die nochtmal die Konstruktoren globaler Objekte hochzeiht? Dan kann man nur in C machen.In meinem Artikel habe ich die eigene Startup aber behandeln muessen, da ich nodefaultlib erklaeren wollte.
Natuerlich hat es absolut keinen Sinn die Standard Library NICHT zu linken. dann braucht man ja kein C/C++ mehr Programmieren.
Normalerweise tun es dynamisches Linken der msvcrt.lib bzw. dynamisches linken der MFC und ein /opt:nowin98
dass ganze mit upx gepackt und die groesse ist minimal
hier gehts aber um extreme optimierung!
-
Weis denn niemand wo ich diese Funktionen finden kann?
MfG SideWinder
-
Ich weiß, dass ihr hier eigentlich nur über Compilerswitches reden wollt und keine Opcodes oder ähnliches hören wollt, aber ich konnte mich hier einfach nich zurückhalten meinen Senf dazu zu geben.
Also das kleinste Hello World für Windows, das ich je gesehen habe, war mit dem NASM erstellt und die compilierte Datei war nur ca. 650 bytes groß. Und dabei hätte man ruhig noch ein paar Bytes sparen können, denn da war noch ein wenig DOS Code für eine Message drin (die erscheint wenn man die EXE unter DOS startet, meist das typische "This program cannot be run under DOS").
Das kleinste Hello World für DOS (wahrscheinlich aber nur MS-DOS) ist folgendes:95 BA 07 01 CD 21 C3 68 65 6C 6C 6F 20 77 6F 72 6C 64 24
Ist wieder für eine COM Datei. 19 Bytes ohne CRLF. Das Ganze ist folgender ASM Code:
xchg ax,bp mov dx,offset msg int 21h retn msg DB "hello world$"
-
Von den 19 Bytes fällt ja das immer noch das meiste auf die "Hello World"-Nachricht. Aber wie gesagt, wir (eigentlich ich) will kein Assembler, kein Opt-Code, keine .com-Dateien.
Wie siehts eigentlich mit den Optimierungen noch aus, was benötigt jetzt noch immer so viel Platz?
MfG SideWinder
PS@malfunction: Ich würde mir Gedanken machen, deine Version weiter zu optimieren. Vielleicht schaffst du es ja den Text "Hello World" irgendwo auszulagern und die Auslagerung mit weniger Bytes zu öffnen?
-
@SideWinder: Ich glaube kaum, dass diese COM Datei noch kleiner geht. Das XCHG AX,BP (ein byte) ist ja schon ein kleiner undokumentierter Trick. Es ersetzt das MOV AH,09 (zwei bytes), weil das höherwertige Byte von BP zum Start des Programms aus irgendeinem komischen Grund immer gleich 09 ist.
Wenn ich den String auslagern soll, kann ich auch gleich den restlichen Code auslagern. Das wäre dann aber geschummelt. Da müsste dann ja nur ein Programm vorher ausgeführt werden, dass seinen eigenene Real Mode Interrupt installiert und dann bräuchte ich den im Hello World Proggie nur noch auszuführen -> 2 bytes
-
Wenn mans so sieht...aber im Grunde genommen habe ich bei der C++-Version auch nicht mehr gemacht. Habe vieles aus der MSVCRT.dll genommen, hab MFC dynamisch gelinkt, etc - andererseits sind die grundlegenden Dinge noch immer da.
MfG SideWinder
PS: Hello World mit 2Bytes ... kleiner wirds dann wohl keiner mehr schaffen...
-
Na die zwei Bytes würden ja nicht alleine laufen...
Aber die 19 sind echt MEEEGGGAAAA COOOOOOOLLLL
cu,
Lukas
-
Kenn mich da nicht so aus, aber wieso sollten die 2Bytes alleine nicht laufen?
MfG SideWinder
-
Nimm INT 3, das ist nur 1 Byte
(0xCC vs. 0xCD 0xnn)
-
Habe die Aussage:
Da müsste dann ja nur ein Programm vorher ausgeführt werden,
......so interpretiert, dass man damit die 2 Bytes ausgeführt werden können vorher noch ein anderes Programm gestartet werden muss. Das heisst die 2 Bytes wären "alleine" nicht lauffähig, man müsste vorher schon was getan haben, dass aber auch eine bestimmte länge an Code braucht...
Ja, hoffe keinen Denkfehler gemacht zu haben...
cu,
Lukas[ Dieser Beitrag wurde am 12.06.2002 um 21:48 Uhr von Consystor editiert. ]
-
Oje 19 Bytes. Mal gucken ob das Prog noch auf meine 21990232555520 Byte Festplatte draufpasst
:p 
mfg
PS: 21990232555520 bytes müssten doch rund 20 Gix sein, wenn ich mich nicht verrechnet hab.
-
Original erstellt von Chris++:
**Oje 19 Bytes. Mal gucken ob das Prog noch auf meine 21990232555520 Byte Festplatte draufpasst :p
**Die Kosten für den Verzeichniseintrag sind ja schon größer als der Datei Inhalt (nein, kein amerkanistischer Getrenntschreibfehler, that's Genitiv). Mit ner Clustersize von 16kb auf ner großen FAT-Platte kommste auf ein Schrott-Zu-Nutzdatenverhältnis von 800/1.
-
Ah... und das heißt?
-
das jedes programm immer nur auf der Festplatte in 16 kb schritten gespeichert wird
machst du Text Datei mit einem Zeichen -> 16 KB auf Festplatte weg, machst du Textdaei mit 16 KB und 1 Byte -> 32 KB weg usw... ist leider Verwaltungstechnisch nötig sonst würden da diverse Dinge vielzuviele Daten zu verwalten haben
-
Achso. D.H. ich müsste jetzt meine Zahl nochmal durch 16 teilen um an das richtige ergebniss zu kommen.
-
man nehme ein perfektes ffs dateisystem mit selbst festzulegender blockgröße und automatischer defragmentierung durch klasse (net)bsd dateisystemtechnik
-
@Chris++: Nein, eigentlich nicht. Du musst nur damit rechnen, dass eine Datei mit 1kb 16kb belegt. Die Größe herauszufinden ist unter Windows sehr einfach: Datei -> Rechtsklick -> Eigenschaften. Dann steht unter Größe, z.B.:
Größe: 1,50 KB (1.536 Byte), 16.384 Byte belegt
MfG SideWinder
-
Original erstellt von Chris++:
Oje 19 Bytes. Mal gucken ob das Prog noch auf meine 21990232555520 Byte Festplatte draufpasst :p Was, du hast eine 21 Terrabyte Festplatte ?
Vielleicht sollte ich mir auch so eine zulegen. Meine 100GB sind schon fast voll.[ Dieser Beitrag wurde am 13.06.2002 um 21:34 Uhr von DrZoidberg editiert. ]
-
http://www.farb-rausch.com/ -> look out for 16byte!!!! demo [fr-016]
-
jo, und bitte auch mal disassemblieren
versteht einer was da genau abgeht?