max Grösse einer EXE

[Manfred]

Hi,

mir stellt sich gerade die Frage, wo man denn als vernünftig denkender Xbase++ Entwickler die Grenze einer EXE Dateigröße zieht oder sieht. Jetzt mal abgesehen vom machbaren. Einfach nur so.

Wie sieht es mit 30MB aus? Zu groß, oder im total grünen Bereich? Auch generell vom gesamten Handling, egal ob Debugger oder Editor usw. Was ist eure Meinung?

[Martin Altmann]

Beruhigt es Dich, wenn ich Dir sage, dass meine 41 MB groß ist?
Und damit gehöre ich eher noch zu den Leichtgewichten unter uns Xbase++-Entwicklern.

Viele Grüße,
Martin

[Tom]

Ich war schon ziemlich weit über 100. Das habe ich dann aufgesplittet, aber nicht, weil es damit irgendwelche Probleme gegeben hätte, sondern weil es beim Kompilieren/Linken einfach viel zu lange gedauert hat, vor allem in der Summe; es war einfach idiotisch, immer alles zu bauen (statt nur die DLLs, die gerade betroffen waren). Ich glaube nicht, dass es mit einer vertikalen Xbase++-Applikation gelingen könnte, da irgendwelche Grenzen zu sprengen. Ich könnte spaßenshalber mal unsere Kernapplikation mit allen Servicemodulen als Single-EXE zusammenfahren und schauen, wie groß das würde. Tendenz 300 bis 400 MB. Auch noch kein Problem, nehme ich an. Ach so: Ich habe schon Setups und selbstextrahierende ZIPs (als EXEn) gesehen/gehabt, deren Größe im Gigabyte-Bereich lag. Liefen ebenfalls.

[Manfred]

Hm,

also ich mache mir eher Sorgen über das Handling so großer Dateien. Das Bauen und compilieren, dass ist es was mich derzeit stört. Auch das Debuggen. Das Projekt was ich gerade habe ist so groß, aber wenn ich es mit der VX debugge, dann könnte ich auch genauso gut zwischendurch einen Dauerlauf machen, ohne Zeit zu verlieren. Mal sehen, wie man das ändern kann. oder die VX hat hier einfach nur ihre Schwächen. Alle naselang kommt die Meldung es hat sich was geändert, soll neu kompiliert werden? Aber wenn ich mir die Dateizeiten ansehe, dann ändert sich da nix. Wer weiß was das wieder ist. Auf jeden Fall ist es recht aufwändig alles zu druchforsten nach solchen Sachen.

[Tom]

Kauf Dir einen schnellen Rechner. Und splitte in DLLs auf - obwohl 30 MB wirklich noch keine Größe markieren.

Ich habe noch nie irgendeinen der Xbase-Debugger benutzt. Wenn ich nach Fehlern suche, baue ich eigenen Debugcode ein. Objektinspektoren, Tabellen, die Variableninhalte anzeigen, statische Memos, die Callstacks ausgeben usw. - eben bedarfsweise. Damit bin ich schneller und gezielter unterwegs.

[georg]

Hallo, Manfred -


von einem, der den Debugger verwendet, einen Hinweis:

Es kommt bei mir hin und wieder vor, dass ein Programm nicht mehr im Debugger läuft. Dann nehme ich aus der XPJ die Debug-Optionen raus, fahren einen "pbuild /a", setze die Debug-Optionen wieder in die XPJ rein und lösche das OBJ-File, das ich gerade im Fokus habe und compiliere nochmals.

Damit hat nur dieses Modul Debug-Code, und alles andere wird im "Debugger" übergangen.

[Jan]

Manfred,

ich habe mein Programm auch irgendwann in exe und diverse dll aufgesplittert, weil die Updates über das Internet dann besser liefen (zu Zeiten, als noch nicht jeder eine 16.000er Flat hatte). Und dann wird bei Updates immer nur die Datei(en) rübergeholt, die sich wirklich geändert hat/haben. Ob das heute noch Sinn macht mag ich nicht bewerten, viele (vor allem ältere) Privatkunden haben immer noch 1.000er Leitungen oder sowas in der Richtung.

Ich hab in VX auch ab und an, nicht reproduzierbar, den Hinweis, es gäbe geänderte Dateien, ob denn neu kompiliert werden solle. Und es gibt garantiert keine Änderungen. Ich ärgere mich darüber inzwischen nicht mehr, sondern hoffe auf eine fehlerbereinigte Version.

Achso. Mein größtes Projekt, das ich jemals in den Fingern hatte, lag bei ca. 16 MB. Da hatte ich mit VX keinerlei Probleme mit. Wenn der Debugger einschnarcht, dann liegt das an VX oder irgendwelchen Hintergrundprozessen oder bösen Geistern. Dann sind sogar sonst schnell debugbare Programme plötzlich irre langsam. Und auf ein mal geht es dann wieder. Mysterium EDV halt.

Jan

[AUGE_OHR]

Kauf Dir einen schnellen Rechner.

hihi ...

eine grosse EXE bzw viel Code ist natürlich schwieriger zu handhaben als ein kleines Test Programm.
leider benötigt man aber viele Function der EXE ... wenn die Function nun in den DLLs wären ...

es hat also nicht nur für den Kunden / Update einen Sinn DLLs zu verwenden sondern hat beim Debuggen den Vorteil "nur" mit 1 DLL, welche mit /b compiliert wurde, zu arbeiten.