4. Compiler mit kleinsten Executables

Compiler mit kleinsten Executables

  • ?

    Zugegeben, es entspricht nicht den Vorgaben aber meine 50 Bytes schlägt so schnell keiner:

    B4 02 B2 48 CD 21 B2 65 CD 21 B2 6C CD 21 B2 6C
    CD 21 B2 6F CD 21 B2 20 CD 21 B2 57 CD 21 B2 6F
    CD 21 B2 72 CD 21 B2 6C CD 21 B2 64 CD 21 B4 B2
    CD 21

    Im Hexeditor eingeben, mit der Endung .com speichern, von der Konsole aus aufrufen et voila: Hello World

    #include <fstream>
#include <string>

#define INT     0xCD
#define MOV_AH  0xB4
#define MOV_DL  0xB2

int main(int argc, char* argv[]) {
 int i;
 char ch;
 string sText, sCode;

 sCode  = MOV_AH;
 sCode += 0x02;

 if (argc == 3)
 {
  ifstream in(argv[1], ios::in | ios::nocreate | ios::binary);

  while (!in.eof())
  {
   ch = in.get();
   i = ch;
   if (!in.eof())
   {
     sCode += MOV_DL;
     sCode += ch;
     sCode += INT;
     sCode += 0x21;
   }
  }

  sCode += MOV_AH;
  sCode += 0x4C;
  sCode += INT;
  sCode += 0x21;

  ofstream out(argv[2], ios::out | ios::binary);
  out << sCode;
 }
 else
 {
  cout << "Usage: txt2com [file.txt] [file.com]" << endl;
 }

 return 0;
}
    0
  • C

    Hi!!!

    Naja, ich würde sagen, dass deine 50 Bytes super sind, aber nicht perfekt:

    Das hier sind 24 Bytes:
--- START ---
b4 09 ba 0b 01 cd 21 b4 4c cd 21 48 61 6c 6c 6f 20 57 65 6c 74 0a 0d 24
--- ENDE  ---

oder 22 Bytes (ohne lf und cr)
--- START ---
b4 09 ba 0b 01 cd 21 b4 4c cd 21 48 61 6c 6c 6f 20 57 65 6c 74 24 
--- ENDE  ---

    In Hexeditor eingeben, als Hallo.com speichern und ausführen.

    cu und machs gut,
    Lukas

    PS:

    Habe dann auch noch den Code über mir etwas geändert.
    So kriegt jeder die kleineste Datei hin!

    #include <string>
#include <fstream>

#define INT     0xCD
#define MOV_AH  0xB4
#define MOV_DX  0xBA

using namespace std;

int main(int argc, char* argv[]) {
 int i;
 char ch;
 string sText;
 string sCode;

 if (argc == 3)
 {
  ifstream in(argv[1], ios::in | ios::nocreate | ios::binary);

  sCode += MOV_AH;
  sCode += 0x09;
  sCode += MOV_DX;
  sCode += 0x0B;
  sCode += 0x01;
  sCode += INT;
  sCode += 0x21;
  sCode += MOV_AH;
  sCode += 0x4C;
  sCode += INT;
  sCode += 0x21;

  while (!in.eof())
  {
   ch = in.get();
   sCode += ch;
  }

  sCode += '$';

  ofstream out(argv[2], ios::out | ios::binary);
  out << sCode;
 }
 else
 {
  cout << "Usage: txt2com [file.txt] [file.com]" << endl;
 }

 return 0;
}

    cu und viel Spass beim Coden,
    Lukas

    [ Dieser Beitrag wurde am 09.06.2002 um 22:37 Uhr von Consystor editiert. ]

    0
  • ?

    Meinen Glückwunsch... Eine schöne Demonstration wie schön man mit Hexeditor und Opcodetabelle programmieren kann.

    0
  • C

    MEEGAAA THNNNX FÜRS LOOOB!!!
    Aber die Initiative ging von Dir aus!!!
    🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

    cu,
    Lukas

    0
  • S

    Mhm, also kleiner als 1.024 Bytes bekomme ich es nicht 😞
    1KB ist einfach, aber da will dann nichtmal mehr upx packen 😞

    0
  • S

    Wir wollten eigentlich keine Optimierungen mit irgendwelchen Hex-Editoren ... da erfahr ich nicht viel über die Übertaktmöglichkeiten von Compilern ;).

    @Shade: Du hast Hello World auf 1024Bytes - compiliert oder nachbearbeitet?

    BTW: Tip für alle Coder: Die <iostream> in ein Projekt einzubinden ist sehr, sehr teurer. Man sollte lieber über die C-Standard-Variante oder über die WinAPI gehen.

    MfG SideWinder

    0
  • S

    Original erstellt von SideWinder:
    @Shade: Du hast Hello World auf 1024Bytes - compiliert oder nachbearbeitet?

    Faul wie ich bin, habe ich lediglich deine Version optimiert.

    Aber 300 Bytes mehr oder weniger sind ja egal 😉 ich wollt nur etwas aufschneiden 😉

    Der 'Trick' liegt darin, keine default librarys einzubinden. Man braucht lediglich die die kernel32.lib fuer die 2 Funktionen.

    dadurch muss man statt main halt mainCRTStartup schreiben, aber das sollte egal sein.

    Kleiner gehts AFAIK nicht mehr.
    Vor einiger Zeit habe ich fuer GermanDevNet einen kleinen Artikel darueber geschrieben

    Allerdings habe ich dort das 'merge' von Segmenten nicht behandelt, da das IMHO zu fehleranfaellig ist, als das ich es wirklich verwenden wuerde (es sei denn fuer so kleine Optimierungsspielchen wie hier)

    [nachtrag]Natuerlich auf 1.024 Bytes Compiliert.
    upx will es naemlich ned mehr komprimieren :([/nachtrag]

    [ Dieser Beitrag wurde am 10.06.2002 um 14:44 Uhr von Shade Of Mine editiert. ]

    0
  • S

    Kleiner gehts AFAIK nicht mehr.

    Sag niemals nie...

    Werd mir noch den Artikel auf der MS-Page durchlesen, vielleicht lässt sich ja noch was rauskratzen :).

    MfG SideWinder

    Edit: Hab gar nicht gewusst, dass du Anton heißt.

    [ Dieser Beitrag wurde am 10.06.2002 um 14:52 Uhr von SideWinder editiert. ]

    0
  • S

    Ich fasse mal zusammen, was es alles so gibt:

    // Vorcompilierter Header "smallwin.h"
#ifndef SMALLWIN_H
#define SMALLWIN_H

    #ifdef NDEBUG

        #pragma optimize ( "gsy" , on )
        #pragma comment ( linker , "/RELEASE" )

        #ifdef _MERGE_RDATA_

            #pragma comment ( linker , "/merge:.rdata=.data" )

        #endif

        #pragma comment ( linker , "/merge:.text=.data" )
        #pragma comment ( linker , "/merge:.reloc=.data" )

        #pragma comment ( linker , "/ignore:4078" )

        #if _MSC_VER >= 1000

            #pragma comment ( linker , "/opt:nowin98" )

        #endif

    #endif

    #define WIN32_LEAN_AND_MEAN
    #include <windows.h>

    int WINAPI WinMainCRTStartup ()
    {
        // Wir bieten absolut keinen Komfort, die Parameter werden nicht übergeben. iCmdShow wird mit Standardwerten gefüllt.

        int Main (
                      WinMain ( GetModuleHandle ( 0 ) , 0 , 0 , SW_SHOWDEFAULT )
                 );

        ExitProcess ( Main );

        return ( Main );
    }   

#endif

// Quellcodedatei "hw.cpp"
#include "smallwin.h"

int WINAPI WinMain ( HINSTANCE hInst , HINSTANCE hPrev , LPSTR szCmdLine , int iCmdShow )
{
    DWORD dw1 ( 0 );
    WriteConsole ( GetStdHandle ( STD_OUTPUT_HANDLE ) , "Hello World" , 11 , &dw1 , 0 );

    return ( 0 );
}

    Das ist so ziemlich das kleinste was man hin bekommen kann. Sogar die interne Startup-Funktion des Compilers wird frisch geschrieben: Das Ignorieren der Standardlibs wird dadurch aber zwingend.

    Jetzt muss man nur noch die optimalen Linkereinstellungen finden.

    MfG SideWinder

    0
  • V

    Das mit den Segmenten halt ich eher für unkritisch, weshalb ich eich bei größeren Progs wenig Angst hätte. Aber ne eigene Startup, die nochtmal die Konstruktoren globaler Objekte hochzeiht? Dan kann man nur in C machen.

    0
  • D

    @Consystor: Das Programmm ist nur 21 byte groß, wenn du zum Beenden ein int 20 benutzt.

    0
  • S

    @volkard: Bei Hello World hoffe ich ja doch noch ohne Konstruktoren auszukommen. Aber du hast recht bei größeren Projekten ist es ziemlich kritisch. Wie schaut das dann eigentlich aus? Muss ich da in jeden Konstruktor das Gleiche schreiben was auch der Compiler vorne reinschreiben würde? Oder wird der Konstruktor bei static-Objekten dann erst gar nicht aufgerufen, und es geht nach dem Motto selbst ist der Mann?

    MfG SideWinder

    0
  • V

    Der Compiler baut Dir schon ne gobale Liste von void-Funktionen, die Du aufrufen sollst. Ganz gemein ist er der startup() gegenüber nicht.

    0
  • S

    Wo findet man die beim MSVC? In welchem Header findet man eigentlich überhaupt die normale Startup? Weiß das jemand?

    MfG SideWinder

    0
  • C

    @DrZoidberg

    Sehr gut, das ist ja noch besser!!!

    cu,
    Lukas

    0
  • V

    Header? Wird nicht benötigt, die Funktion zu deklarieren.

    0
  • S

    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!

    0
  • S

    Weis denn niemand wo ich diese Funktionen finden kann?

    MfG SideWinder

    0
  • M

    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$"
    0
  • S

    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?

    0
Anmelden zum Antworten