RTTI abschalten oder minimieren - HowTo ?

[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ß

[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 von paule32.jk:

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 von paule32.jk:

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 von paule32.jk:

...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