Applikation in .DLL aufteilen? [Erledigt]

[Herbert]

Liebe X-Gemeinde
Habe meine Applikation (.exe ist 11MB gross) in mehrere .DLL versucht aufzuteilen. Nach einigen Startproblemen funktioniert das gut. Ich stelle fest, dass die Ladezeit während des Arbeitens (nicht für den Mainscreen) eher länger wird.
Meine Fragen dazu:
Teilt ihr eure App überhaupt auf?
Was muss beachtet werden?
Danke!

[Manfred]

Hi Herbert,

ich habe meine Applikation(en) "etwas" untereilt. Das was allgemeingültig ist, habe ich in DLL ausgelagert. Ich habe es aber aus dem Hauptgrund gemacht, damit ich eben diese Module einfacher austauschen kann, ohne gleich eine neue EXE auszuliefern und weil das Projekt aus mehreren Exe Dateien besteht, die dann auf gemeinsame DLLs zugreifen, die dann auch nur einmal in den Speicher geladen werden. Die EXE wird dann auch entsprechend schlanker.
Worauf zu achten ist, und was mich am Anfang etwas zurückwarf, ist halt, dass den DLLs alles bekannt sein muß, was man dort aufruft, aber nicht aus der DLL stammt. Es muß halt vorher eingebunden werden.

[Jan]

Ich selber teile meine Projekte inzwischen stark auf.

In die Exe kommt nur das, was für den Start notwendig ist. DbeSys.prg, Menüsystem, etc.
In eine dll kommen alle allgemeingültigen Tools und Routinen.
Jeder Hauptmenüpunkt bekommt eine eigene dll.

Der Sinn dafür ist ähnlich wie bei Manfred. Bei einem Update muß der User nur das runterladen, wo sich wirklich was geändert hat.

Ich bin inzwischen dazu übergegangen, eine einzelne projektbezogene Include zu schreiben. Die kommt grundsätzlich in jede prg rein. Und da stehen alle eventuell benötigten includes drin, und alle PRAGMA-Anweisungen, mit denen ich alle eigenen und die benötigten Alaska-dll einbinde und allgemein bekannt mache. Der Sinn ist der, daß ich, nur weil da irgendwas geändert wurde, eine neue dll hinzugekommen ist, oder sonstwas passiert, ich nicht in jeder einzelnen prg was nachführen muß. Einfach in meine globale Include reinschreiben, neu kompilieren, fertig.

Jan

[Manfred]

Hi Jan,

das mit der Include mußt Du mir mal eben in meinem hohen Alter näher erklären. Irgendwie habe ich jetzt ein Brett vor dem Kopf. Was schreibst Du da alles rein? Poste doch einmal bitte ein Beispiel....

[Herbert]

Danke schon mal für die Einschätzungen eurerseits.

Betreffend Performance habt ihr keine Probleme?

Manfred (oder "junggebliebener Rentner"), du erstellt mehrere .EXE oder sind das Programme für sich alleine?

[Manfred]

Hi Herbert,

das gesamte Projekt unterteile ich in z.B. Verkauf, Kundenstamm, Artikelstamm, sonstige Stammdaten usw. So bleibt es alles relativ schlank und ich kann an den einzelnen EXE arbeiten und muß nicht so aufpassen, was jetzt gesperrt werden muß und was nicht. Das wäre wenn alles in einer großen EXE wäre. Es ändert sich was im Verkauf, dann wird nur der Teil angepackt und die anderen EXE nicht. Dort kann/könnte ich dann andere Sachen machen, die vielleicht erst viel später verteilt werden würden. Hat sich bisher prima bewährt. Ist aber alles Geschmack- und Konzeptsache eines jeden selbst. Wie man in Kölle immer so schön sagt: Jede Jeck iss anners.

[brandelh]

Hi,

ich selbst teile nicht auf, alles in eine EXE ist meine Devise ...

Wegen der Performance, es müsste schneller sein, wenn man selten benötigte Teile in eine DLL auslagert,
die erst bei Bedarf geladen wird. Allerdings muss man dazu dynamisch Linken.
Wenn man statisch linked, wird jede DLL gleich zu Beginn geladen.
Ich vermute dass es länger dauert 3 oder 4 kleinere Dateien zu laden als eine große EXE (cache, readahead buffer...).
Außerdem dürfte der Verwaltungsaufwand intern größer sein wenn er die Funktion aus einer DLL lädt.

Aber wie geschrieben sind das nur Vermutungen

Einen großen Vorteil hat das Aufteilen auf jeden Fall dann, wenn der Kunde Programmteile als Module
eventuell auch noch mit verschiedener Ausbaustufe dazu kaufen (laden kann.).
Also Startprogramm + Textmodul einfach/pro + Einkauf etc. ... das habe ich aber nicht

[AUGE_OHR]

hi,

Teilt ihr eure App überhaupt auf?
Was muss beachtet werden?

Bei mir besteht die EXE, wie bei Jan, nur aus der APPSYS,DBESYS,ERRORSYS und die Main mit Menü alles andere in DLL´s.

der Grund jedoch ist das praktisch jede DLL als EXE laufen kann (#IFDEF USEEXE). Dies hat 2 Vorteile :
1.) der Code ist strikt getrennt und anderen DLL´s sind nur per PostAppEvent() zu erreichen.
2.) als reine EXE kann ich leichter eine Demo von einem Modul erstellen

ok, es gibt schon eine "FUNKTGUI" LIB/DLL ... eigentlich 2 denn auch für Hybrid gibt es noch die "FUNKTCRT" LIB/DLL.
Das sind die gemeinsam genutzten "Standard" Funktionen wie NET_USE() etc. sowie einem "Stack" für globale Einstellungen (Farben,Path)

zudem kommen all die activeX DLL die ich verwende, also eine ganze Menge "echte" *.DLL´s wo man "andere" DLL´s verstecken kann ...

[Rolf]

Hallo

Wir benutzen auch nur eine *.exe etwas unter 30 MB, ausgelagert sind nur wirklich seperate Module die man auch getrennt verkaufen kann, z.B. der Terminplaner.

Die Ladezeit bei unser Haupt-Exe dauert nicht länger, wie das öffnen eine Worddokumentes.
Übers Netzwerk ca 3-7 Sekunden. Wir haben zu Beginn einen Logindialog so fällt es kaum auf, dass die Anwendung länger braucht.

Es gibt auch Programme die man vorschalten kann auf der Seite von Phil war glaube ich mal eins in Delphi programmiert.

Wenn man zu beginn noch prüft ob die Datenbanken existieren oder die richtige Struktur haben. Sollte man drauf achten nicht mehr als 1000 Dateien in einem Ornder zu haben, das dauert sonst auch länger.

Liebe Grüße Rolf

[Rolf Ramacher]

Hallo Herbert

ich habe meine Application in mehrere exe-Files aufgeteilt. d.h. mein Startprogramm beinhaltet einen dialog mit mehreren Menüs
die dann die anderen exei-files mit runshell startet. funzt. ohne Probleme . meine bisherige größte exe ist 1,2 MB groß

[Herbert]

Hallo Rolf
Wie steuerst du in diesem Fall das Schliessen der einzelnen .EXE, wenn der Benutzer das Hauptprogramm schiesst?

[Wolfgang Ciriack]

Hallo Herbert,
ich habe das auch so ähnlich wie Rolf, ich fange einfach das Schließen des Hauptprogramms ab. Es kann erst geschlossen werden, wenn alle anderen Module (.Exe) geschlossen wurden (z.B. damit ich weiss, wer noch im Programm tätig ist).

[Rolf Ramacher]

Hallo Herbert,

das schliessen der einzelnen exe-files habe ich gar nicht abgefangen. gute idee noch. ist bei mir aber nicht so wild, da im Normalfall keine Datenbanken geöffnet sind. außer bei xbpbrowse temp-datenbanken im lokalen verzeichnis.

aber man könnte doch die einzelnen aufgerufen exe-files in einer datenbank eintragen und beim schließen des Hauptfensters hinweise geben, welche noch offen sind.