exe zu groß!

[MathiasSimmack]

Zitat von tommie-lie:

Zitat von jbg:

Da bekommt sehr kleine Exe-Dateien (was aber verschwiegen wird, wie auch bei MFC Anwendungen: die 40MB der .NET Runtime Environment)

Mit dem Unterschied, daß das .NET-Framework wiederverwertbar ist und einen gewissen Namen hat.

Und als Ergänzung: Das .NET-Framework hat ja auch eine gewisse Größe, und es muss auch erst mal installiert werden. So gesehen, @jbg, ist .NET bisher kein Vorteil. Es wirkt auch nicht gerade ... äh ... schön, wenn sich der potentielle Kunde für ein 30k großes Programm erst mal das 20meg dicke .NET-Framework installieren muss. Die geringe Dateigröße fällt tatsächlich erst ins Gewicht, wenn ein komplettes Betriebssystem auf .NET basiert.

Zitat:

Die VCL-Packages müssen aber jeder Delphi-Anwendung beiliegen, da den Usern ja ständig eingeredet wird, non-MS wäre unsicher und man solle niemals was ins Systemverzeichnis kopieren, wo alle Anwendungen die Chance haben, Dateien zu sharen.

Wobei ich das durchaus nützlich finde. Du darfst ja nicht vergessen, dass Microsoft nicht verboten hat, eigene Bibliotheken in die Systemverzeichnisse zu kopieren. Es ist nur eine Empfehlung um Versionschaos zu vermeiden. Ich hatte selbst mal mit zwei Programmen zu tun, von denen das vermeintlich aktuellere eine ältere Version einer DLL installiert hat - mit dem unschönen Nebeneffekt, dass das andere dann nicht mehr richtig funktionierte.
Wenn aber eine Runtime- oder was weiß ich-DLL ihre Versionsnummer im Namen trägt und sich dann nicht mit einer evtl. älteren/neueren Version in die Quere kommt, spricht auch nichts gegen das Kopieren in das Systemverzeichnis.

Zitat:

Zitat von jbg:

Mit direkter WinAPI Programmierung wird man nach Windows Longhorn ziemlich im Regen stehen, denn dann ist die WinAPI nur noch zweite Wahl, wenn es nach Microsoft geht, und das tut es beim Windows Betriebssystem.

Solange die API noch zur Verfügung steht, steht man selber auch nicht im Regen, egal ob MS das für erste oder zweite Wahl hält.

Und abgesehen davon wird sich Longhorn sicher auch nicht sofort nach der Veröffentlichung durchsetzen. Es gibt ja jetzt noch mehr als genug Rechner, auf denen 95 oder NT4 läuft. Ich selbst habe auch noch mein gutes altes 98 am Start.

[supermuckl]

@ work haben wir auch haufenweise NT 4 rechner ( ja auch die neuen 2k3 systeme parallel )

ich persönlich mag .NET überhaupt nicht, da es wie gesagt noch ein plugin ist und daher ziemlich langsamer sein wird als direkt im kernel mit einkompiliert

ausserdem wird das wohl wie mit win311 und seinen 16bit programmen sein.. die laufen heute immernoch und sogar dos krempel
also ich werde als letzter auf .NET "umsteigen".. wenn nich sogar total auf linux und dem microschnufti dreck komplett aus dem weg zu gehen und unabhängiger zu sein

ich hoffe kylix wird weiter entwickelt werden.. und wenn nicht mach ich meine projecte halt mit Kdevelop in C++ oder pascal/delphi mit diversen free pascal compilern

[tommie-lie]

Zitat von MathiasSimmack:

wenn sich der potentielle Kunde für ein 30k großes Programm erst mal das 20meg dicke .NET-Framework installieren muss.

Aber wenn er das Framework ersteinmal hat, dann hatter's und braucht bis zur nächsten Version vom Framework nicht mehr runterladen.

Zitat:

Du darfst ja nicht vergessen, dass Microsoft nicht verboten hat, eigene Bibliotheken in die Systemverzeichnisse zu kopieren.

Microsoft vielleicht nicht, aber die ganzen Sensationsreporter, die meinen, ihr nicht vorhandenes Wissen an ahnungslose PC-Neukäufer weiterreichen zu müssen.

Zitat:

Wenn aber eine Runtime- oder was weiß ich-DLL ihre Versionsnummer im Namen trägt und sich dann nicht mit einer evtl. älteren/neueren Version in die Quere kommt, spricht auch nichts gegen das Kopieren in das Systemverzeichnis.

Das ist ja bei der VCL der Fall, zumindest heißen die Packages bei mir vclXXX60.bpl.
Aber den meisten Leuten wird einfach Angst gemacht, sowas zu machen, und deswegen muss unsereiner entweder die Dateien immer mitliefern (entweder "lose" oder in die EXE binden), oder auf nonVCL umsteigen, wenn wir in Sachen Dateigröße mit VB oder MSVC konkurrieren wollen.

Zitat:

Und abgesehen davon wird sich Longhorn sicher auch nicht sofort nach der Veröffentlichung durchsetzen. Es gibt ja jetzt noch mehr als genug Rechner, auf denen 95 oder NT4 läuft. Ich selbst habe auch noch mein gutes altes 98 am Start.

Eben, deswegen denke ich ja auch, daß das noch einige Jahre dauern wird, bis sich .NET endlich vollständig durchgesetzt hat, mindestens noch zwei Windowsgenerationen.

[jbg]

Zitat:

So gesehen, @jbg, ist .NET bisher kein Vorteil. Es wirkt auch nicht gerade ... äh ... schön, wenn sich der potentielle Kunde für ein 30k großes Programm erst mal das 20meg dicke .NET-Framework installieren muss

Warum schreibe ich eigentlich was in Klammern dazu :

Zitat:

(was aber verschwiegen wird [...]: die 40MB der .NET Runtime Environment)

[MathiasSimmack]

Zitat von jbg:

Warum schreibe ich eigentlich was in Klammern dazu

Ich habe das schon gesehen. Es wird ja IMHO auch nicht "verschwiegen" im Sinn des Wortes. Es wird nur ab und zu vergessen, dass .NET-Programme eben auch das .NET-Framework voraussetzen. Und damit relativiert sich der angebliche Vorteil der geringen Größe erst mal wieder ... Das wollte ich sagen. Hätte ich wohl gleich tun sollen.

[mytar]

Die normale Größe bei meinem Programm beträgt, ca. 1MB
Mit UPX nur noch knapp 600KB, gibt es noch eine Möglichkeit wie ich das optimieren kann?

mytar

[Wheelie]

Zitat von mytar:

Die normale Größe bei meinem Programm beträgt, ca. 1MB
Mit UPX nur noch knapp 600KB, gibt es noch eine Möglichkeit wie ich das optimieren kann?

mytar

Ich glaube nicht, dass du an der Echse noch was optimieren kannst (mit irgendwelchen Tools). Du kannst aber das Projekt optimieren (zu große Grafiken, überflüssige Units, etc.). Meistens sind es irgendwelche Komponenten, die deine Echse um 200-300 KB wachsen lassen. Wenn du die samt Units rauswirfst und diese durch primitivere Komponenten ersetzt, holst du bestimmt noch ein paar KB raus.

[MrKnogge]

Zitat von mytar:

Die normale Größe bei meinem Programm beträgt, ca. 1MB
Mit UPX nur noch knapp 600KB, gibt es noch eine Möglichkeit wie ich das optimieren kann?

mytar

Du kannst auch die komprimierungs-stufe einstellen, gib einfach mal den parameter "-h" an die ee, und du erhalst die gesamten paramter, oder such hier im Forum nach UPX-GUI, dann kannst du den UPX-Packer per Oberfläche bedienen.

[mytar]

Ich denke nicht das ich große Komponenten eingefügt habe,

ich hab PageControl,

Vielleicht ist es die ImageList,
oder ActionToolbar und ActionMainMenuBar?

Was sagt ihr?

[MrKnogge]

die größe liegt hauptsächlich an der Unit "Forms", die du für deine Formulare benötigst. Wie bereits geschrieben, um auf die zu verzichten, müsstest du auf API oder .NET umsteigen, oder du komprimierst eben deine exe-file.