Warum wird die Ressource verändert?

[venice2]

Ich erstelle ne Ressource.

Code:

IDR_VERSION1 VERSIONINFO
FILEVERSION 1,1,0,0
PRODUCTVERSION 1,1,0,0
FILEOS 0x00000004
FILETYPE 0x00000001
BEGIN
  BLOCK "StringFileInfo"
  BEGIN
    BLOCK "04070000"
    BEGIN
      VALUE "FileVersion", "1.1.0.0\0"
      VALUE "ProductVersion", "1.1.0.0\0"
      VALUE "CompanyName", "BrewIdeas@Emil Weiss\0"
      VALUE "FileDescription", "Tracer64\0"
      VALUE "InternalName", "Tracer64\0"
      VALUE "LegalCopyright", "2020 by Emil Weiss\0"
      VALUE "LegalTrademarks", "BrewIdeas@Emil Weiss\0"
      VALUE "OriginalFilename", "Tracer64.dll\0"
      VALUE "ProductName", "Tracer64\0"
    END
  END
  BLOCK "VarFileInfo"
  BEGIN
    VALUE "Translation", 0x0407, 0x0000
  END
END

Jetzt meine einfache Frage warum wird bei 64 Bit dieser ganze Müll vom Compiler hinzugefügt?
Wie kann ich das abstellen.!

Ich mache doch nicht umsonst eine Minimal Ressource.
20 Zeilen Code und eine DLL > 3MB was für ein Schmarrn

Rein Programmiertechnisch gesehen sind das gerade mal 45K. (An Bit und Bytes) Wenn überhaupt!

Die gleiche DLL mit PowerBasic kompiliert ist 52KB groß nur mal so nebenbei.

[Rolf Frei]

Weil jedes Delphiprogamm eine Unmenge an RTTI Informationen mit reinkompiliert. Wenn dich die Grösse stört nimm Delphi 7 oder sonst was altes, das noch ohne RTTI funktioniert. Die neuen Delphikompiler produzieren dank RTTI riesige Dateien, auch wenn sonst nichts im Programm gemacht wird. Das lässt sich leider nicht abschalten.

Hast du irgendwo die Forms Unit includiert und brauchst du diese? Wenn man ohne diese auskommt wird das Programm shon mal deutlich kleiner, aber immer noch weit entfernt von dem was man erwarten würde. Wirklich kleine Anwendungen sind mit aktuellen Delphi's leider nicht mehr möglich.

[venice2]

Zitat:

Zitat von Rolf Frei (Beitrag 1479760)

Weil jedes Delphiprogamm eine Unmenge an RTTI Infornmatiion mit einkompiliert. Wenn dich die Grösse stört nimm Delphi 7 oder sonst was altes, das noch ohne RTTI funktioniert. Die neuen Delphikompiler produzieren dank RTTI riesige Dateien, auch wenn sonst nichts im Programm gemacht wird. Das lässt sich leider nicht abschalten.

Traurig.
Das es auch anders geht sehe ich an PowerBasic.
Diesen Müll braucht man nicht wirklich.

[Daniel]

Welche Compiler-Schalter hast Du denn gesetzt, um die Menge an RTTI-Informationen zu reduzieren?

[venice2]

Zitat:

Zitat von Daniel (Beitrag 1479762)

Welche Compiler-Schalter hast Du denn gesetzt, um die Menge an RTTI-Informationen zu reduzieren?

Delphi-Quellcode:

{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

Ich weis das es nicht kleiner geht aber es will mir nicht in den Kopf warum.
Abhängig vom Compiler Type ist es ohne weiteres möglich kleine Daten zu generieren abhängig von der fast realen Größe an Bit und Bytes.
Das nervt halt manchmal.

Das ist alles an Code..


warum muss die EXE nun 3,5 MB groß sein.
Unter PowerBasic habe ich überhaupt keine Ressource inkludiert.
Und die DLL tut ihr Ding!

[himitsu]

Die "StringTables", das ist alles, was im Delphi mit

Delphi-Quellcode:

resourcestring

definiert wurde. (damit Sprachübersetzungen an die Konstanten rankommen)
Units SysConst sind immer enthalten und müssen drin bleiben.
Man könnte die Tabellen editireren ein Einträge/Zeilen, die man "denkt" niemals zu brauchen, durch ein Leerzeichen (1 Char) ersetzen.

"24" (WindowsManifest) kann man in den Projektoptionen abschalten (das würde ich aber nicht weglassen, vorallem nicht den OS-Kompatibilitätsabschnitt)

Die Icons/IconGroup kommen immer rein, entweder Deines oder ein StandardIcon.
Die könnte man aber nachräglich löschen. (RessourceEditor)
Oder du verwendest ein kleines einfarbiges SchwarzWeisIcon. (1 Bit Farbtiefe)

DVCLAL gehört zur Delphi-Lizenz und gibt an mit welcher Delphiversion, bzw. mit welcher Edition (Starter/Pro/Ent/Arch) kompiliert wurde.
De muß drin bleiben. (wird auch von einigen Programmteilen benutzt, z.B. von Komponenten der Architect, welche nicht in anderen Editionen laufen wollen/dürfen)

PACKAGEINFO ist eine UnitListe.
k.A. ob eine alleinstehende EXE die verwendet, aber beim Laden von Packages (BPL) sind sie zwingend notwendig.

das neue PLATFORMTARGETS seit Delphi 10.irgendwas (keine Ahnung, aber ist eh unbedeutend Klein)

MSG_ERROR/INFO/WARNING willst du haben, da du irgendwo die Dialogs.res (Vcl.Dialogs / Dialogs.pas) eingebunden hast.

[Rolf Frei]

Diese Compilerswitches bringen nicht wirklich was, weil diese nur auf den eigenen Code Auswirkung hat. Um das ganze RTTI Zeugs in dene Basis Units zu entfernen, müsste die Delphi Basisklassen (System, Classes, etc) neu ohne RTTI kompiliert werden. Das geht aber nicht so einfach, wie man meinen könnte. Eigentlch ist das unmöglich, weil man die System untis nicht neu konmpilieren kann.

OP du kannst ja mal folgende Switsches verwenden, wird dir aber wegen obigen Gründen auch nicht wirklich weiterhelfen.

Code:

{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

[venice2]

Zitat:

Zitat von Rolf Frei (Beitrag 1479765)

Diese Compilerswitches bringen nicht wirklich was, weil diese nur auf den eigenen Code Auswirkung hat. Um das ganze RTTI Zeugs in dene Basis Units zu entfernen, müsste die Delphi Basisklassen (System, Classes, etc) neu ohne RTTI kompiliert werden. Das geht aber nicht so einfach, wie man meinen könnte. Eigentlch ist das unmöglich, weil man die System untis nicht neu konmpilieren kann.

OP du kannst ja mal folgende Switsches verwenden, wird dir aber wegen obigen Gründen auch nicht wirklich weiterhelfen.

Code:

{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

Habe ich schon drin siehe Code oben.
Na bringt max 200 KB.

Ich wollte nur sagen das es mich nervt.
Wenn es nicht anders abschaltbar ist dann ist gut. ;)
Aber trotz alle dem es geht auch anders.

[Bernhard Geyer]

Zitat:

Zitat von venice2 (Beitrag 1479763)

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

Und wieso nutzt du dann dafür nicht weiter PowerBasic?
Viele der Vorteile von Delphi bekommt man mit der Komponentenbiliothek.
Wenn du diese nicht nutzt, wieso dann nochmal mit Delphi nachimplementieren?

Meine "kleinste richtige DLL" ist mit 10.2 für Win32 ca. 750kByte.

[venice2]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1479767)

Zitat:

Zitat von venice2 (Beitrag 1479763)

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

Und wieso nutzt du dann dafür nicht weiter PowerBasic?
Viele der Vorteile von Delphi bekommt man mit der Komponentenbiliothek.
Wenn du diese nicht nutzt, wieso dann nochmal mit Delphi nachimplementieren?

Meine "kleinste richtige DLL" ist mit 10.2 für Win32 ca. 750kByte.

Es geht nicht darum warum, weshalb sondern das es möglich ist!
Das ist der kleine Unterschied.

Und was verstehst du unter richtige DLL denkst du meine wäre falsch?
Sie tut was sie soll.

[Bernhard Geyer]

Zitat:

Zitat von venice2 (Beitrag 1479768)

Es geht nicht darum warum, weshalb sondern das es möglich ist!
Das ist der kleine Unterschied.

Klar ist es möglich. Aber Delphi ist halt nicht darauf ausgelegt kleine DLLs zu erzeugen.
Und wenn es nicht ohne sehr große Klimmzüge möglich ist, akzeptiert man einfach das es so ist oder nimmt einfach eine andere IDE, welche das kann.

Zitat:

Zitat von venice2 (Beitrag 1479768)

Und was verstehst du unter richtige DLL denkst du meine wäre falsch?

Es gibt sogenannte Ressourcen-DLLs die können noch kleiner werten, da sie keine Ausführbaren Code beinhalten.

[Rolf Frei]

Zitat:

Zitat von venice2 (Beitrag 1479766)

Zitat:

Zitat von Rolf Frei (Beitrag 1479765)

Diese Compilerswitches bringen nicht wirklich was, weil diese nur auf den eigenen Code Auswirkung hat. Um das ganze RTTI Zeugs in dene Basis Units zu entfernen, müsste die Delphi Basisklassen (System, Classes, etc) neu ohne RTTI kompiliert werden. Das geht aber nicht so einfach, wie man meinen könnte. Eigentlch ist das unmöglich, weil man die System untis nicht neu konmpilieren kann.

OP du kannst ja mal folgende Switsches verwenden, wird dir aber wegen obigen Gründen auch nicht wirklich weiterhelfen.

Code:

{$WEAKLINKRTTI ON}
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

Habe ich schon drin siehe Code oben.
Na bringt max 200 KB.

Ich wollte nur sagen das es mich nervt.
Wenn es nicht anders abschaltbar ist dann ist gut. ;)
Aber trotz alle dem es geht auch anders.

Ja hast deine Nachricht nach meiner geschrieben. Übrigens hat die Grösse der EXE praktisch nichts mit den Resourecen zu tun. Das was bei dir in den Resourcen ist, sind Formen (DFM-Daten die als Resoruce reingelinkt werden) aus der Basisbibliothek von Delphi. Diese machen aber dein Progamm nicht wirklich massiv grösser. Das Problem ist die RTTI, die bei allen Delphi Basisklassen mit reinkompiliert wurden. Um das zu umgehen. müsstest du alle Delphi DCS's neu durchkompileren und bei allen die RTTI Flags setzen. Das geht aber leider nut therotisch und in der Praxis ist das praktisch unmöglich. Wollte das selber schon mal machen und habe dann aber relativ schnell aufgegeben.

Eben mal getestet:
Eine minimale Consolenapp, die nur die SysUtils nutzt, ist nun mit aktuellen Delphi's im Release Build um die 150 KB. Bei D7 wird eine leere Consoleapp 41 KB gross. Sobald du da bestimmte Untis verwendest explodiert das und du hast dann >2 MB. In deinem Fall sind die Untis Clipprd, Printers und IOUtils dafür verantwortlich.

Hats du deine exe mit dem Release Build kompiliert oder nur mit Debug?

[venice2]

Ok es ist wie es ist damit muss ich dann leben. Danke.

Zitat:

Hats du deine DLL mit dem Release Build kompiliert oder nur mit Debug?

Release..

[himitsu]

Zitat:

Das Problem ist die RTTI

und die Generics (bzw. der unschön generierte Code daraus)

Bei Code kann der Compilier/Linker auch Ungenutztes weglassen,
aber bei eingebundenen RES, kann er nicht erkennen, ob nötig oder nicht.
Sobald ein

Delphi-Quellcode:

{$R irgendwas.res}

in einer einkompilierten Unit drin steckt, dann bleibt es drin, selbst wenn der verwendende Code garnicht benutzt und vom daher vom Linker weggelassen wurde.

[venice2]

Zitat:

Sobald ein {$R irgendwas.res} in einer einkompilierten Unit drin steckt, dann bleibt es drin, selbst wenn der verwendende Code garnicht benutzt und vom daher vom Linker weggelassen wurde.

Keine Ahnung ob den den besagten Units (Clipprd, Printers und IOUtils) eine Res eingebunden ist.
Im Meinem Projekt habe ich diese komplett entfernt aber lach. Sie wird trotzdem eingebunden.

[himitsu]

Du kannst dir vom Compiler die MAP-Datei erstellen lassen (Projektoptioen),
da steht alles drin, was drin ist.

Oder du schaust kurz in die PACKAGEINFO-Ressource.
Die ist zwar binär, aber die Unitnamen kann man auch so erkennen.

[Rolf Frei]

Zitat:

Zitat von venice2 (Beitrag 1479775)

Zitat:

Sobald ein {$R irgendwas.res} in einer einkompilierten Unit drin steckt, dann bleibt es drin, selbst wenn der verwendende Code garnicht benutzt und vom daher vom Linker weggelassen wurde.

Keine Ahnung ob den den besagten Units (Clipprd, Printers und IOUtils) eine Res eingebunden ist.
Im Meinem Projekt habe ich diese komplett entfernt aber lach. Sie wird trotzdem eingebunden.

Wie gesagt sind diese Resourcen minimal und machen die Exe nicht wirklich grösser. Wir reden hier von ein paar KB. Wenn du Texte mit resourcestring definiest, und davon gibt es seher viele in den Delphi Basis Units, kommen diese auch in die Resource der Exe (stringtable). Die MSG_xxx, etc. sind glaube ich die Symbole für Delphi Messageboxen. Die Cursors sind die Mauszeiger Symbonlresourcen, die über eine Unit hineinkommen (Classes?). DVCLAL ist eine spezielle Resource, die der Conmpiler automatisch einfügt und die Infos darüber enhält mit welcher Delphiversion sie erzeugt wurde.

Betreffs meinen gelisteten Units hast du da was falsch verstanden. Es geht dabei nicht um die Resourcen die daruch grösser werden sondern die Exe selber durch die zusätzlichen RTTI Informationen, die nicht in der Resource abgelegt werden. Also vergiss bitte die Resourcen, die sind nicht dein Problem hier, was die Grösse betrifft.

Habe nun mal die Sourcen angeschaut und dabei gesehen, dass die Forms Unit in Printers genutzt wird. Das macht deine Exe so gross. Wenn du die Printers Unit entfernst und alles selber machst, was sonst die Printers Unit macht, dürfte die Grösse schon mal deutlich kleiner werden, sofern natürlich diese Forms Unit nur da genutzt wird. Wenn du es schafst, dass die Forms unit nicht mehr in deine Exe gelinkt wird, wirst du dann eine deutlich kleinere EXE bekommen.

[venice2]

Zitat:

Betreffs meinen gelisteten Units hast du da was falsch verstanden.

Nein ich habe das schon richtig verstanden.
Meine Antwort bezog sich auf die Info von himitsu bzg.

Zitat:

Sobald ein {$R irgendwas.res} in einer einkompilierten Unit drin steckt, dann bleibt es drin, selbst wenn der verwendende Code garnicht benutzt und vom daher vom Linker weggelassen wurde.

Ob diese Units Ressourcen verwenden oder nicht.
Denn bei mir werden sie immer eingebunden egal ob ich da etwas definiert habe oder nicht.

Das die RTTI das Problem ist habe ich schon verstanden. Danke

[Rolf Frei]

RTTI ist nur ein Teil des Problems, der andere und hier vieleicht der entscheidendere ist, dass die Forms unit verwendet wird. Das macht den grössten Unterschied. Kommentiere doch mal bei dir die Printers Unit und allen Code aus, der diese nutzt und compiliere dann. Beachte bitte auch deine uIni Unit, was da genau benutzt wird. Die Exe sollte dann deutlich kleiner werden. Das ist ein Problem dass seit jeher besthet und nichts mit RTTI zu tun hat sondern damit, dass die Forms Unit so viele Abhängikeiten hat, dass alles mögliche in die Exe gelinkt wird, was man eigentlich in deimem Fall garnicht braucht. Meine Test-Consolenanwendung in D7 wächst durch die Verwendung von Printes auch von 41 KB auf 393 KB. In neueren Delphi's macht das noch deutlich mehr aus.

[generic]

Zitat:

Zitat von Rolf Frei (Beitrag 1479760)

Weil jedes Delphiprogamm eine Unmenge an RTTI Informationen mit reinkompiliert. Wenn dich die Grösse stört nimm Delphi 7 oder sonst was altes, das noch ohne RTTI funktioniert. Die neuen Delphikompiler produzieren dank RTTI riesige Dateien, auch wenn sonst nichts im Programm gemacht wird. Das lässt sich leider nicht abschalten.

Aber die RTTI Informationen liegen doch nicht in den Ressourcen.

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

[himitsu]

Zitat:

Zitat von KodeZwerg (Beitrag 1479857)

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.

Wozu? Und wer behaupter immer, dass solche Dinge wie die ReallocationsTabellen "nutzlos" seien und man sie einfach so entfernen darf?
https://de.wikipedia.org/wiki/Addres..._Randomization , welches auf Servern gern aktiv ist und auch auf HeimPCs darf man das nutzen, wenn man von böswilligen Entwicklern nicht dran gehindert wird.
Und die Debuginfos ... Delphi speichert seine eh ganz anders.