Lazarus, EXE groß

[Medium]

Zitat von himitsu:

siehe die geilen 64K-Programme

Von denen sind, neben gelegentlichen Handassemblierungen, fast alle aber auch gepackt (Selten UPX, oft .kkrunchy, ab und an Eigenbauten der jeweiligen Crews)

@Topic:
Als Fan von beidem, kleinen Executables und komfortablen wartbarem Code, empfinde ich das Thema oft als Gratwanderung. Kleine Dateien erzeugen irgendwie einen Eindruck von "oh, da hat sich der Herr Compiler aber viel Mühe gegeben beim Optimieren, diese Sorgfalt legt er sicher auch an anderen Stellen an", wenn ich mir das aber über Einbußen im Umgang mit meinem Code erkaufen muss, entgleitet das zu einer Art Kunstform, die ich eher in meiner Freizeit zur Befriedigung meines Perfektionsdranges bei Nebensächlichkeiten sehe. Wenn ich mit Code Geld verdienen will, müssen die Quellen allen Komfort und zurück zulassen, da kümmert mich die Größe nicht mehr. Es sei denn es artet so weit aus, dass die Portabilität leidet. Nicht die zwischen diversen OS, sondern von mir zum Kunden. Die Größe darf meinetwegen hier also gerne mit den verfügbaren Übertragungswegen und Speichermedien mitwachsen, und das wäre das andere Ende meiner Gratwanderung.

Ob ich nun ein Framework brauche oder nicht, ist mir im Grunde auch fast egal. So lange es eines der auf Endanwender weit verbreiteten ist (im Prinzip .NET und JRE), und somit einen Quasi-Standard bildet, soll es mir eben so recht sein wie statisches Linking. Die angestellten Vergleiche hier sind teils wirklich recht... unbrauchbar und kaum ein Maß, und ich bezweifle, dass es da ein allgemeingültiges und rein technisch begründbares gibt. Hier ist einfach viel Präferenz im Spiel. Seitens des Entwicklers und auch des Kunden, und so lange beide mit einer Lösung leben können ist alles gut. Wenn nicht, dann hat der Kunde ein Programm, und der Dev einen Kunden weniger. Ob es einem von beiden wert ist seine Vorlieben zu ändern (und ggf. nen Stück Arbeit in Kauf zu nehmen) ist dann jedem selbst überlassen. Die Tools an sich sind alle gut, manche für Dinge besser als andere und umgekehrt, womit wieder einmal gilt: Das passende Werkzeug für die Aufgabe zu wählen ist schon halb programmiert Und wenn das Ziel kleine EXEn sind, dann war der Griff nach Delphi/FPC halt einfach schlecht. Als Entwickler ist es eben auch meine Aufgabe, zu wissen womit ich mein Ziel am besten erreiche. Wenn ich nachher feststelle, dass meine Wahl Murks war, dann kann man zwar nach Verbesserungen suchen, aber sicher nicht dem Tool die Schuld an meiner mangelnden Expertise/Recherche geben.

@Lazarus: Die Namen der Optionen sind allerdings wirklich etwas missverständlich . Solche Infos dürften da mindestens in Form eines Hits rein, oder aber gleich die Optionen so nennen, dass es eindeutig ist. Ich hätte das auch nie erahnt.