Gesichtspunkte für geräteübergreifende Delphi-Anwendungen

Nach oben zu Gesichtspunkte für geräteübergreifende Anwendungen

Der Datentyp Extended ist auf verschiedenen Plattformen unterschiedlich

Die Größe des Datentyps Extended ist auf jeder Plattform unterschiedlich. Der Extended-Typ ist der Gleitkommatyp mit der größten Genauigkeit und abhängig von der Hardware zur Laufzeit.

• Auf Intel Windows 32 Bit ist der Typ Extended (weiterhin) 10 Byte groß.
• Auf Intel Windows 64 Bit ist der Typ Extended ein Alias für ein Double oder 8 Byte.
• Auf Intel Linux 64 Bit und Intel macOS 64 Bit ist der Typ Extended 16 Byte groß.
• Auf ARM-Plattformen, wie iOS 64 Bit, ARM macOS 64 Bit, ARM iOS-Simulator 64 Bit und Android (32 Bit und 64 Bit) ist der Typ Extended ein Alias für ein Double oder 8 Byte.

Auf Win64- oder ARM-Plattformen bietet der Datentyp Extended daher eine geringere Genauigkeit als unter Win32. Wenn Sie in Ihren Anwendungen den Datentyp Extended verwenden und Genauigkeit, z. B. für Gleitkommaberechnungen, wichtig ist, könnte sich dieser Größenunterschied auf Ihre Daten auswirken.

Hauptsächlich betroffen sind sehr kleine oder sehr große Werte. Die beiden Datentypen haben die folgende Genauigkeit:

• 1x10³⁰⁸ IEEE Double, vom 8-Byte-Typ Extended unterstützt, umfasst Intel Windows 64 Bit und alle ARM-Plattformen
• 1x10⁴⁹³² IEEE Extended, unterstützt vom 10- oder 16-Byte-Typ Extended umfasst Intel POSIX-Plattformen

Wenn die Codebasis den Datentyp Extended enthält, wird die folgende Hinweismeldung angezeigt: W1066 Erweiterte Genauigkeit für Gleitkommawert verloren gegangen. Verkürzt auf Double (Delphi). Gleitkommaoperationen mit einer 10-Byte-Extended-Genauigkeit werden in Intel Windows-32-Bit-Anwendungen, aber nicht in Intel Windows-64-Bit-Anwendungen unterstützt. Auf Intel Windows 64 Bit ist die Genauigkeit von Gleitkommaoperationen mit Extended-Variablen auf eine doppelte Genauigkeit reduziert.

Mit dem Record TExtended80Rec können Sie mit Gleitkommavariablen mit Extended-Genauigkeit auf allen Plattformen arbeiten, aber nur zum Lesen aus und Schreiben in den Arbeitsspeicher und zum Durchführen von Low-Level-Änderungen (Ändern der Mantisse, des Exponenten oder des Vorzeichens).

Weitere Informationen zu 64-Bit-Datentypen finden Sie unter 64-Bit-Windows-Datentypen im Vergleich zu 32-Bit-Windows-Datentypen.

Die Datentypen LongInt und LongWord sind auf 64-Bit-POSIX-Plattformen unterschiedlich

Um die Interoperabilität zwischen Delphi und der POSIX-API aufrechtzuerhalten, wurde für 64-Bit-POSIX-Plattformen die Größe der LongInt- und LongWord-Typen in 64 Bit geändert. Alle 32-Bit-Plattformen und 64-Bit-Windows-Plattformen behalten 32 Bit für die LongInt- und LongWord-Typen.

Unterstützung der Zielplattform macOS 64 Bit (ARM)

macOS 64 Bit (ARM) ist nativ für die M1 Apple Silicon-CPUs mit macOS 11 ausgerichtet. Verwenden Sie diese Plattform, um native M1-Anwendungen zu erstellen (M1-Hardware ist für die Ausführung erforderlich).

Hinweis: RAD Studio unterstützt die Zielplattform macOS 64 Bit (Intel) weiterhin und ermöglicht die Erstellung von universellen Binäranwendungen, die sowohl ARM- als auch Intel-Binärdateien in einem einzigen Package enthalten.

Erstellen Sie alle Arten von unterstützten Anwendungen wie Konsolenanwendungen, einfache FireMonkey-Anwendungen, FMX-Anwendungen mit Datenbankfunktionen und nutzen Sie die universelle Version des eingebetteten InterBase, IBLite.

Universelle Binärdateien

Erstellen Sie eine universelle Binärdatei, die sowohl Intel- als auch ARM-Code enthält. Legen Sie als Zielplattform macOS 64 Bit (ARM) fest. Navigieren Sie in den Projektoptionen zu Erzeugen > Delphi-Compiler > Compilieren > Weitere und aktivieren Sie "Universelle macOS-Binärdatei generieren (x86_64 + arm64)". Stellen Sie die Anwendung bereit. Der Bereitstellungs-Manager verbindet zwei Binärdateien in eine einzelne "universelle" Binärdatei, bevor die Anwendung an das Ziel-macOS übertragen wird. Die universelle Binärdatei befindet sich im Ordner OSXARM64\Debug.

Stack-Ausrichtungsproblem auf macOS

Ein zentrales Problem bei macOS-Anwendungen stellt die Anforderung dar, dass die gesamten Speicherdaten auf dem Stack an 16-Byte-Grenzen ausgerichtet sein müssen:

• Einzelheiten dazu finden Sie im Blog von Eli Boling
• Bei Delphi-Anwendungen können Sie mit der Direktive Code ausrichten (Delphi) 16-Byte-Grenzen festlegen.
• Siehe auch die ALIGN_STACK-Definition in Bedingte Compilierung (Delphi).

Migrieren von Delphi-Anwendungen von Win32 zu macOS

Die folgende Tabelle gibt einen Überblick über die Plattformunterstützung durch die verschiedenen Bibliotheken in RAD Studio:

Bibliothek/Plattform	Win32	Win64	macOS 64 Bit
FMX
RTL
VCL			Nicht unterstützt

Hinweis: Die obige Tabelle enthält nur einen groben Überblick über die Bibliotheksunterstützung für Plattformen.

Auf bestimmten Plattformen gelten für die Unterstützung der RTL und der VCL Ausnahmen. </blockquote>

Die VCL ist nur unter Windows verfügbar und unterstützt macOS nicht. Anwendungen für macOS sollten mit FireMonkey (FMX) erzeugt werden.

Ein Großteil der Delphi-Laufzeitbibliothek (RTL) unterstützt aber alle unterstützten Zielplattformen. Die RTL beinhaltet die Units System, SysUtils und IOUtils und andere, die plattformunabhängige Elemente enthalten.

• Delphi-Anwendungen, die nur die RTL (nicht die VCL) verwenden, arbeiten unter Win64 mit geringfügigen Änderungen.
• Delphi-Anwendungen, die die VCL und/oder die RTL verwenden, unterstützen Win32 und Win64.

Weitere Informationen über die RTL finden Sie unter Verwenden der RTL (Laufzeitbibliothek).

Weitere Informationen zu FireMonkey finden Sie unter FireMonkey.

Weitere Informationen über die VCL finden Sie unter Einführung in die VCL (Visual Component Library).

Migrieren von Delphi-Anwendungen von Win32 zu Win64

Die VCL, FMX und die RTL werden unter Win32 und Win64 unterstützt.

Weitere Informationen zur Delphi-Anwendungsentwicklung für Win64 finden Sie unter 64-Bit-Windows-Anwendungsentwicklung.

Migrieren von Delphi-Anwendungen von Win32 zu Linux64

Die VCL und FMX werden auf Linux-Plattformen nicht unterstützt. Gegenwärtig unterstützt Linux nur Konsolenanwendungen. Mit dem FmxLinux-Produkt, erhältlich über den GetIt-Package-Manager, kann Linux jedoch als Ziel für FMX-Anwendungen verwendet werden. Weitere Informationen finden Sie auf der Seite FireMonkey for Linux.

Für die Anwendungsentwicklung für Delphi-Linux siehe Anwendungsentwicklung für Linux.

Migrieren von Delphi-Anwendungen von Desktop- zu mobilen Anwendungen

• Migrieren von Delphi-Code zu mobilen Anwendungen vom Desktop aus

In den Clang-basierten C++-Compilern wird das Schlüsselwort "absolute" bei der Interoperabilität zwischen Delphi und C++Builder nicht unterstützt

Wenn Sie Delphi-Code schreiben möchten, der in Interoperabilität mit den C++-Compilern, die durch Clang erweitert wurden, ausgeführt wird, dürfen Sie die Delphi-Direktive/das Delphi-Schlüsselwort "absolute" im interface-Abschnitt einer Delphi-App nicht verwenden. Sie können das Schlüsselwort "absolute" jedoch im implementation-Abschnitt verwenden.

LLVM bietet keinen Mechanismus, anhand dessen eine Variable eine andere überlagern kann, daher geht C++Builder von einem eindeutigen Symbol für jede Variable aus.

Beschränkungen der Inline-Assembly

Wenn Ihre Codebasis Inline-Assembly-Code enthält, müssen Sie möglicherweise Codeänderungen vornehmen, um auf neue Plattformen umzusteigen. Weitere Informationen finden Sie in den folgenden Themen:

Für Intel Windows-64-Bit-Plattformen

• 64-Bit-Inline-Assembler von Delphi
  • Verwendung des integrierten Assemblers
  • Assembler-Prozeduren und -Funktionen
• Konvertieren von 32-Bit-Delphi-Anwendungen in 64-Bit-Windows

Für ARM-Plattformen und Intel POSIX-Plattformen

Diese Plattformen unterstützen den Inline-Assembler nicht.

Siehe auch

• 64-Bit-Windows-Anwendungsentwicklung
• Gesichtspunkte für geräteübergreifende C++-Anwendungen
• Unterschiede zwischen Windows und macOS
• 64-Bit-Windows-Datentypen im Vergleich zu 32-Bit-Windows-Datentypen