Entwickler-Ecke
Windows API - kleines Executable
ScaVo - Fr 05.11.10 14:00
Titel: kleines Executable
Sehr geehrte Community,
zur Zeit ist mir sehr langweilig, weshalb ich ein bisschen mit der Technik spiele. Nun stehe ich allerdings vor einem Problem, bei welchem ich keine Ahnung habe wie ich vorgehen soll. Wie bekomme ich eine "kleinst"-Exe hin? Alle meine Ansprüche sind eigentlich der Zugriff auf die Standart Datentypen (extended, integer, word, string...) sowie auf einen eigenen Handle(hWnd). Und genau bei dem letzten Anspruch ist mein Problem. Was muss ich schreiben um so einen (eigenen), möglichst platzsparenden, Handle zu bekommen?
(Und wieso ist ein Programm welches ohne Einbindung von irgendetwas ist, also nur begin end., 14kB groß???)
F34r0fTh3D4rk - Fr 05.11.10 14:22
Wenn dir wirklich sehr langweilig ist, und du eine kleinst-Exe hinbekommen möchtest, kannst du es ja mal mit Assembler probieren.
ScaVo - Fr 05.11.10 14:57
Soooo langweilig ist mir dann doch nicht xDD (da DX, in welches ich mich gerade einarbeite (64k Demo etc) nicht unbedingt Assembler braucht - und ich nunmal Pascal schon kann und entsprechende Header habe)
~EDIT~ Danke an Nersgatt, hat geholfen
Martok - Fr 05.11.10 15:34
Wenn du bei Pascal bleiben willst, kommst du nicht wesentlich weiter runter als ein Hello World mit {$APPTYPE CONSOLE}. Um noch kleiner zu werden, brauchst du eine alternative RTL, die auf Größe optimiert ist. Links hab ich da keine, aber Google bestimmt.
Bergmann89 - Fr 05.11.10 15:51
Hey,
gabs nich auch ma so ne Art selbstverpackende bzw. selbstentpackende Exe? Die waren dann deutlich kleiner als die normalen Exen, haben sich beim start entpackt und dann den entpacken Code ausgeführt. Kann aber auch sein, das ich da grad was verdreh ^^
MfG Bergmann.
Nersgatt - Fr 05.11.10 15:55
Doch, das gibts. Aber das lohnt sich erst bei einer bestimmten Größe, da der Platz, den der Entpacker braucht ja auch erst mal eingespart werden muss. Außerdem werden diese gepackten EXE gern mal als Trojaner erkannt, eben weil sich Trojaner manchmal so tarnen.
Und zu guter letzt: in Zeiten, wo ne 1 Terrabytefestplatte 44,99 EUR kostet, muss man wirklich nicht mehr auf ein paar Byte schauen, die die Exe belegt.
Bergmann89 - Fr 05.11.10 16:07
Hey,
schon klar, das Speicherplatz in der heutigen Zeit kein ewirkliche Rolle mehr spielt, aber es ist ja der Kniff an der Sache das so klein wie möglich zu bekommen. Siehe
Breakpoint [
http://de.wikipedia.org/wiki/Breakpoint] (auch wenn es da nicht nur um die Größe der Datei geht).
MfG Bergmann.
ScaVo - Fr 05.11.10 16:09
Wie geschrieben - ein bisschen langeweile. Aber die 300kB waren mir dann doch zu groß, bin jetzt bei weniger als zwei Zehntel inklusive ein kleines bisschen DirectX xD
BenBE - Fr 05.11.10 19:21
Weil du wegen der Größe gefragt hast:
Selbst wenn man bei DElphi keine weiteren Units einbindet, bindet de Compiler 2 Units IMMER ein. Die erste ist SysInit, die andere ist System. Beide werden implizit eingebunden und dürfen nicht explizit aufgeführt werden.
Die Unit System stellt alle wesentlichen Deklarationen bereit, um mit den Datentypen zu arbeiten und enthält zudem einen großteil der Compiler Magic.
Die Unit SysInit wiederum enthält den gesamten Code, der zum Start eines Delphi-Programms notwendig ist und liefert u.a. auch den Code-Einsprungpunkt für die Anwendung (die Main-Routine). Dieser liegt, anders als vom Debugger behauptet, nämlich nicht in der Projektdatei ;-)
Es gibt Möglichkeiten, beide dieser Units selbst zu beeinflussen, was aber zur Folge hat, dass man ALLE Delphi-Units von Hand selbst noch einmal übersetzen muss.
delfiphan - Fr 05.11.10 19:26
Mach doch eine .NET Applikation. Eine WPF GUI Applikation mit einem Knopf braucht vielleicht 8 KB.
Nersgatt - Fr 05.11.10 19:47
 delfiphan hat folgendes geschrieben  : |
| Mach doch eine .NET Applikation. Eine WPF GUI Applikation mit einem Knopf braucht vielleicht 8 KB. |
lol, wenn man vom "kleinen" Framework absieht, dass man noch mitschleppen muss. :D
glotzer - Fr 05.11.10 19:53
kleiner gehts nicht :p
delfiphan - Fr 05.11.10 20:01
Das Framework gehört zum Betriebssystem. Ohne Betriebssystemaufrufe kannst du sowieso keine sinnvolle Applikation schreiben.
SAiBOT - Fr 05.11.10 20:56
Es gibt doch dieses "Delphi 7 RTL replacement". Damit kann man eine Konsolenanwendung von 7kb kompilieren, ohne auf irgendwelche Funktionen zu verzichten. Das ist das komfortabelste was ich kenne.
| glotzer hat folgendes geschrieben : |
| kleiner gehts nicht :p |
Ich wette das ist ein Virus, kann das mal jemand reversen :mrgreen: ?
glotzer - Fr 05.11.10 20:58
wie soll das ein Virus sein mit einer byte größe?
nen es mal kleinsteExe.txt und schaus dir an :p
Delete - Sa 06.11.10 04:55
Na toll, eine Messagebox. Was will ich mit einem Programm mit keiner Funktionalität außer beweisen, dass es auch kleiner geht?
spawn89 - Sa 06.11.10 13:28
| Luckie hat folgendes geschrieben : |
| außer beweisen, dass es auch kleiner geht |
Du hast es erfasst. Es geht nativ. :D
Implementation - Sa 06.11.10 17:43
| delfiphan hat folgendes geschrieben : |
| Das Framework gehört zum Betriebssystem. Ohne Betriebssystemaufrufe kannst du sowieso keine sinnvolle Applikation schreiben. |
Das .NET-Framework? Nicht ganz. Das muss zuinstalliert werden und liegt AUF dem Betriebssystem.
Wenn man miteinrechnet, dass normale Delphi-Exen standalone laufen, ohne dass man etwas anderes erst installieren muss, sind sie insgesamt dann doch DEUTLICH kleiner als .NET-Anwendungen.
Du darfst nicht einfach auf die Größe der Exe selbst schauen!
delfiphan - So 07.11.10 01:10
.NET ist
"integral part of Windows" [
http://msdn.microsoft.com/library/zw4w595w.aspx].
Ausser du bist vielleicht noch auf dem Stand von 2 Generationen früher (Windows XP), was von Microsoft nur noch im Extended Support ist.
| Implementation hat folgendes geschrieben : |
| Du darfst nicht einfach auf die Größe der Exe selbst schauen! |
Wenn du denkst, dass ich das nicht darf, bist du off-topic ;);)
Willst du damit sagen, dass "Standalone Delphi-Exen" keine Abhängigkeit zum Betriebssystem haben und das Programm von vorhin z. B. die MessageBox mit Magie zeichnet? ;)
Spass beiseite - Fakt ist, in den neueren Versionen von Windows ist .NET mit dabei und du kannst kleine Anwendungen schreiben, ohne auf kompliziertes non-VCL zurückgreifen zu müssen. Möglichst kleine Exe ist nicht unbedingt das Verkaufsargument von Delphiapplikationen. Wer es sich (gerade deswegen) zum Sport macht, eine Mini-App mit Delphi zu schreiben, darf das gerne tun. Allzu sinnvoll ist es aber nicht.
spawn89 - So 07.11.10 03:25
Na wenn es dann sinnvoll ist seine Platten mit Backups von VMs voll von unnötigem Balast ala .Net, Java, whatever zu füllen, dann ist ja alles gut.
jaenicke - So 07.11.10 03:55
Dafür bieten diese Frameworks auch viele Vorteile. Und bei dem bisschen Speicherplatz. :nixweiss:
Da nehmen andere Sachen viel mehr Platz weg. Meine Entwicklungspartition alleine ist mehrmals so groß wie Windows 7 mit allen installierten Programmen.
FrEaKY - So 28.11.10 20:14
| Nersgatt hat folgendes geschrieben : |
Doch, das gibts. Aber das lohnt sich erst bei einer bestimmten Größe, da der Platz, den der Entpacker braucht ja auch erst mal eingespart werden muss. Außerdem werden diese gepackten EXE gern mal als Trojaner erkannt, eben weil sich Trojaner manchmal so tarnen.
Und zu guter letzt: in Zeiten, wo ne 1 Terrabytefestplatte 44,99 EUR kostet, muss man wirklich nicht mehr auf ein paar Byte schauen, die die Exe belegt. |
Ist eine Frage des Skills oder nicht? Warum soll ich zusätzliche 350 kb in mein Programm packen, die ich nicht benötige? Wenn du 10.000 Euro auf dem Konto hast, schmeißt du dann auch einfach 300 Euro aus dem Fenster, weil ja noch genug übrig ist?
Ich finds echt arm wie heuzutage die meisten Programme hier wo fast nichts drin ist, schon auf 500-800kb kommen.
FrEaKY - So 28.11.10 20:19
| delfiphan hat folgendes geschrieben : |
| Das Framework gehört zum Betriebssystem. Ohne Betriebssystemaufrufe kannst du sowieso keine sinnvolle Applikation schreiben. |
Nö tut es nicht. Nicht jeder müllt seinen Computer voll mit allem möglichen unnützen Zeugs.
jaenicke - So 28.11.10 20:35
| FrEaKY hat folgendes geschrieben : |
| Nö tut es nicht. Nicht jeder müllt seinen Computer voll mit allem möglichen unnützen Zeugs. |
Nicht jeder verzichtet auf nützliche Funktionen nur weil es von MS kommt. :nixweiss:
Martok - So 28.11.10 21:27
Das Framework ist kein Teil vom Betriebssystem, genausowenig wie die MSCVRT ein Teil vom Betriebssystem ist.
Es ist nur zufällig auf neueren Windows-Versionen vorinstalliert!
Anders sieht das in Singularity aus, in dem .NET die Win32-API komplett ersetzt. Aber solange das nicht am Markt ist, hat
FrEaKY vollkommen Recht.
.NET 1.1 ... 2.0 macht übrigens 22% meines WINNT-Verzeichnisses auf dieser Maschine aus... und beim .NETfx 3.5 ist der Installer allein 10mal so groß. Was dabei rauskommt weiß ich allerdings nicht, ist nirgendwo installiert ;)
Darf ich an die Signatur vom
MrSaint erinnern?
"people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems
jaenicke - So 28.11.10 21:35
| Martok hat folgendes geschrieben : |
| .NET 1.1 ... 2.0 macht übrigens 22% meines WINNT-Verzeichnisses auf dieser Maschine aus... und beim .NETfx 3.5 ist der Installer allein 10mal so groß. Was dabei rauskommt weiß ich allerdings nicht, ist nirgendwo installiert ;) |
.NET 1.1 bis 4.0 brauchen bei mir ca. 700 MiB. Mein Windows Verzeichnis ist etwas über 20 GiB groß, wovon ca. 9 GiB im winsxs Ordner (und damit teilweise redundant) sind.
// EDIT:
| Martok hat folgendes geschrieben : |
Darf ich an die Signatur vom MrSaint erinnern?
"people knew how to write small, efficient programs [...], a skill that has subsequently been lost"
Andrew S. Tanenbaum - Modern Operating Systems |
Es ist ja nicht so, dass ich keine kleinen Programme schreiben
kann. Aber klein und effizient passt oft nicht zusammen. Denn da das Programm klein sein muss, muss man vor allem darauf achten und kann weniger auf Effizienz achten. Und dass man wenig Speicherplatz verwendet, hat nicht viel mit Effizienz zu tun. Was nutzt ein winziges Tool, das dafür langsam und von der Oberfläche her unproduktiv ist?
Die vielen non-VCL Spielereien, die es immer wieder gibt, sind das beste Beispiel dafür...
Durch das .NET Framework kann man sehr effizient programmieren ohne stattdessen sehr viel Code für den gleichen Zweck zu schreiben. Und die Geschwindigkeit von Delphiprogrammen oder .NET Programmen steht handoptimierten Assemblerprogrammen nicht viel nach. Je nach Kenntnisstand des Entwicklers sind die manuell optimierten Programme oft auch langsamer.
Delete - So 28.11.10 21:47
| FrEaKY hat folgendes geschrieben : |
Ist eine Frage des Skills oder nicht? Warum soll ich zusätzliche 350 kb in mein Programm packen, die ich nicht benötige? Wenn du 10.000 Euro auf dem Konto hast, schmeißt du dann auch einfach 300 Euro aus dem Fenster, weil ja noch genug übrig ist?
Ich finds echt arm wie heuzutage die meisten Programme hier wo fast nichts drin ist, schon auf 500-800kb kommen. |
Na dann schreib doch alles in ASM oder gleich im Machinensprache. Merkst du wohin der Zug fährt? Frameworks erzeugen eben einen gewissen Overhead, dafür hast du aber auch einfacher beim Programmieren und sparst Zeit, Mühe und die Programme sind wartbarer. Zeit ist heute Geld. Und die paar Bruchteile eines Cents die heute Festplattenspeicher kostet, simd vernachlässigbar. Eher müllst du dir deine Festplatte mit Bildern, Videos und Musik zu als mit Exe-Dateien.
Moderiert von Martok: Quote repariert.
Delphi-Laie - So 28.11.10 22:21
| ScaVo hat folgendes geschrieben : |
| Wie bekomme ich eine "kleinst"-Exe hin? |
Hängt alles nur von der Funktion dieser "exe" ab.
Auch wenn Exe und Com intern ein anderes Format haben, so kann man - nach meiner Beobachtung - Exe in Com umbenennen und umgekehrt, ohne daß die Funktionalitäten leiden.
Die mit sehr großer Wahrscheinlichkeit kleinste (sinnvolle) Com, die es jemals gab, schrieb ich vor knapp 20 Jahren, und zwar bestand sie nur aus 2 Byte und hatte dennoch eine sinnvolle Funktion: In Assembler bestand sie aus der einzigen Funktionszeile
Int 19 (oder Int $19?)
, und nach dem Assemblieren löschte ich alles in der Com-Datei, was noch "drumherum" war, so daß wirklich nur noch die beiden Bytes (eines für Int und eines für 19) übrigblieben.
Int 19 ist ein Hardwareinterrupt für Reboot, der/das - abhängig von der Hauptplatine - unter DOS tatsächlich zu einem Reboot führen konnte.
Dies 2 Bytes wollen jetzt nur noch unterboten werden - wer bietet weniger?
BenBE - Di 30.11.10 08:47
@Luckie: Ich darf doch mal:
Diesen Link kennst Du doch hoffentlich? [
http://discuss.joelonsoftware.com/default.asp?joel.3.219431]
Nicht!? Lies ihn doch einfach mal ;-)
Die Idee hinter Frameworks ist durchaus gut und lobenswert, aber nicht immer ist es sinnvoll für ein Küchenrack eine Generische Tool Building Factory Factory Factory zu betreiben.
Ich wünsch mir schon seit Jahren, dass ich beim Compilieren einer VCL-Anwendung konfigurieren kann, welchen Kram er aus der VCL in die EXE packt und auf welche Sachen ich gut verzichten kann.
Es mag zwar schön sein, nicht alle Sachen erneut schreiben zu müssen, aber kann man das nicht irgendwo reduzieren, dass man analog wie unter Linux einmal üblich gewesen, die Funktionen alle in Libs auslagert und das Programm im Wesentlichen nur noch ein Stub zum Aufruf der Lib ist?
jaenicke - Di 30.11.10 09:47
| BenBE hat folgendes geschrieben : |
| Es mag zwar schön sein, nicht alle Sachen erneut schreiben zu müssen, aber kann man das nicht irgendwo reduzieren, dass man analog wie unter Linux einmal üblich gewesen, die Funktionen alle in Libs auslagert und das Programm im Wesentlichen nur noch ein Stub zum Aufruf der Lib ist? |
Das nennt sich Runtime Package.
spawn89 - Di 30.11.10 10:26
Man sollte aber schon zwichen
- Gb großen Zwangsframeworks mit weltweit massig verschiedenen Versionen, die aber generell dem Kunden rein gar nichts bringen (.Net, JavaVMs)
und
- nativen Frameworks, die genau das gleiche können und vom Compiler in die Exe optimiert/reduziert werden
unterscheiden
jaenicke - Di 30.11.10 11:22
| spawn89 hat folgendes geschrieben : |
| nativen Frameworks, die genau das gleiche können |
Genau das stimmt ja absolut nicht. .NET hat Features, von denen man als Delphientwickler (ohne Prism) nur träumen kann. Und wofür man tausend externe Bibliotheken oder sehr viel eigenen Code bräuchte.
Ich nutze trotzdem lieber Delphi, aber dieses Argument stimmt nicht.
spawn89 - Di 30.11.10 11:30
Sorry, ich meinte es im Sinne von: "auf den gleichen Features des OS basieren"
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!