.EXE Programm aufteilen

[SKolberg]

Hallo, das ist warscheinlich wieder eine DUMME frage.

Ich schreibe ein Programm in Delphi welches noch nichtmal ganz fertig ist, da die .EXE aber schon fast 7 MB gross ist wollte ich fragen ob und wie man diese Datei aufteilen kann. Man kennt das ja von diversen Programmen die man installiert das die hier und da noch ne .DAT Datei haben. Wie ist das machbar??

Danke im voraus, Steve

[MathiasSimmack]

Resourcen-DLLs nutzen und soviel wie möglich auslagern. Edit: Falls es hauptsächlich BMP-Bilder sind, dann vllt. mal ein anderes Format oder die RLE-Kodierung probieren. Das spart auch Platz.

[Kernel32.DLL]

haste viele Bitmaps in deiner Anwendung? Wenn ja, tue die in einen extra Ordner und lade sie dynamisch...

[SKolberg]

Das mit den BMP´s ist schonmal ein guter Vorschlag, noch sind es nicht viele, aber werden es wohl noch.
Es ist eine Win32.SDI. Anwendung für eine Datenbankverwaltung sie beinhaltet mittlerweile 8 Forms und das ZeosLib.
Kann man da eventuell noch dir Forms bzw. Das Lib auslagern?

[SKolberg]

die BMP´s habe ich jetzt seperat vom programm allerdings ist es dadurch nur um 2 MB geschrumpft und immer noch 5 MB gross,
kann ich da nicht irgendwie doch die Forms, ZeosLib und ..halt irgendwas in andere dateien auslagern worauf das hauptprogramm
dann halt drauf zurückgreift?? zb. wenn ich eine updatefunktion ins programm einbaue und eine neue Ver. zur verfügung steht wäre
das ja sch... wenn der jedesmal die 5 oder mehr MB übers internet laden müsste(gerade bei isdn modem etc.), wäre ja gut wenn ich die Form´s in seperate dateien speichere und er nur die parts lädt an denen was geändert wurde...??!

[Jasocul]

In deinen Projekt-Optionen gibt es ein Register Packages.
Dort kannst du einstellen, ob du mit oder ohne Laufzeit-Packages compilieren möchtest. Schalte das mal um.
Allerdings solltest du dann auf einem "jungfräulichen" PC genau prüfen, welche Laufzeit-Packages du mitliefern musst.

[SKolberg]

wenn ich ohne laufzeit packages kompiliere, muss ich die dann seperat komplieren? z.b. das zeoslib in eine dll??

[Jasocul]

Nein. Du musst sie nur mit ausliefern.
Auch die DLLs müssen nur in dein Update rein, wenn diese sich geändert haben. Aber normalereise lässt man diese ja in Ruhe.

Ähm, ich hoffe, dass sich das seit D5 nicht geändert hat.

[Phoenix]

Hrm.

Du kannst auch mal nach UPX googeln. Das Ding komprimiert Deine .exe so, dass sie sich erst beim ausführen entpackt und dann erst gestartet wird. Das kann schon ein paar MB ausmachen. Ich bekomme damit eine 20 MB - .exe auf knapp 4 bis 5 MB runter.

[SKolberg]

gute idee @Phoenix werde mir das auch mal anschauen, allerdings kommt es bei diesem programm nicht in frage..
es ist noch nicht mal fertig, aber trotz alldem schon 5 MB gross und es zum ende wohl schätzungsweise 20MB
seien werden. auch wenn es komprimiert dann nur 5 MB wären, wäre das zuviel ums per Modem-ISDN zu upzudaten,
daher denke ich die beste möglichkeit ist alle forms/komponenten in seperate dateien zu speichern, so dass wenn ein form,
z.b. Datenbearbeitung geändert wird halt auch nur die datei **.dat/bin oder so zu laden. wie auch immer das zu bewerktelligen ist...

Danke

[MathiasSimmack]

Da kann ich dir eigentlich .NET und die Assemblies empfehlen. Damit kannst du buchstäblich einzelne Teile deines Programms auslagern. Im Extrem so, dass du für jeden Dialog (= Form) eine separate Assembly nutzt. :stupid: Musst du was aktualisieren, gibst du nur die Teile neu heraus, die sich verändert haben.

Aber okay, der Nachteil wären dann die ~20 MB für das .NET-Framework. :mrgreen:

[SKolberg]

kann ich denn mein bestehendes win32.sdi projekt in .Net umwandeln ohne alles neu zu programmieren?? das mit dem .Net installieren
kann man ja über ein installationspaket machen, wenn ja wie wandle ich das proj. um und würde das auch unter Win98 laufen
(man muss ja alle möglichkeiten in betracht ziehen)..

[maximov]

du kannst dein programm doch auch auf normaler packages (BPLs) verteilen. Allerdings is es alles augenwischerei, da vielleicht die Echse schrumpft aber wohl kaum das projekt.

[MathiasSimmack]

Das ist richtig, maximov. Aber wenn man clever auslagert, etwa die Bitmaps in eine Ressourcen-DLL usw., dann muss man bei Updates nur die notwendigen Programmteile aktualisieren. Ob nun VCL, nonVCL oder .NET. Wenn du einen Bug in der Exe behebst, dann kann der User aber bspw. trotzdem die alte Ressourcen-DLL mit den Bitmaps und Symbolen verwenden, weil man die wohl nicht auch ständig erneuern wird.

Der User muss bloß die Exe mit bspw. fiktiven ~300 kB runterladen und wird dazu wohl eher bereit sein, als sich noch mal das komplette ~5 MB-Paket zu holen, in dem faktisch gesehen vllt. 30k Code ge-bugfixt wurden. :)

[SKolberg]

gut dann werde ich die möglichkeiten mal in den nächsten tagen ausprobieren..

gruss, Steve

[neolithos]

Mal ne kurze Frage, was stört dich daran das deine EXE 7 MB groß ist?

Ich würde Sie nur in einzelne Teile teilen, wenn es für die Entwicklung sinnvoll ist (mehrere Entwickler, Updates etc). Sonst ist es gut das es nur eine Datei ist, da sie schneller geladen werden kann. Zweitens legt man Bitmaps oder Teile in andere Datei außerhalb der EXE, sollte man immer prüfen, ob Sie noch vorhanden sind, und nicht irgentein DAU Sie gelöscht hat, um Platz zu sparen.

UPX find ich übrigens nicht so prickeln, da dadurch die Anwendung im Speicher entpackt wird, was wieder an der Perfomance nagt, was heutzutag, ich weis nicht so interessant ist.

[MathiasSimmack]

Zitat:

Zitat von neolithos

Ich würde Sie nur in einzelne Teile teilen, wenn es für die Entwicklung sinnvoll ist (mehrere Entwickler, Updates etc).

*räusper* Ich weiß, man plant als Entwickler immer das ultimative Programm, völlig fehlerfrei, gleich von Anfang an mit vollem Funktionsumfang, den sich der Anwender wünscht ... Aber die Realität sieht doch anders aus ... ;) Mit Updates sollte man also schon rechnen.

Zitat:

Zweitens legt man Bitmaps oder Teile in andere Datei außerhalb der EXE, sollte man immer prüfen, ob Sie noch vorhanden sind, und nicht irgentein DAU Sie gelöscht hat, um Platz zu sparen.

Ich vermisse den Einwand von Robert bzgl. MSI und Windows File Protection. Korrekt angewendet, meldet sich bei fehlenden Komponenten der Microsoft Installer und fragt nach der Setupdatei, bzw. installiert die Dateien im Hintergrund automatisch nach, wenn er die Setupdatei allein findet. Mit anderen Worten: Der DAU kann löschen so oft er will, mit jedem Programmstart sind die fehlenden Komponenten notfalls wieder da. :)

[SKolberg]

@Neolithos
der grund warum ich die datei aufteilen will ist ganz einfach, jedesmal wenn ich an der sofware was ändere,
müsste die person um das update zu installieren bzw. das automatische update die komplette exe mit ...MB herunterladen das kann aber wenn per modem oder ISDN online, ziemlich lange dauern deswegen die aufteilung. die software soll in meiner firma eingesetzt werden da aber einige mitarbeiter des öfteren unterwegs sind, sollten sie die möglichkeit haben ohne grosse probleme die updates zu laden, zumal in den meisten hotels nur modem verfügbar ist...

@Simmick
das mit dem MSI werde ich mir mal anschauen, daran habe ich noch garnicht gedacht.
P.S. Wenn ein entwickler denkt er könne seine Software Perfekt, Ohne Bugs.... programmieren ist er ganz schön
eingebildet, ich denke jeder gute programmierer weiss das es sehr viel zeit benötigt um eine problemlose software zu entwickeln,
ganz abgesehen von den wünschen und anregungen der User!!

[leddl]

Warum erstellst du dir bei einem Update nicht einfach eine Datei, die eben nur die jeweiligen Änderungen beinhaltet? Es gibt genug Programme, mit denen du dir so eine "Änderungsdatei" machen kannst. Die lädst du dann herunter, und da die eben nur die neuesten Änderungen umfasst, dürfte sie also relativ klein sein. Danach kannste dann mit dieser Datei deine vorhandenen Dateien updaten.
Weiß grade nicht, wie das Prog heißt, das ich benutze, aber wenn du willst kann ich mal nachschaun.

[SKolberg]

läuft das integriert in meiner software oder als seperates programm? wäre nett wenn du mir den namen mal geben könntest

[leddl]

OK, das Programm heißt MakeUpdate, ist Freeware und zB hier zu finden. Da is auch gleich eine kleine Beschreibung.
Die Zip-Datei enthält nicht nur das Programm, mit dem du dir deine Update-Dateien erstellen kannst, sondern auch den kompletten Quelltext, so daß du die Update-Funktion ohne weiteres in ein eigenes Programm einbauen kannst. Ich hab mir so zB ein extra Programm geschrieben, daß ich mit ausgeliefert habe, das dann eben bei Bedarf das Hauptprogramm (oder sich selbst) auf den neuesten Stand gebracht hat.
Viel helfen kann ich dir allerdings nicht, da ich das damals mit einer einiges älteren Version geschrieben habe, und sich da anscheinend einiges verändert hat. Is außerdem sowieso schon ne ganze Weile her, müßte mich da also sowieso erstmal wieder zurechtfinden. Es ist aber eine Hilfe-Datei dabei und ich denke, daß du wohl hier oder auch auf Delphi-Source reichlich Hilfe dazu finden wirst.

Ich finde eben so einen Updater immer besser, als immer die komplette Datei herunterzuladen. Daß das natürlich ungleich schwerer umzusetzen ist, ist natürlich wiederrum ein Nachteil. Dennoch sieht eine "in-program-update-Funktion" immer um einiges stylisher aus! :mrgreen:

[neolithos]

[ot]
Dieser Beitrag ist übrigens nur entstanden, da es mit Win32 relativ aufwendig ist eine Datei auf mehrere Dll's und Dateien aufzuteilen ohne Spätfolgen zu haben. (Erfahrung) Bei dotNET scheint es logischerweise auch nicht besser auszusehen.
Denn man muss in seinen Schnittstellen zwischen den Compilaten schon viele eventualitäten einplanen. Also programmiere sauber und vorausschauend.
[/ot]