RTTI abschalten oder minimieren - HowTo ?

[paule32.jk]

Hallo,
kann man die RTTI's in der DCE 12 abschalten oder zumindest minimieren ?

[Aliquis]

Hallo,

Delphi-Quellcode:

  {$IF CompilerVersion >= 21.0}
  {$WEAKLINKRTTI ON}
  {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}
  {$IFEND}

Das steht so in der Hilfe.Vielleicht ist es das, was du suchst?

[TomyN]

Ich bin mir nicht sicher, ob es das ist, was du suchst:

Projektoptionen -> Erzeugen -> Delphi-Compiler -> Compilieren -> Quelltexterezugung -> Laufzeittypinformationen ausgeben

[paule32.jk]

moin moin,

irgendwie muss DCE 12 mitbekommen, wenn man unter einer anderen PID das erstellte Programm/Anwendung/Bibliothek betrachtet.
kann sicherlich sein, dass das sowas wie ein Kopierschütz ist... ?
habe das jetzt schon öfters erlebt.
kann jemand was dazu sagen ?

[Sinspin]

Erstmal, die Regeln hier haben sich noch nicht geändert. Eine Frage pro Thread bitte.

Zitat:

Zitat von paule32.jk (Beitrag 1539633)

irgendwie muss DCE 12 mitbekommen, wenn man unter einer anderen PID das erstellte Programm/Anwendung/Bibliothek betrachtet.

Warum auch nicht?

Zitat:

Zitat von paule32.jk (Beitrag 1539633)

kann sicherlich sein, dass das sowas wie ein Kopierschütz ist... ?

Das ist Unsinn. Du kannst deine Programme tausendemale ausführen wo immer Du willst.

Wenn da was abschmiert haste Mist programmiert. Soll ja selbst den Besten immer malwieder passieren.

[paule32.jk]

Hallo Sinspin,

die Fragen gehen in Richtung: Leistungssteigerung.
Also auch, das die IDE von DCE 12 regelmäßig abstürzt.
Und ich bin halt auf der Suche, warum das denn so sein kann.

Das dann Cross-Postings aufkommen, ist nicht gewollt.

Ist nur halt komisch...

[paule32.jk]

okay.

Ich habe mal ein wenig mit den Projekt-Optionen gespielt, und bin dann auf "Linken mit Laufzeitpackages" gestoßen.
Dabei viel mir auf, das die Option für den DCE 12 Linker auf FALSE eingestellt war, und ich somit angenommen habe,
das da keine Laufzeitpackages mit in die EXE einfließen würden.

Wenn ich das Option-Kästchen auf TRUE setze, dann wird die EXE um einiges kleiner.
Da bin ich nun von knapp 350 KB, auf stolze 25 KB gekommen.

Das ist irgendwie verwirrend die ganze Sache...

Aber was die Größe anbelangt, bin ich durchaus zufrieden.
Wenn ich dann noch UPX.exe über die 25 KB loslasse, dann bin ich bei ca. 10 KB zu Hause,
was auch schon eine beachtlich kleine Anwendung darstellt.

Im Image habe ich dann nach bpl gesucht, aber ich konnte noch keine finden, was mich zu der
Annahme verleitet, das die RunTime Funktionen von Delphi nicht immer übernommen werden und
erst bei Gebrauch gelinkt werden, womit ich auch zufrieden bin.

Die Verringerrung des Icons brachte auch ein paar kleine Unterschiede in punkto Größe.
Es kann also heißem:
stay tuned ...

[peterbelow]

Zitat:

Zitat von paule32.jk (Beitrag 1539642)

okay.

Ich habe mal ein wenig mit den Projekt-Optionen gespielt, und bin dann auf "Linken mit Laufzeitpackages" gestoßen.
Dabei viel mir auf, das die Option für den DCE 12 Linker auf FALSE eingestellt war, und ich somit angenommen habe,
das da keine Laufzeitpackages mit in die EXE einfließen würden.

Wenn ich das Option-Kästchen auf TRUE setze, dann wird die EXE um einiges kleiner.
Da bin ich nun von knapp 350 KB, auf stolze 25 KB gekommen.

Das ist irgendwie verwirrend die ganze Sache...

Aber was die Größe anbelangt, bin ich durchaus zufrieden.
Wenn ich dann noch UPX.exe über die 25 KB loslasse, dann bin ich bei ca. 10 KB zu Hause,
was auch schon eine beachtlich kleine Anwendung darstellt.

Im Image habe ich dann nach bpl gesucht, aber ich konnte noch keine finden, was mich zu der
Annahme verleitet, das die RunTime Funktionen von Delphi nicht immer übernommen werden und
erst bei Gebrauch gelinkt werden, womit ich auch zufrieden bin.

Die Verringerrung des Icons brachte auch ein paar kleine Unterschiede in punkto Größe.
Es kann also heißem:
stay tuned ...

Wenn Du ein Projekt mit runtime-packages baust erfordert die EXE einen Haufen BPLs, für die Delphi RTL, VCL, FMX, was immer Du auch verwendest. Auf dem Entwicklungsrechner sind die alle vorhanden, aber wenn Du die EXE auf einen anderen Rechner kopierst läuft sie dort nicht. Du mußt dann alle notwendigen BPLs mit kopieren. Im Allgemeinen ist die Summe der Größen aller notwendigen Dateien deutlich größer als die der monolitischen EXE ohne packages.
Packages machen nur Sinn für umfangreiche Projekte aus vielen Modulen (EXEs), die sich viele Packages teilen. Dann kann die Größe der Distribution dadurch kleiner werden, aber die Installation wird komplexer. BPLs = Embas Version der DLL Hell.:wink:

[blawen]

Zitat:

Zitat von paule32.jk (Beitrag 1539642)

Wenn ich das Option-Kästchen auf TRUE setze, dann wird die EXE um einiges kleiner.
Da bin ich nun von knapp 350 KB, auf stolze 25 KB gekommen.

Das ist irgendwie verwirrend die ganze Sache...

Aber was die Größe anbelangt, bin ich durchaus zufrieden.
Wenn ich dann noch UPX.exe über die 25 KB loslasse, dann bin ich bei ca. 10 KB zu Hause,
was auch schon eine beachtlich kleine Anwendung darstellt.

Die Verringerrung des Icons brachte auch ein paar kleine Unterschiede in punkto Größe.

Ob das File 350 kB gross ist oder nur 10 kB ist eigentlich egal, in beiden Fällen ist die Datei Grösse deutlich kleiner als die Cluster Grösse - Sprich, ich spare schlussendlich nichts ein.

Meine Erfahrung mit kleinen Files ist aktuell, dass mein Virenscanner anspricht. UPX unterstützt noch das Misstrauen des Virenscanners.

Und ja, je grösser das Bild umso stärker ist die Gewichtung bei kleinen Files.

[stifflersmom]

Zitat:

Zitat von blawen (Beitrag 1539646)

Ob das File 350 kB gross ist oder nur 10 kB ist eigentlich egal, in beiden Fällen ist die Datei Grösse deutlich kleiner als die Cluster Grösse - Sprich, ich spare schlussendlich nichts ein.

Na ja, die default-Clustergröße bei NTFS, und das haben die meisten Windowsentwickler auf ihrer Festplatte/SSD, ist bestimmt nicht 350kb groß...
Die liegt bei Festplatten bis 16 TByte bei 4kb

[paule32.jk]

nu.
- er meint sicherlich Sektor-Größe - die ist Standard 4.096 Bytes oder 4 KB groß.
- selbst mit Assembler habe ich keine gültige Windows .EXE programmieren können, die kleiner als 2.048 Bytes ist.

Man muss halt abwiegen:
- viele Dateien kleinere, kleine Sektor-Größe
- wenige Dateien größere Dateien, größere Sektor-Größe...

Ok, zurück:
Ich habe jetzt aus dem Verzeichnis:
C:\Program Files (x86)\Embarcadero\Studio\23.0\bin

- die rtl290.bpl in das Verzeichnis meiner "kleinen" Ausgabedatei kopiert
- vorher hat Windows gemekkert, das rtl290.bpl nicht auffindbar ist
- nun bekomme ich den Fehler 0x0007b - was auf ein Image-Fehler hindeutet
- die rtl290.bpl ist rund 12 MegaByte groß :coder2:

[himitsu]

So kleine Dateien landen bei NTFS eh in der MFT, als Attribut am Datensatz, und nicht in einem eigenen Sector Cluster auf der Platte. (falls ich das richig verstanden hatte)

Das Meiste spart man ein, wenn einfach nur die Debuginfos nicht gelinkt werden. (RELEASE)

[paule32.jk]

ja, richtig: RELEASE.
Aber mich würde doch schonmal interessieren, warum da ein 0x007b Fehler kommt, wenn man die RT Pakete nicht mit einlinkt...
Wie der Peter schon schrieb, macht das ja auch irgendwann oder irgendwie Sinn.

[paule32.jk]

ok.
ich habe es jetzt hindeicseln können:
in den Optionen:
- RELEASE
- ohne Packages (TRUE)
- Optimize

dann eine Batch-Datei (run.bat):

Code:

@echo off
set BDS=C:\Program Files (x86)\Embarcadero\Studio\23.0
set BDSINCLUDE=C:\Program Files (x86)\Embarcadero\Studio\23.0\include
set BDSCOMMONDIR=C:\Users\Public\Documents\Embarcadero\Studio\23.0
set FrameworkDir=C:\Windows\Microsoft.NET\Framework\v4.0.30319
set FrameworkVersion=v4.5
set FrameworkSDKDir=
set PATH=%FrameworkDir%;%FrameworkSDKDir%;C:\Program Files (x86)\Embarcadero\Studio\23.0\bin;C:\Program Files (x86)\Embarcadero\Studio\23.0\bin64;C:\Program Files (x86)\Embarcadero\Studio\23.0\cmake;%PATH%
set LANGDIR=DE
set PLATFORM=
set PlatformSDK=

.\win64\Release\<das programm.exe>

und der 0x007b Fehler fly away...

wenn ich nun auch noch upx.exe auf die bestehende DLL und die Startanwendung (EXE) losjage, dann bin ich bei 21 KB zu Hause.
Somit: Fall gelöst.

[Sinspin]

Lade dein UPX-tes Programm mal bei VirusTotal hoch und schau dir an wieviele Scanner dein Programm als Virus erkennen.

UPX ist niemals eine clevere Idee wenn man sein Programm vielen Leuten weitergeben will. UPX-te Programme werden oft als Viren erkannt. Das wird sich auch nicht ändern.

[paule32.jk]

nu.
Ich will ja keinen Virus verbreiten.

Ich komme aus der MS-DOS Welt, wo Bits und Bytes noch sehr hoch im Kurs standen, soviel wie möglich, mit so wenig binary Code zu erzeugen.
Da hat man zum Beispiel ein "ClearScreen" programmiert, um den Bildschirm zu löschen.
Heute muss man einen weit aus höheren Aufwand betreiben, das ein Fenster als Vollbild dargestellt wird, und in diesen der dargestellte Text dann gelöscht werden soll, weil man eine weitere Bildschirm(text)seite darzustellen, aber dafür dann megabytes an binary auf der Festplatte zu verbraten.

Das ist so ziemlich der gröbste Wunsch von mir, wieder auf das Level zu kommen, wo man mit kleinen Programmen, viel schafft.

Aber: Ja, da gebe ich Euch recht, das Heute (aus welchen Gründen auch immer) Software immer schneller fertig werden muss, und es diese DLL Hell gibt, wenn ständig pätsches riliesed werden (müssen).

[himitsu]

UPX und Anderes kennen aber viele (ordentliche) Virenscanner und entpacken es vor der Analyse.
Was dann oft nur noch angemeckert wird, sind modifikationen/verschleierungen, welche dieses Entpacken verhindern sollen.

Was aber "normal" unpraktisch war, dass sowas z.B. Optimierungen für ein schnelleres Laden verhindert, durch Wiederverwenden und Teilen von vorbereitetem DLL-Speicher,
aber seit ASLR relativiert das sich etwas.

Die Ersparnis durch UPX war gegen die Nachteile nur noch minimal, da Speicher und Traffic diesbezüglich selbst eigentlich kein Problem mehr sind.

[paule32.jk]

nu.
Den UPX kann ich ja weg lassen, dann habe ich aber immernoch ein "kleines" Image.
Ich bin das erzeugte Image mal durchgegangen, und fand nur einen Eintrag auf rtl290.bpl.
Ich vermute aber, das dazu noch etliche DLL-images dazugehören... ?

Hat da schonmal Einer/Eine eine Liste gemacht, und so großzügig ist, diese zu teilen ?
Die Windows DLL images, sind schon klar (kernel32 und user32).

[TiGü]

Zitat:

Zitat von paule32.jk (Beitrag 1539670)

Hat da schonmal Einer/Eine eine Liste gemacht, und so großzügig ist, diese zu teilen ?
Die Windows DLL images, sind schon klar (kernel32 und user32).

Sieht man alles im Event Log Window der IDE während des Debuggens, wenn man Module Messages aktiviert.

https://docwiki.embarcadero.com/RADS...nt_Log_Options
https://docwiki.embarcadero.com/RADS...ent_Log_Window

[Sherlock]

Ich will Dir wirklich nicht den Wind aus den Segeln nehmen, aber

Zitat:

Zitat von paule32.jk (Beitrag 1539667)

Ich komme aus der MS-DOS Welt, wo Bits und Bytes noch sehr hoch im Kurs standen,...

MS-DOS ist eine Welt die schon lange untergegangen ist. Vielleicht fühlst Du Dich mit Unix wohler.

Zitat:

Zitat von paule32.jk (Beitrag 1539667)

...und es diese DLL Hell gibt...

Da trägst Du gerade einen guten Anteil dazu bei, daß diese Hölle weiter bestand hat. Denn die BPL, die Du ab jetzt mit ausliefern musst, ist fix IDE versionsgebunden. Wenn also eine 12.2 oder ein 14.0 rauskommt, dann funktioniert Deine 10kB Exe nicht mehr mit den 12 MB von Delphi 12.1. Eine Stärke von Delphi ist die Möglichkeit monolithische EXEn zu erzeugen, die eine XCopy Installation ermöglichen. DLLs und BPL sollten eine bewusste Designentscheidung sein, und nicht einem vorgestrigen Zwang zur Größenreduktion entspringen.

Wenn Du das natürlich alles aus Spaß machst, dann viel Freude an der kleinen EXE mit der großen BPL.

Und UPX gepackte EXEn sind in nicht wenigen Firmen ein nogo.

O'Neill

[paule32.jk]

nu.
Ihr habt ja recht.
Im Gegensatz zu 12 MB sind die EXE mit 400 KB Pinatz.

Der Thread kann erstmal als "solved" makiert werden.

[himitsu]

Jo, abgesehn davon, dass es mit BPL mehr ist, da in BPLs immer alles drin ist,
während in die EXE einkompiliert, der Linker viel Ungenutztes weglassen kann.

Hat man oft kleine/teilweise Updates, innerhalb der selben Delphi-Version und besteht das Projekt aus vielen eigenen EXE/DLLs, dann können BPLs eine gute Wahl sein, z.B. auch wenn man massig und/oder große Fremdbibliotheken nutzt, ala DevExpress.
Bei uns ist alles knapp über einem Gigabyte und da dann nur eine 2 MB EXE/BPL/DLL zu tauschen, das merkt man schon, bzw. ich stelle vom FinalBuilder auch noch einige ZIP bereit, also mit "Allem aus unserem eigenen Quellcode", Fremdkomponenten, sowie Zusätzliches (Python und Anderes).

BPL ist mehr mit sowas wie beim .NET und der C++-Runtime-Library oder dem Java-Runtime-Environment zu vergleichen.
Die EXE ist schön klein, aber dahinter liegt ein fettes Framework, was immer ALLES drin hat, was vielleicht mal wer braucht oder nicht.

Zitat:

Der Thread kann erstmal als "solved" makiert werden.

Nur, wenn der Thread-Ersteller zu Beginn das "als offen markieren" angehakt hat, dann kann er es später "schließen".
Ansonsten bleibt es eh immer quasi offen, falls irgendwann mal wieder jemand das gleiche Problem hat, es für ihn aber noch keine Lösung gibt und er sich einfach hier anschlieen könnte.