Das stimmt schon... Aber wie ich schon schrieb - "Standardeinstellungen"!!! Also Visual Studio oder auch Delphi mit den Standardeinstellungen installiert und bei Delphi z.b. die "Build-Konfigurationen" unangetastet lassen.

also das Argument ist ja jetzt etwas banane. Die Größe der Exe von den (zufällig) gewählten Voreinstellung des Compilers abhängig machen.

Luckie hat folgendes geschrieben :

Die Größe der Exe von den (zufällig) gewählten Voreinstellung des Compilers abhängig machen.

Zufällig ist es ja noch nicht einmal. Microsoft hat seinerzeit einfach entschieden, dass es sinnvoller ist, wenn die Runtime für jede VB Version einmal installiert werden muss als für jedes Programm den Speicherplatz zu belegen. Zur Zeit von VB war Speicherplatz aber auch noch teurer als heute.
Jetzt bei VB.NET gilt das gleiche. Einmal .NET installieren und das wars.

Der Unterschied zu Delphi ist schlicht die Verbreitung und die Marktmacht. Microsoft kann das machen, Embarcadero nicht. Denn in VB seinerzeit und jetzt in .NET sind enorm viele Programme geschrieben, so dass man das Framework in der Regel ohnehin auf dem PC hat.
Bei Delphi hingegen sieht das anders aus. Insbesondere weil ja jede Delphiversion wiederum eigene Bibliotheken benötigt. Noch dazu gibt es diese nicht einfach als separates Downloadpaket wie die VB Runtimes und .NET. Deshalb konnte die Standardeinstellung nur sein, dass keine Bibliotheken benötigt werden. Denn erstens ist genau das ja ein wichtiges Argument für den Endnutzer für Delphi und zweitens müsste sich jeder Entwickler sonst darum kümmern wie er die Runtimebibliotheken mitliefert...

Insofern liegen die Gründe für diese unterschiedlichen Einstellungen nicht bei den Sprachen / Compilern an sich.

Don Krawallo hat folgendes geschrieben :

In Verbindung mit einem gescheiten Packer

Den zeig mir einmal... ich kenne keinen. Nur son Zeug wie AsPack oder Upx.

Hey, was mich hier mal bei Gelegenheit interessiert...
Was macht soviele Cracks,Trainer etc. suspicious gegenüber Virenscannern?
Zb. Don Krawallos Trainer (oder was es auch war) hat bei einem Viertel aller Virenscanner angeschlagen. (Nicht dass ich dir unterstelle es wäre ein Virus )
Also welches Verhalten macht Virenscanner in der Hinsicht aufmerksam?

lg

@jaenicke: Das reicht mir nicht als Rechtfertigung für M$ OS-großes Bindungsframework. Ich vermisse keine Programme.
@HenryHux: Meist statisches einbinden von DLLs

Seit wann schlagen Virenscanner an, wenn DLLs statisch eingebunden werden? Das ist bei jedem Delphi Propgramm standard, dass die benötigten DLLs statisch eingebunden werden. Guck dir mal die Windows.pas an.

HenryHux hat folgendes geschrieben :

Was macht soviele Cracks,Trainer etc. suspicious gegenüber Virenscannern?

Dass deren Autoren oft irgendwelche Exe-Packer benutzen... Dass solche gepackten Programme oft als Virus erkannt werden, ist nur eines der Probleme solcher Packer.

Dazu kommt noch, dass diese auf den Speicher anderer Programme zugreifen. Beides ist auch bei Viren oft der Fall.

Ist mir zumindest meist so aufgefallen.
Aufgrund vom standard UPX-Packer treten afaik keine Virenfunde auf, da die meisten das entpacken.
Bei Cryptern schlägt dagegen fast alles an.

HenryHux hat folgendes geschrieben :

Zb. Don Krawallos Trainer (oder was es auch war) hat bei einem Viertel aller Virenscanner angeschlagen. (Nicht dass ich dir unterstelle es wäre ein Virus )

In erster Linie ist hier der Packer/Encryptor der Auslöser des Übels. Gepackt und encrypted ist die EXE mit RLPack.
Aber selbst wenn einer Trainer nicht gepackt ist kann er von Antivierenprogrammen als schädlich eingestuft werden, da Trainer meistens per Hotkeys arbeiten. Trojaner oder Keylogger nutzen das auch. Der 2. Punkt ist die Antivierenlösung an sich. Ich selber nutze Kaspersky Internet Security und bin damit bisher sehr gut bedient. Hingegen mit Avira, Symantec oder Nod32 hab ich nur schlechte Eindrücke gesammelt.

Es gibt Antivirenlösungen die auch solcher Packer/Protectoren erkennen und daraus schließen das die Datei eben zwar gepackt und geschützt ist aber als nicht gefährlich eingestuft wird. Dieser Schuß kann aber allerdings nach hinten losgehen Denn es gibt wiederum Programme um sogenannte Fake Signaturen in eine Datei einzufügen.

Hotkeys sind auch Blödsinn. Ich habe schon dutzende Programme mit Hotkeys geschrieben und noch nie Probleme gehabt.

Das erzähl nicht mir sondern den Antivierensofterherstellen...

Don Krawallo hat folgendes geschrieben :

Man muss sich natürlich immer vor Augen halten das es auf die verwendete Programmiersprache ankommt. Man nehme zum Vergleich mal Visual Studio... Mit VB eine einfach Form dazu noch ein Button hat man eine Größe von ca. 100 bis 150 KB. Bei Delphi XE mit den Standard-Einstellungen, ne simple Form + Button, kommt man auf ca. 900 KB.

Ernsthaft 900 KB? Wow. Und ich hab schon gedacht, Delphi 7 wäre "groß" (360 KB bei leerer Form).
Naja, das Heilmittel nennt sich WinApi. Und bevor wieder jemand sagt, da kann man ja gleich zu C wechseln....Nö.

Aber ich frage mich dann doch, wo das Ganze hinführen word. Ist in 30 Jahren dann jede einfache "leere" Anwendung 1 GB groß, nur weil man sich den Speicher leisten kann und das Internet schnell genug sein wird? Lächerlicher Gedanke bei dem ich meinen Kopf schüttele.

FrEaKY hat folgendes geschrieben :

Ernsthaft 900 KB? Wow. Und ich hab schon gedacht, Delphi 7 wäre "groß" (360 KB bei leerer Form). Naja, das Heilmittel nennt sich WinApi.

Dafür hast du mit der API eben keinen Komfort. Die Größe rührt ja daher, dass seit z.B. Delphi 7 enorm viel Funktionalität hinzugekommen ist. Irgendwo muss der Code dazu eben liegen...

Ein weiterer Punkt sind z.B. die RTTI-Informationen. Wenn man diese nicht braucht, könnte man den Platz natürlich sparen, aber diese Option wird erst noch kommen (wahrscheinlich).

Die Priorität liegt aber natürlich bei einer immer besseren Funktionalität, nicht beim Sparen von ein paar Kibibyte. Und das finde ich auch gut so, da es sehr viel Zeit bei der Entwicklung spart, wenn man auf diese verbesserten Funktionen zurückgreifen kann.

Ich benutze die VCL natürlich auch gern. Aber es wäre doch viel besser,wenn der Compiler alles rausschmeißen würde, was nicht verwendet wird.

Tut er ja auch - zumindest zum Teil. Alle nicht benutzen Routinen landen nicht im Compilat. Aber einige Units initialisieren Dinge, die dann doch nicht gebraucht werden. Und es landen noch viele Ressourcen im Compilat, die meistens nicht benötigt werden. Guck dir das mal an und öffne eine VCL-Anwendung mit einem Ressourceneditor.

Luckie hat folgendes geschrieben :

Und es landen noch viele Ressourcen im Compilat, die meistens nicht benötigt werden.

Genau, meistens. Und da liegt auch schon das Problem:
Die Ressourcen werden per Compilerdirektive in Units eingebunden. Der Compiler kann schlicht nicht wissen welche davon zur Laufzeit angesprochen werden. Also muss er alle drin lassen, die in eingebundenen Units liegen.

Diese Sachen werden sich auch nicht ändern, da es beim Kompilieren eben noch nicht feststeht welche dieser Daten benötigt werden.

Man sieht jedenfalls immer wieder beim Debuggen wie viel der Compiler eigentlich rauswirft. Denn wenn man zur Laufzeit Routinen im Debugger nutzen will, die man im Programm nicht verwendet hat (z.B. Getter von Eigenschaften, die man im Code nur über das private Feld setzt), dann geht das eben nicht.

Luckie hat folgendes geschrieben :

...Guck dir das mal an und öffne eine VCL-Anwendung mit einem Ressourceneditor.

Sicherlich nichts weltbewegendes was letztenendes die Größe der Datei ausmacht... Aber genau das ist ein Punkt wo ich mich immer frage warum die ganzen Cursor mit in der EXE landen wenn sowieso der Standardcursor auf ner Form genutzt wird?!

jaenicke hat folgendes geschrieben :

Deshalb konnte die Standardeinstellung nur sein, dass keine Bibliotheken benötigt werden.

Nunja, in Borlands C++-Builder sind die Standardeinstellungen aber (leider?!) genau so (siehe www.delphi-forum.de/...e=quote&p=603891), daß man zur Benutzbarkeit der Compilate entweder dieses Softwarepaket oder wenigstens irgendwelche Bibliotheken auf dem Computer installiert haben muß - insoferst stimmt diese Aussage, daß die Standardeinstellung „nur so sein konnten“, eben nicht. Ich möchte allerdings nicht wissen, wieviel Verwirrung und gar Frustration bei unzähligen Empfängern der Compilate das schon auslöste, weil die eben unbenutzbar waren. Gerade, wenn man nicht werweißwie gierig nach einem Programm ist, ist es schneller wieder gelöscht, als es auf den Computer kam („Mist, Schrott, taugt nichts, funktioniert nicht...“). Zunächst war ich von den kleinen Exe-Dateien des C++-Builders auch begeistert, jedoch folgte recht bald die Ernüchterung.

Stellt man die betreffenden Optionen entsprechend so ein, daß die Exe-Dateien universell einsetzbar sind, werden die C++-Compilate leider größer als ihre Delphi-Pendants.

Sehr kleine Exe-Dateien, die anscheinend keine externen Bibliotheken benötigen, sind allerdings bei Nir Sofer (Nirsoft) verfügbar. Ich fragte ihn, womit er sie erstellt, und er antwortete mir „I use C/C++ in Microsoft Visual Studio.“

Don Krawallo hat folgendes geschrieben :

Aber genau das ist ein Punkt wo ich mich immer frage warum die ganzen Cursor mit in der EXE landen wenn sowieso der Standardcursor auf ner Form genutzt wird?!

Woher soll denn der Compiler wissen, dass du das nicht im Code irgendwo umschaltest? Zudem ändert sich der schon auf einem Editfeld.

Delphi-Laie hat folgendes geschrieben :

Sehr kleine Exe-Dateien, die anscheinend keine externen Bibliotheken benötigen, sind allerdings bei Nir Sofer (Nirsoft) verfügbar. Ich fragte ihn, womit er sie erstellt, und er antwortete mir „I use C/C++ in Microsoft Visual Studio.“

Nur weil diese Bibliotheken auf deinem PC schon drauf sind, heißt das nicht, dass keine benötigt werden.

jaenicke hat folgendes geschrieben :

Delphi-Laie hat folgendes geschrieben : Sehr kleine Exe-Dateien, die anscheinend keine externen Bibliotheken benötigen, sind allerdings bei Nir Sofer (Nirsoft) verfügbar. Ich fragte ihn, womit er sie erstellt, und er antwortete mir „I use C/C++ in Microsoft Visual Studio.“ Nur weil diese Bibliotheken auf deinem PC schon drauf sind, heißt das nicht, dass keine benötigt werden.

Das heißt also, in Windows (auch schon 9.x) ist die MFC-Bibliothek bereits enthalten?