ULONG Typ in Delphi als Cardinal definiert!?

[richard_boderich]

Moin,

Ich habe Probleme beim Auswerten einer Record Strucktur, die ich von einer WinAPI erhalte, welche mir einen Pointer darauf liefert. Diese sieht folgendermaßen aus.

Delphi-Quellcode:

  TMyInformation = packed record
    zeitwert: Int64;
    zähler: ULONG;
    Länge: ULONG;
    Name: WChar;
  end;

In Delphi ist der ULONG Typ als Cardinal definiert!?

Delphi-Quellcode:

Cardinal   0..4294967295            32 Bit, ohne Vorzeichen

Die MSDN sagt zum ULONG Typ

Delphi-Quellcode:

ulong 0 to 18,446,744,073,709,551,615 Unsigned 64-bit integer

Ich vermute, das Problem was ich habe ist, das Aufgrund der unterschiedlichen Typen Cardinal und ULONG und ihrer Bytelängen
die Recordabfrage mit den Feldern nicht mehr richtig funktioniert. z.B wenn name=foobar und Länge=10, dann sowas raus

Delphi-Quellcode:

@myinformation.name -> "bar"
@myinformation.Länge -> "foobar??" !!!!

Problem:
1. Wenn ich nach dem Namen frage bekomme ich nur einen Teilstring.
2. Wenn ich nach der Länge frage bekomme ich den ganzen String + paar Byte dazu, dabei sollte Länge ein Cardinal mit der Länge von Name sein.

Vielleicht kann mir jemand sagen, ob meine Vermutung zutrifft und es wirklich an den Typen liegt, oder was ich da sonst falsch mache. *seufz*

mfG Richard

[mkinzler]

Ich würde eher int64 nehmen

[Der_Unwissende]

Hi,
wie genau gibst Du denn die Länge aus, wenn da ein String rauskommt?

Gruß Der Unwissende

[Bernhard Geyer]

Zitat:

Zitat von richard_boderich

Die MSDN sagt zum ULONG Typ

Delphi-Quellcode:

ulong 0 to 18,446,744,073,709,551,615 Unsigned 64-bit integer

Wirklich oder doch nur wenn als Zielplattform Win64 genommen wird?
Ok, unter .NET ist ULONG immer 64-Bit.

[richard_boderich]

@ Der Unwissende

Die Strucktur wird von der Api Funktion ausgefüllt. Ich will nur auslesen.
Werde es erstmal mit Int64 probieren, obwohl das ja "signed" ist.

mfg Richard

[Der_Unwissende]

Zitat:

Zitat von richard_boderich

@ Der Unwissende

Die Strucktur wird von der Api Funktion ausgefüllt. Ich will nur auslesen.

Das ist klar, aber Du sagst ja die Belegung der Längeninformation ist ein String, der z.B. Foobar enthält. Wie also ermittelst Du die Belegung? Und was bekommst Du, wenn Du das Feld per IntToStr ausgibst?

Zitat:

Zitat von richard_boderich

Werde es erstmal mit Int64 probieren, obwohl das ja "signed" ist.

Gut, wenn ein String mehr als 4,2 Mrd. Zeichen enthält ist ohnehin schlecht...

[richard_boderich]

Also das funktioniert erstmal teilweise

TMyInformation = packed record
zeitwert: Int64;
zähler: word; < statt ulong
Länge: word; < stat ulong
Name: WChar;
end;

wenn ich es so mach, dann bekomme ich wenn ich .name abfrage den vollen string. leider gibt er mir dan als länge 0 aus.
versteh ich einfach nicht. Die APi funktioniert doch. Fehlerstatus ist ok und Resultlength ist 30.
Also wird doch was zurueckgegeben. Der Name stimmt doch auch.

@ Unwissender Namelängth = 0 , das heisst die Strucktur kann noch nicht stimmen. Habe ich per Breakpoint ermittelt

Gruß Richard

[Der_Unwissende]

Ok, dann noch anders, kannst Du vielleicht kurz die Struktur verlinken, die Du hier in Delphi abbilden möchtest? Vielleicht kann man dann leichter den potentiellen Fehler ermitteln.

[mkinzler]

Das Feld muss auch 64Bit breit sein, also int64

[himitsu]

eigentlich ist doch ulong ein LongWord :gruebel:

LONG ist jedenfalls LongInt
also sollte ULONG doch LongWord sein?

demnach ULONGLONG = UInt64? :gruebel:




Nja wie dem auch sei

unsigned 64 bit integer = UInt64 (gibt's erst seit D6 und vorher muß man Int64 mißbrauchen)


[add]
PS: in Windows.pas steht übrigens auch LONGLONG = Int64; und das hat sich doch Borland aus den Windows-PSDK-Headern übersetzt :angel2:

[Der_Unwissende]

Zitat:

Zitat von himitsu

eigentlich ist doch ulong ein LongWord :gruebel:
LONG ist jedenfalls LongInt

Ich glaube ganz so stimmt das nicht. In C sind die Datentypen (afaik) generisch, so wie Integer und Cardinal es unter Delphi sind. Die tatsächliche Größe hängt somit von der Plattform ab, unter der das ganze laufen soll. Ein LongWord hingegen ist immer fest in seiner Größe (eben anders als Cardinal oder Integer). Es gibt auf jeden Fall keine garantien dafür, dass ein long int genau 16, 32 oder x bit groß ist unter C. Ich denke darauf zielte auch die Frage von Richard Boderich ab.

[edit]
Sorry, muss mich kurz korrigieren, meinte eigentlich eher die Frage bzw. Antwort von Bernhard Geyer :oops:
[/edit]

[richard_boderich]

ja stimmt

Ich habe festgestellt, das wenn ich für den Parameter Time von TKBasicInformation einen Int64 nehm füllt windows anscheinend sie Struktur nicht mehr richtig. Tlasttimewrite sollte eigentlich auch 2 Dword beinhalten statt 2 word. jedoch kracht es dann wieder.
Entweder ich lese die Struktur falsch aus, oder es liegt am Typ des Feldes Time? Die Länge und der String werden ja richtig ausgelesen , das habe ich überprüft.

Richard

[Olli]

Zitat:

Zitat von Der_Unwissende

Ich glaube ganz so stimmt das nicht. In C sind die Datentypen (afaik) generisch, so wie Integer und Cardinal es unter Delphi sind. Die tatsächliche Größe hängt somit von der Plattform ab, unter der das ganze laufen soll. Ein LongWord hingegen ist immer fest in seiner Größe (eben anders als Cardinal oder Integer). Es gibt auf jeden Fall keine garantien dafür, dass ein long int genau 16, 32 oder x bit groß ist unter C. Ich denke darauf zielte auch die Frage von Richard Boderich ab.

Das stimmt so leider nicht. Bsp. ULONG. Im Kernelmode ist ULONG die Bezeichnung, welche statt DWORD (im UM) benutzt wird. ULONG ist auch bei einer 64bit-Zielplattform ala x64 noch 32bit breit. Hingegen ULONG_PTR, hat die Breite eines Pointers, unterscheidet sich also je nach Zielplattform. Ich kann mir eigentlich nicht vorstellen, daß es für ULONG im UM anders ist.

Abgesehen davon, sind das ohnehin nur Vereinbarungen in den Headern, die man eben benutzen kann oder nicht. Wenn man es nicht mag, nimmt man die Grundtypen der Sprache, welche man benutzt.

Bsp C++:

unsigned long int
long int

@richard: Das Feld für den Namen sieht eigenartig aus. Sicher, daß es nicht etwas ala "array[0..1] of WCHAR" ist?

[richard_boderich]

@Olli

mit dem WChar hast du natuerlich recht. Es ist eine array of wchar. Hatte es nur abgetippt, da ich meine Zwischenablage nicht nutzten konnte.

mfG Richard