4. Gewisse Packages gezielt ausschließen

Gewisse Packages gezielt ausschließen

  • F

    Ja, die Stärken kenne und liebe ich, nur programmiere ich derzeit halt eher wenige große Projekte (bei denen 3,5MB jetzt zu verkraften sind 🙂 ) ich programmiere halt eher kleinere Sachen und da ist es schon ärgerlich, wenn ich da jedes mal mit 3,5MB rummachen muss o:

    Wäre nett, wenn ihr dazu mal Stellung nehmen könntet:

    C++ Builder XE3 vs:

    1. Netbeans + Qt + MiNGW (exe ist ca 700kb groß)
    2. VC++ native [der native Code] und mit C# die Oberfläche

    0
  • N

    Hallo,

    ich antworte mal hier, auch wenn du in einem zweiten Thread etwas ganz ähnliches gefragt hast.

    Für kleine Tools, die vom USB-Stick aus eingesetzt werden, habe ich auch den C++ Builder eingesetzt, von der ersten Version bis XE2. Mittlerweile bin ich aber vollständig zu Visual Studio gewechselt, mit C# Anwendungen und nativen C++ DLLs.

    Da diese Tools nur auf anderen PCs eingesetzt werden, wo schon andere Software von uns installiert ist, brauche ich mich allerdings nicht um das Vorhandensein des passenden .net Frameworks sorgen. Das kann man als gegeben ansehen.

    Die Dateigrößen sind wirklich klein, z.B. bei einem Tool, das über serielle Schnittstelle Einstellungen an angeschlossen Geräten vornimmt, um die 50 kB für den C# Teil und 250 kB für die statisch gelinkte DLL. Die Vorgängerversion hatte mit dem BCB 6 etwa 2,7 MB und mit XE2 etwa 4 MB.

    Aber bei den Größen heutiger Sticks spielen diese Größenunterschiede keine wirkliche Rolle. Die Startzeit der .net Anwendungen dürfte etwas höher sein, aber das nimmt man nicht wirklich wahr.

    In dem anderen Thread schreibst du, dass du den BCB verwendest, weil er moderne Standards einhält. Nun ist VC++ was C++11 angeht, sicher kein Vorbild, aber beim BCB ist man bei modernem C++ auf 64-Bit Windows beschränkt, das ist aber für meine Tools ein Ausschlusskriterium. Außerdem sind 64-Bit Programme meist etwas größer als 32 Bit, mit allen Compilern.

    Wenn du wirklich kleine WinAPI-Programme machen willst, schau dir vielleicht mal die Hilo-Beispiele in der MSDN an.
    http://msdn.microsoft.com/en-us/library/windows/desktop/ff708696.aspx

    0
  • F

    Naja, ich habe vorher immer C# programmiert, nur was das wirklich extrem langsam. Allein, als ich ne Form mit ca. 100 Buttons hatte, hat man wirklich zuschauen können, wie das Programm erst ewig gebraucht hat und dann immer 3 Buttons nacheinander geladen hat 😃 Schade, dass ich wirklich so fette Exen habe, aber ich kann ja auch für kleinere Exen zu VC++ greifen, ich denke nicht dass das großartig langsamer ist, wenn nur die GUI in .NET ist. Vor allem brauch ich dann auch nur 2 Sekunden um das ganze im BCB zu machen 🙂

    0
  • A

    Frolo schrieb:

    Naja, ich habe vorher immer C# programmiert, nur was das wirklich extrem langsam. Allein, als ich ne Form mit ca. 100 Buttons hatte, hat man wirklich zuschauen können, wie das Programm erst ewig gebraucht hat und dann immer 3 Buttons nacheinander geladen hat 😃

    War das mit WinForms oder mit WPF? (Und 100 Buttons auf einer Form, kann das wirklich sinnvoll sein?)

    Für Kleinigkeiten sind Delphi und C++Builder gut geeignet, allerdings habe ich auch wenig Verständnis für die Aufgeblasenheit der letzten Releases. Wenn du ein paar Releases zurückgehst (2007, 2010 oder XE), bleiben die Kompilate in überschaubaren Größenverhältnissen.

    Qt wird gerne als zeitgemäße Alternative zum C++Builder genannt, und die Tools sind auch gut, wenn man die VS-Integration nutzt (der Debugger in Qt Creator ist recht beschränkt, da gdb-basiert); aber die Ergebnisse fand ich noch nicht überzeugend. Desgleichen in bezug auf WPF. Sowohl Qt- als auch WPF-GUIs weichen im Look & Feel geringfügig von gewöhnlichen Windows-GUIs ab, und das fand ich bisher immer störend genug, um sie nicht zu verwenden.

    Wie es mit WinForms steht, weiß ich nicht, aber die Bibliothek hat prinzipbedingt viele ähnliche Probleme wie die VCL und ist seit Jahren bei v2.0 stehengeblieben.

    0
  • F

    Ich habe neben der XE3 auch noch die 2010er Version und da sind die Kompilate wirklich unter 1MB was ich für gut halte. Ich mag einfach nicht an das Framework gebunden sein, vor allem, da jetzt alle in 4.0 programmieren, weil Windows 8 das 3.5 nicht mehr standartmäßig drauf hat. Ich weiß nicht. Aufwändige Projekte hingegen würde ich schon lieber mit dem C++ Builder programmieren, oder haben da andere IDEs Vorteile?

    0
  • ?

    Embarcadero's Motto == "Hey, it compiles! Ship it!" ´(geklaut von (audacia))

    Erweiterte RTTI wegen (keine sau nutzt) LiveBindings erstellt nun mal größerer EXE'n >= XE2

    0
  • F

    So, danke für eure Antworten. Ich hab mich mit dem UPX Packer mal drangesetzt und die Exe gepackt und es sind nur noch 1,2 MB. Die Frage ist nur, was dieser Packer denn eigentlich macht? Nicht, dass ich dadurch andere Nachteile habe 🙂

    0
  • W

    Also, da ich UPX in deinem anderen Thread ins Spiel gebracht habe, kann ich hier etwas dazu sagen:
    Ich habe jahrelange Erfahrung damit, meine Programme damit zu verkleinern und bisher noch nichts negatives erlebt. Das Prinzip ist eine zip Kompression mit einem kleinen zip Entpacker in der exe Datei. Das funktioniert hier unter allen möglichen Windows Versionen und auch Linux mit Wine kommt damit zurecht.

    0
  • Z

    http://forum.lazarus.freepascal.org/index.php?topic=6284.0 schrieb:

    Hi *,
    I am sure, that this is common question. 😞
    I have also found articles speaking about it
    (http://wiki.lazarus.freepascal.org/Lazarus_Faq#Why_are_the_generated_binaries_so_big.3F), but I do not fully understand it.

    In my very simple example I have one form and one label and button on it.
    When I compile project, I get 12MB size executable.
    I have tried some options in Compiler options/Linking, but without effect ...

    When I use strip.exe on 12MB executable I get 1.5MB executable ... which is fine.

    Why Lazarus does not use "strip.exe" by default in Building process ?
    Or is there any switch, which I have missed ?

    TIA
    -Laco.

    0
  • W

    Was will uns das jetzt sagen ?
    Bei Lazarus ist es mit der Dateigröße noch viel schlimmer als bei Delphi oder BCB.
    Das erwähnte Strip.exe entfernt Debug-Symbole aus der Datei, der UPX Packer kann zusätzlich verwendet werden.
    Insgesamt finde ich, daß BCB + UPX gut eingesetzt werden kann für kleine Programme, die überall funktionieren sollen. Ich denke, auch der ganze QT-Kram muß entweder Laufzeit-Bibliotheken installieren oder ist statisch gelinkt auch nichg gerade besonders klein, habe bisher aber noch keine Erfahrung damit.

    0
Anmelden zum Antworten