Also woher kommt die Ursprungsdatei denn?
Die Ursprungsdatei liegt auf meiner Festplatte und sie so aus.
Delphi-Quellcode:
unit System.ByteStrings;
interface
{$IFDEF NEXTGEN}
type
ShortString = _ShortString;
AnsiString = _AnsiString;
AnsiChar = _AnsiChar;
PAnsiChar = _PAnsiChar;
PPAnsiChar = _PPAnsiChar;
UTF8String = _UTF8String;
PUTF8String = _PUTF8String;
RawByteString = _RawByteString;
PRawByteString = _PRawByteString;
{$ENDIF NEXTGEN}
implementation
end.
Diese lässt sich aber so nicht kompilieren, da die Symbole in der System.dcu nicht mit Unterstrich anfangen, sondern mit "@" (der Compiler ändert alle führenden Unterstriche in System.pas zu "@" ab). Der Patch besteht nun darin, die System.dcu Datei etwas zu recht zu biegen, System.ByteStrings zu kompilieren und danach die System.ByteStrings
Unit auf "@" zu patchen.
Es ginge natürlich auch noch einfacher, in dem man die System.pas ändert und neu kompiliert. Aber dann hat man mit Packages und
Unit-Abhängigkeiten so seine Probleme.
Zitat:
Wie kommt man auf solche Sachen?
Durch so falsche Aussagen, wie "der Nextgen-Compiler kann nur UnicodeStrings, die anderen Stringtypen werden nicht auf ARM Prozessoren unterstützt". Ein Stringtyp hat mal überhaupt nichts mit dem Prozessor zu tun. Zudem wurden die anderen Stringtypen nur versteckt, ihre Funktionalität ist aber voll gewährleistet (alle Compiler-Magic Funktionen sind vorhanden) und wurde weder von XE3, XE4, XE5, XE6 noch XE7 entfernt.