Das CONST mit {$J+} könnte man als "private globale Inlinevariable" betrachten.
https://docwiki.embarcadero.com/RADS...tants_(Delphi)
Vom besseren "Verständnis" her, würde ich aber vom
{$J+}
bzw.
{$WRITEABLECONST ON}
abraten.
-> also stattdessen eine "richtige" globale Variable, bzw. als Private in eine Klasse, oder Dergleichen.
Aber wenn doch, wäre es wenigstens angebracht die "langen" Varianten solcher Settings zu verwenden, weil bissl "verständlicher".
Nja, auf "normalen" Windows-Versionen dürft ASLR doch standardmäßig deaktiviert sein.
Ich glaub nur auf Windows-Server wird sowas eventuell per Default auf Aktiv gestellt sein.
Somit kommen die meisten Nutzer damit nicht in Berührung.
Und da Windows normal versucht kleine Speicheradressen zu belegen, außer ASLR ist aktiv, oder z.B. VirtualAlloc+MEM_TOP_DOWN,
fallen Fehler seltener auf, wenn z.B. Pointer durch falsche Casts/Typen auf 32 Bit abgescnitten werden. (so wie es hier der Fall war)
Einen winzigen Nachteil hat ASLR noch.
* normal kann Arbeitsspeicher von Executables (EXE/
DLL/
BPL) wiederverwendet werden, was Ladezeit und bissl Speicher spart.
* wenn ASLR aktiv ist, liegt theoretsch jede EXE/
DLL wo anders in den virtuellen Speichern, also wird sie überall exlusiv (mehrmals) geladen, weil dabei ja Adressen im Code überall anders übersetzt werden müssen.
* gut, dass es JETZT knallt, ist kein Fehler des ASLR ... bei vollem Programmspeicher hätte es so oder so geknallt
* der Vorteil ist dann aber dass "bösartige" Überläufe auf "feste" Adressen nun höchstwahrscheinlich nicht das kaputt machen, was sie wollten
* * wenn der Böse aber sich vorher die "richtige" Position besorgt, dann hilft ASLR auch nichts
https://learn.microsoft.com/de-de/wi...-in-windows-10