Applikation in .DLL aufteilen? [Erledigt]
Moderator: Moderatoren
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Applikation in .DLL aufteilen? [Erledigt]
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!
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!
Zuletzt geändert von Herbert am So, 28. Mär 2010 15:05, insgesamt 1-mal geändert.
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- Manfred
- Foren-Administrator
- Beiträge: 21186
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Applikation in .DLL aufteilen?
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.
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.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Jan
- Marvin
- Beiträge: 14651
- Registriert: Fr, 23. Sep 2005 18:23
- Wohnort: 49328 Melle
- Hat sich bedankt: 21 Mal
- Danksagung erhalten: 88 Mal
- Kontaktdaten:
Re: Applikation in .DLL aufteilen?
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
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
Mitglied der XUG Osnabrück
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
Mitglied der XUG Berlin/Brandenburg
Mitglied des Deutschsprachige Xbase-Entwickler e. V.
- Manfred
- Foren-Administrator
- Beiträge: 21186
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Applikation in .DLL aufteilen?
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....
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....
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- Herbert
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Applikation in .DLL aufteilen?
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?
Betreffend Performance habt ihr keine Probleme?
Manfred (oder "junggebliebener Rentner"), du erstellt mehrere .EXE oder sind das Programme für sich alleine?
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- Manfred
- Foren-Administrator
- Beiträge: 21186
- Registriert: Di, 29. Nov 2005 16:58
- Wohnort: Kreis Wesel
- Hat sich bedankt: 210 Mal
- Danksagung erhalten: 67 Mal
Re: Applikation in .DLL aufteilen?
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.
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.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
- brandelh
- Foren-Moderator
- Beiträge: 15695
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 65 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Applikation in .DLL aufteilen?
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
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
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12906
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 45 Mal
Re: Applikation in .DLL aufteilen?
hi,
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 ...
Bei mir besteht die EXE, wie bei Jan, nur aus der APPSYS,DBESYS,ERRORSYS und die Main mit Menü alles andere in DLL´s.Herbert hat geschrieben:Teilt ihr eure App überhaupt auf?
Was muss beachtet werden?
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 ...
gruss by OHR
Jimmy
Jimmy
Re: Applikation in .DLL aufteilen?
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
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
- Der Entwickler von "Deep Thought"
- Beiträge: 1930
- Registriert: Do, 09. Nov 2006 10:33
- Wohnort: Bergheim
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Applikation in .DLL aufteilen?
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ß
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
- Der Entwickler von "Deep Thought"
- Beiträge: 1991
- Registriert: Do, 14. Aug 2008 0:22
- Wohnort: Gmunden am Traunsee, Österreich
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Applikation in .DLL aufteilen?
Hallo Rolf
Wie steuerst du in diesem Fall das Schliessen der einzelnen .EXE, wenn der Benutzer das Hauptprogramm schiesst?
Wie steuerst du in diesem Fall das Schliessen der einzelnen .EXE, wenn der Benutzer das Hauptprogramm schiesst?
Grüsse Herbert
Immer in Bewegung...
Immer in Bewegung...
- Wolfgang Ciriack
- Der Entwickler von "Deep Thought"
- Beiträge: 2934
- Registriert: Sa, 24. Sep 2005 9:37
- Wohnort: Berlin
- Hat sich bedankt: 13 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Applikation in .DLL aufteilen?
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).
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).
Viele Grüße
Wolfgang
Wolfgang
- Rolf Ramacher
- Der Entwickler von "Deep Thought"
- Beiträge: 1930
- Registriert: Do, 09. Nov 2006 10:33
- Wohnort: Bergheim
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Applikation in .DLL aufteilen?
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.
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.