Warum wird die Ressource verändert?

[jaenicke]

Zitat:

Zitat von venice2 (Beitrag 1479763)

Ich weis das es nicht kleiner geht aber es will mir nicht in den Kopf warum.
warum muss die EXE nun 3,5 MB groß sein.

Die RTTI sorgt u.a. dafür, dass du Funktionen, Objekteigenschaften usw. über den Namen ansprechen kannst. Damit kannst du auch solche verwenden, die im Code nie verwendet werden. Entfernt der Compiler diese Funktionen dann trotzdem, knallt es sobald jemand diese per RTTI verwenden möchte.
Umgekehrt verwenden Delphis Units intern selbst die RTTI, so dass sich diese auch nicht einfach so abschalten lässt, denn dann würde da wiederum manches nicht mehr funktionieren.

Du verwendest ein paar Funktionen, die dazu führen, dass viele bzw. große Units einkompiliert werden.

Original sind es bei mir 2516 KiB als Release (ohne deine Ressource und die INI-Unit).
Entfernst du einfach nur die VCL-Units Vcl.Clipbrd (Clipboard.AsText) und Vcl.Printers (AssignPrn, Printer.Canvas), halbiert sich die Größe schon auf 1206 KiB.
Entfernst du dann noch die Unit System.IOUtils (die in der Unit gar nicht verwendet wird) landest du schon bei nur noch 255 KiB.

Die Unit System.SysUtils würde nun noch knapp 100 KiB sparen, ist aber nicht so einfach zu ersetzen.

Zitat:

Zitat von venice2 (Beitrag 1479763)

Unter PowerBasic habe ich überhaupt keine Ressource inkludiert.
Und die DLL tut ihr Ding!

PowerBasic kann z.B. Funktionen nicht über den Namen ansprechen, weil es so etwas wie die RTTI dort nicht gibt. Deshalb werden dafür eben auch keine Informationen einkompiliert. Und auch die vorhandenen Bibliotheksfunktionen können ja deutlich weniger als bei Delphi.

[TiGü]

Das hat jetzt nichts mit der eigentlichen Fragestellung zu tun, aber es ist notwendig zu erwähnen:

Ich möchte in Hinblick auf eine Nutzung unter 64-Bit darauf hinweisen, die richtigen Datentypen zu verwenden.
Die Argumente hListBox: LongInt in GetTextListbox, hCtrl: DWORD in AddString und die Variablen hCtrl in ToolProc und ShowPopup sollten zwingend ein HWND sein.
Sonst kann man sich unter 64-Bit ganz merkwürdige Effekte einhandeln.

[himitsu]

Du kannst im Debug-Profil auch gern mal die Bereichsprüfung aktivieren, bzw. dir unter Debug ein SuperDebug-Profil erstellen und dort solche Prüfungen aktivieren.
Falsche Integer-Typen/Größen lassen sich so oft schnell finden.

Schon vor über 11 Jahren sind Viele über falsche String-Typen gestolpert, beim Unicode,
und nun kommt es mit 64 nochmals zurück. :lol:

[venice2]

Zitat:

die richtigen Datentypen zu verwenden.

Die richtigen Datentypen?
Ja was ist das? Delphi selbst kommt doch damit (von der Namensgebung) selbst schon nicht zurecht.

bsp.1
DWord -> System.Types.DWORD -> FixedUInt -> LongWord

bsp.2
Hwnd -> UINT_PTR -> System.UIntPtr -> NativeUInt

bsp.3
hInstance -> HINST -> System.HINST -> THandle -> NativeUInt

Delphi-Quellcode:

wClass.hInstance := hInstance;
wClass.hInstance := HINST;
wClass.hInstance := THandle;
wClass.hInstance := NativeUInt;

Nun suche dir etwas aus.


Das kann man jetzt mit PChar und anderen Datentypen so fortführen.
Kann man sich denn nun mal einigen welcher Datentype was, wo vom Namen her ist?

Aber ja du hast natürlich recht. Danke
Quelltext berichtigt und gelöscht damit ich mich nicht schämen muss.

[himitsu]

Das die meisten Typen über eine irre Hierarchi verfügen ist nunmal so. (viele Teile stammen aber auch schon so vom Hersteller "Microsoft" und wurden nur übernommen)

Mit "richtig" meinte ich sowas wie, dass man eine ANSI-API auch mit AnsiChar aufruft und nicht mit Char (damals vor 2009)
Jetzt nimmt man bei einer Wide-API eben auch WideChar anstatt Char (ab 2009)
Oder man nimmt eben bei einer dynamischen API eben Char anstatt AnsiChar/WideChar.

Dann passen Typ und API/Behandlung auch dann noch zusammen, wenn wie 2009 sich das alles geändert hat.




Genauso muß man eben auch aufpassen, wann man einen native (dynamischen) oder einen fixed Typen verwendet.

Ja, natürlich war bei Erfindung von 64 Bit (schon vor Delphi) es eine saublöde Idee den dynamischen "Integer" einzufrieren und dafür einen neuen Typen zu erfinden, der sich ab jetzt ändert. (in Delphi nennt der sich nun eben NativeInt bzw. NativeUInt und im C bissl anders)

Objekte in Integer casten war in den Mobilen auch eine leicht blöde Idee, wegen dem ARC (soll man nun wieder abgeschaltet haben, den Mist ... aber noch nicht selbst ausprobiert)
und Pointer in einen "Integer" oder gar in einen LongInt zu casten ging unter Win32 noch, aber für Win64 wäre NativeInt schöner gewesen.
Aber wenn man ganz sicher sein will, dann nimmt man für Pointer-Casts schon immer IntPtr/UIntPtr und bei Messages die Typen LPARAM/WPARAM/LRESULT, welche sich ebenfalls ans System anpassen.

[venice2]

Zitat:

Das die meisten Typen über eine irre Hierarchie verfügen ist nunmal so

Wollte nur mal darauf hinweisen.
@Tigü hatte aber schon recht es war einiges durcheinander habe es gefixt um auf der sicheren Seite zu sein.
Es ist schwer für Neueinsteiger durch diesen Dschungel von Datentypen durch zu blicken bei einer solchen Hierarchie.

Bei sowas hat man nun die Qual der Wahl.
Was mache ich nun nehme ich HINST oder Thandle oder vielleicht doch NativeUInt, so ein Quatsch!

Zitat:

hInstance -> HINST -> System.HINST -> THandle -> NativeUInt

[himitsu]

Nja, die Wahl ist nicht so groß, wie es aussieht.
Man nimmt nur den End-Typen. Dieser Typ wurde für ein spezielles Verhalten erfunden, einmal als Doumentation und um ihn eventuell auch mal ändern zu können.
Wenn Windows sich nun überlegt da was umzubauen, oder z.B. sich bei Win32/Win64/WinRT/Android/Linux/... etwas ändert, dann kann durch den OS-Hersteller und anschließend auch durch Delphi der "interne" Typ angepasst werden, ohne dass du am Code etwas ändern mußt.

HINST ist aktuell als HANDLE definiert (das wird sich vermutlich nicht ändern)
und ein HANDLE ist aktuell in Win32 32 Bit und in Win64 eben 64 Bit. (also das ändert sich gerade)

Die Wahl die du hier hast, ist HInstance oder HINST bzw. HINSTANCE, also Name des Delphi-Typ oder die Namen des Windows-Typen.
https://docs.microsoft.com/en-us/win...ows-data-types
Evetuell hat Delphi hier dann nur noch eine Ebene mehr eingefügt, um auch andere OS zu unterstützen, neben Windows, wo der jeweilige Typ dann eventuell von was Anderem erbt.



Es gibt hier leider nur ein Problem, nämlich dass das Code-Insight leider dein "Ursprungstypen" anzeigt, anstatt des "Alias", da dieser keine eigene RTTI besitzt.
So dass man in den Hints nicht den "richtigen" Typen sieht ... daher besser immer direkt die Implementation ansehen (Strg+Linksklick).

Delphi-Quellcode:

type
  A = Integer;  // Alias
  B = type Integer;  // neuer Typ

  X = TObject;
  Y = type TObject;
  Z = class(TObject);  // Ableitung

[Daniel]

Stop, Ihr seid vom Ausgangsthema abgekommen. Emil, eröffne bei Bedarf bitte ein neues Thema.

[venice2]

Zitat:

Zitat von Daniel (Beitrag 1479815)

Stop, Ihr seid vom Ausgangsthema abgekommen. Emil, eröffne bei Bedarf bitte ein neues Thema.

Ist mir auch schon aufgefallen. Danke.
Für mich wurde alles gesagt was meine frage angeht von daher ist es abgeschlossen.

[KodeZwerg]

Noch ein mini Hinweis um kompilierte Dateien zumindest etwas abzuspecken: Direktive SetPeFlags nutzen.
Keine relocations, keine debuginfos usw... einfach mal probieren.
Viel Glück und frohes Fest.