Probleme unter Win98

**Bernhard Geyer**

Zitat von Infect:

Ich selbst habe bei den neu hinzugekommenen Formularen schon darauf geachtet, Code-Redundanz zu vermeiden, aber wenn, dann haben meine Formulare das bereits randvolle Fass quasi nur zum Überlaufen gebracht.

Schon mal versucht die Uses-Anweisungen zu bereinigen. Auch Klassen die nicht mehr benötigt werden können zu Speicherwuchs führen wenn sie per Uses eingebunden werden und im Initialization-Abschnitt darauf zugegriffen wird. Haben damit schon einige 100 kByte gespart. Auch würde ich mal darüber gehen das für gleiche Anforderungen immer die gleichen Controls verwendet werden (Nicht 10 Grids da jedem Entwickler ein anderes besser gefällt bzw. das gerade eine Funktion hat die das andere nicht bietet).

**MatthiasR**

Zitat von Luckie:

Werden alle Formulare beim Start erstellt oder dynamisch, wenn sie gebraucht werden?

Eigentlich letzteres, allerdings kann das beim Einpflegen meiner Neuerungen in unser Testsystem auch vergessen worden sein. Ich werde mich auf alle Fälle schlau machen, weil auch ich schon die Vermutung hatte. Aber senkt das die Exe-Größe wirklich? Den Speicherbedarf zum Programmstart jedoch bestimmt, doch um wieviel?

@Bernhard: Versucht habe ich deine Tipps selbst noch nicht, ist halt nur die Frage, ob sich der Aufwand lohnt, weil wir den Support von Win98 ohnehin zum neuen Jahr kündigen wollen. Klar wäre es trotzdem sinnvoll, ein Programm auf diese Weise auszumisten, aber Zeit ist nunmal Geld. Unsre Formulare sollten jedoch recht einheitlich sein, was die Controls angeht, da wir nicht sooo viele Entwickler haben, die einen solchen Wildwuchs erzeugen könnten.

**Bernhard Geyer**

Zitat von Infect:

Aber senkt das die Exe-Größe wirklich? Den Speicherbedarf zum Programmstart jedoch bestimmt, doch um wieviel?

Nein. Nur den Ressourcenbedarf beim Programmstart

Zitat von Infect:

Versucht habe ich deine Tipps selbst noch nicht, ist halt nur die Frage, ob sich der Aufwand lohnt, ... Klar wäre es trotzdem sinnvoll, ein Programm auf diese Weise auszumisten, aber Zeit ist nunmal Geld.

Du weißt nicht wieviel

Lavafluss sich so in der Zeit ansammelt wenn man nicht ab und zu mal drüberschaut. Und bei einer über 30 MB Echse tipp ich da auf einiges Optimierungspotetial.

Zitat von Infect:

Unsre Formulare sollten jedoch recht einheitlich sein, was die Controls angeht, da wir nicht sooo viele Entwickler haben, die einen solchen Wildwuchs erzeugen könnten.

Evtl. sind ja auch einige Komponentenleichen eingebunden.

**MatthiasR**

Das Problem ist halt, dass uns momentan die für Optimierungsarbeiten nötige Zeit nicht zu Verfügung steht. Es brennt sozusagen an zig stellen gleichzeitig. Daher wäre es das beste, dass wir mit meinen neuen Formularen vorübergehend eine unter Win98 lauffähige Version erzeugen können und diese dann irgendwann einmal entrümpeln, wenn es gerade mal nicht so hoch her geht.

Also, wir schaun nun mal, wie wir die Exe etwas verkleinern könnten, um zumindest noch eine gewisse zeit Schonfrist zu haben.

**Assertor**

Hallo,

seit Ihr -sicher- mit der Größenbeschränkung der EXE unter Win98? Für mich hört sich das eher nach Problemen in Richtung

a) Swap-File zu klein (Größenzuweisung auf automatisch stellen)
b) Zu wenig freier Platz auf der System/Swap-Festplatte
c) Virusinfektion des Systems bzw. der EXE an

jeweils natürlich auf dem Target System (Win98).

Nach kurzem Googlen (deswegen der Edit):

Ich habe von einigen lauffähigen Anwendungen > 30 MB unter Win9x gelesen. Die Frage ist, wieviel Prozent der EXE Code und wieviel Ressourcen sind. Das macht ja auch schon einiges aus.

Hauptthema bei Deinem Problem ist wohl das Win9x Ressourcen Limit (teilweise nur 640 bis 1000 GDI Objekte für das ganze System inkl. aller Anwendungen).

Ich glaube nicht an ein Größenlimit der EXE (abgesehen von der zulässigen Größe einer Datei des Dateisystems unter FAT/12/16/32 und dem freien Swap-Space falls der Speicher nicht ausreicht).

Und die Unitliste kannst Du mal einfach mit der IDE Extension CnPack säubern - da kannst Du sogar sagen, ob Units mit Initilization Part auch entfernt werden dürfen. Natürlich nur nach Backup probieren

Läuft hier aber schon lange einwandfrei.

Gruß winkel79

**MatthiasR**

Zitat von Infect:

Zitat von Luckie:

Werden alle Formulare beim Start erstellt oder dynamisch, wenn sie gebraucht werden?

Eigentlich letzteres, allerdings kann das beim Einpflegen meiner Neuerungen in unser Testsystem auch vergessen worden sein. Ich werde mich auf alle Fälle schlau machen, weil auch ich schon die Vermutung hatte. Aber senkt das die Exe-Größe wirklich? Den Speicherbedarf zum Programmstart jedoch bestimmt, doch um wieviel?

Also es werden wirklich nur die nötigen Formulare beim Startup direkt erzeugt, alles andre dynamisch.

@winkel79: Am virtuellen Speicher (meintest du das mit Swap-File?) wurde wohl ebenfalls schon rumgeschraubt, jedoch ohne Erfolg. Die andren Probleme schließe ich mal aus, da das Problem nicht nur auf einem 98er Rechner besteht. Wenn garnichts mehr hilft, werde ich das CnPack mal ausprobieren, danke für den Tipp!

**Bernhard Geyer**

Mir ist noch was eingefallen. Verwendest du schon FastMM4? Falls nein: Bau es ein. Wir sind auch mal in die Speicherfragmentierungsfehler des normalen Speichermanagers von Delphi < 2006 gefallen. Sollte zwar nicht schon zum Programmstart auftreten, aber wer weis.

Ansonsten wären Bilder (PNG/BMP's) 'ne Falle welche kaputt sind aber unter 2000/XP/Vista das Betriebssystem nicht stören aber unter Win98 komische Effekte (auch Bluescreens) verursachen können. Evtl. BMP's/PNG's von Mac-Rechnern.

**MatthiasR**

Könntest du mir etwas nähere Infos zu FastMM4 geben? Was macht dieser Speichermanager genau? Bei uns treten des öfteren beim Compilieren Speicherzugriffsverletzungen auf, deren gründe wir nicht nachvollziehen können. Hilft FastMM4 auch dabei? Wird das nur auf dem Entwicklungsrechner benötigt oder auf jedem Rechner, auf dem anschließend das Programm laufen soll? Wie sicher ist FastMM4? Wie einfach zu installieren? Denn ich müsste meinen Chef erstmal davon überzeugen, in so grundlegenden Dingen wie einem Speichermanager auf Fremdprodukte zu setzen, statt auf Delphi-Interna. Aber wenn der auch bei unsren andren Problemen Erfolg verspricht...

**Bernhard Geyer**

1, Für das Compilieren hilft es nur bedingt.

2, "Installiert" in deine Anwendung ist es ganz einfach: FastMM als ersten Eintrag in die Projektdatei

3, Sicher ist es. Ab Delphi 2006 liefert es Borland als Standard-Speichermanager mit aus.

4, Für's Debuggen muß immer eine FastMM_FullDebugMode.dll von der Anwendung erreichbar sein.