Bei mir kam die Tage eine Anfrage rein, ob man meine Library für Audio-Metadaten auch für 64Bit nutzen kann (keine DLL, einfach nur Code, der mit eincompiliert wird). Daher muss ich mich jetzt ein wenig damit beschäftigen. Google liefert da zuerst diesen Artikel (zum Umstieg), oder auch diesen (Integer-Typen).

Da Integer, Cardinal, Word, DWord, LongInt, SmallInt, Byte etc. alle gleich groß geblieben sind, dürften binäre Schreib- und Leseoperationen beim Parsen/Erstellen der Dateien kein Problem sein. Windows-Messages verschicke ich da auch nicht selbst, so dass Konflikte bzgl. Integer/WPARAM/LPARAM auch nicht zu erwarten sind.

Bleiben die Zeiger. Im deutschen Artikel ist das widersprüchlich, aber der englische Artikel erklärt das richtig mit "You cannot assume that:" (hoffe ich zumindest, kann man den Fehler eigentlich irgendwo melden?)

Zitat:

Sie sollten Zeigeroperationen in Ihrer Codebasis überprüfen.
Die Größer aller Zeiger wurde folgendermaßen geändert:

• Auf einer 32-Bit-Windows-Plattform ist ein Zeiger 4 Byte groß.
• Auf einer 64-Bit-Windows-Plattform ist ein Zeiger 8 Byte groß.

Sie können von Folgendem ausgehen: ... ähm... nein???

• SizeOf(Pointer)=SizeOf(Integer/Cardinal/Longint)

Aber generell kann man Pointer ohne Änderungen weiter verwenden, oder? Ich habe z.B. so was im Code, wo ich ein wenig mit Records trickse, um Daten nicht mehrfach aus einer Datei lesen zu müssen. Sowas ist unabhängig von der Bittigkeit der Anwendung, oder?

zusammenfalten · markieren

Delphi-Quellcode:

const
  APE_PREAMBLE = 'APETAGEX';
  ID3V1_PREAMBLE = 'TAG';

type

TID3v1Structure = record
  ID: Array[1..3] of AnsiChar; // 3
  Title: Array [1..30] of AnsiChar; // 30
  Artist: Array [1..30] of AnsiChar; // 30
  Album: Array [1..30] of AnsiChar; // 30
  Year: Array [1..4] of AnsiChar; // 4
  Comment: Array [1..30] of AnsiChar; // 30
  Genre: Byte; // 1 = 128 Bytes total
end;

TApeHeader = record
  Preamble: Array[1..8] of AnsiChar; // 8
  Version: DWord; // 4
  Size: DWord; // 4
  ItemCount: DWord; // 4
  Flags: DWord; // 4
  Reserved: Array[1..8] of Byte; // 8 = 32 Bytes total
end;

PApeHeader = ^TApeHeader;

// aID3v1tag wird aus den letzten 128 Byte einer Datei gelesen
function IsValidID3Tag(aID3v1tag: TID3v1Structure): Boolean;
var
  p: Pointer;
  hiddenApeFooter: TApeHeader;
begin
  p := @aID3v1Tag.Year[4];
  hiddenApeFooter := PApeHeader(p)^ ;
  // Valid wenn:
  // - Die letzten 128 Byte starten mit "TAG",
  // - aber die letzten 32 starten NICHT mit "APETAGEX"
  result := (aID3v1Tag.ID = ID3V1_PREAMBLE)
        and (hiddenApeFooter.Preamble <> APE_PREAMBLE);
end;

Gibt es sonst noch wichtige Punkte, die man beim Umstieg auf 64Bit beachten muss, die in dem Artikel nicht erwähnt sind?

Denn sonst scheint es mit der Library keine Probleme unter 64Bit zu geben. Es compiliert, und bei ein paar Tests sind keine Dateien kaputt gegangen.

Solange du Pointer nur auf Pointertypen castest, kann da auch nix passieren. Probleme kann es nur geben, wenn man z.B. Pointer in Integertypen gepresst hat.

Hallo Gausi,

ich benutze schon mehrere Jahre deine Mp3FileUtils 6.0a für 32bit und auch 64bit, bisher hatte keine Probleme.
Geändert wurde vom Mir nichts.

gruß Reinhold

Zitat von jaenicke:

Solange du Pointer nur auf Pointertypen castest, kann da auch nix passieren. Probleme kann es nur geben, wenn man z.B. Pointer in Integertypen gepresst hat.

Kann sein, dass ich das an ein oder zwei Stellen umgekehrt mache, also einen Integer- oder Aufzählungstypen auf Pointer caste, um damit eine TList zu füllen. Aber die Richtung sollte ja passen - ein 32Bit Integer passt ja in einen 64Bit Pointer.

Zitat von Stolle58:

ich benutze schon mehrere Jahre deine Mp3FileUtils 6.0a für 32bit und auch 64bit, bisher hatte keine Probleme.

Danke für die Rückmeldung. Aktuell geht es zwar um die Fortentwicklung, die auch andere Audio- und Tagformate unterstützt, aber wenn der alte Code funktioniert, finde ich das für den neueren sehr beruhigend.

Mal so am Rande bemerkt: Es gibt IntPtr, einen Integer-Datentyp, der immer der Größe eines Pointers entspricht, unabhängig davon, ob 32 oder 64 Bit und vor allem unabhängig von der Plattform. Denn die Integer-Größen sind auch noch Plattform-abhängig und - die älteren mögen sich erinnern - Delphi 7 bis 2007 hatten ein 64-bit NativeInt, obwohl die Compiler nur 32 bit Code erzeugten.
(Allerdings hatten die auch noch kein IntPtr).

Jupp, es gibt Typen, die sind direkt für Pointer-Casts gedacht.

Stellt euch mal vor, dass früher der Integer ein dynamischer Typ war, der mitwachsen sollte.
Bei 16 zu 32 Bit machte er es noch, aber für 64 dachten sich welche, es wäre geil den Typen einzufrieren und 'nen neuen Typen zu erfinden (NativeInt im Delphi genannt), aber mal sehn, ob er das bei 128 und 256 Bit auch noch machen wird, in den nächsten Jahrtausenden.