AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Probleme mit RtlRunEncodeUnicodeString

Ein Thema von slemke76 · begonnen am 22. Sep 2015 · letzter Beitrag vom 27. Sep 2015
Antwort Antwort
Seite 2 von 2     12
Benutzerbild von uligerhardt
uligerhardt

Registriert seit: 19. Aug 2004
Ort: Hof/Saale
1.704 Beiträge
 
Delphi 2007 Professional
 
#11

AW: Probleme mit RtlRunEncodeUnicodeString

  Alt 24. Sep 2015, 09:39
Auch gehen würde folgendes (normale Stringkonstanten landen nicht in der read-only Section bzw. werden bei Zuweisung vermutlich umkopiert):
Delphi-Quellcode:
var
  Source: WideString;
  UnicodeString: UNICODE_STRING;
  Hash: UCHAR;
begin
  Source := 'TestString'#0;
  RtlInitUnicodeString(@UnicodeString, @Source[1]);
  Hash := 0;
  RtlRunEncodeUnicodeString(@Hash, @UnicodeString);
Dann aber nicht vergessen vorher per Hand eine #0 an den Source String anzuhängen.
Die #0 fügt Delphi (AFAIK ) schon automatisch an verwaltete Strings an. Und statt @Source[1] lieber den passenden Cast nehmen:
Delphi-Quellcode:
var
  Source: WideString;
  UnicodeString: UNICODE_STRING;
  Hash: UCHAR;
begin
  Source := 'TestString';
  RtlInitUnicodeString(@UnicodeString, PWideChar(Source));
  Hash := 0;
  RtlRunEncodeUnicodeString(@Hash, @UnicodeString);
  RtlRunDecodeUniCodeString(Hash, @UnicodeString);
end.
Uli Gerhardt
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#12

AW: Probleme mit RtlRunEncodeUnicodeString

  Alt 24. Sep 2015, 16:16
Die #0 fügt Delphi (AFAIK ) schon automatisch an verwaltete Strings an.
Wäre mir neu Würde ich mich, selbst wenn es so ist, aber auf keinen Fall drauf verlassen. "Normale" Strings sind in Delphi nicht nullterminiert, sondern enthalten ein vorangestelltes Längenbyte. Unter dem Gesichtspunkt ist für den Delphi Compiler ja keine Notwendigkeit gegeben noch irgendwelche Nullen hinzuzufügen.

Edit:
Zumindest bei neueren Delphi Versionen stehen auf den ersten Blick tatsächlich zwei Nullbytes hinter dem String.

Und statt @Source[1] lieber den passenden Cast nehmen
Macht keinen Unterschied:
Code:
Unit1.pas.63: RtlInitUnicodeString(@UnicodeString, @Source[1]);
005C7383 8B45F8           mov eax,[ebp-$08]
005C7386 E8252DE4FF      call @WStrToPWChar
005C738B 50               push eax
005C738C 8D45F0           lea eax,[ebp-$10]
005C738F 50               push eax
005C7390 E8B7FFFFFF      call RtlInitUnicodeString
Unit1.pas.64: RtlInitUnicodeString(@UnicodeString, PWideChar(Source));
005C7395 8B45F8           mov eax,[ebp-$08]
005C7398 E8132DE4FF      call @WStrToPWChar
005C739D 50               push eax
005C739E 8D45F0           lea eax,[ebp-$10]
005C73A1 50               push eax
005C73A2 E8A5FFFFFF      call RtlInitUnicodeString
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)

Geändert von Zacherl (24. Sep 2015 um 16:37 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von uligerhardt
uligerhardt

Registriert seit: 19. Aug 2004
Ort: Hof/Saale
1.704 Beiträge
 
Delphi 2007 Professional
 
#13

AW: Probleme mit RtlRunEncodeUnicodeString

  Alt 24. Sep 2015, 16:29
Die #0 fügt Delphi (AFAIK ) schon automatisch an verwaltete Strings an.
Wäre mir neu Würde ich mich, selbst wenn es so ist, aber auf keinen Fall drauf verlassen. "Normale" Strings sind in Delphi nicht nullterminiert, sondern enthalten ein vorangestelltes Längenbyte. Unter dem Gesichtspunkt ist für den Delphi Compiler ja keine Notwendigkeit gegeben noch irgendwelche Nullen hinzuzufügen.
Aus reiner Delphi-Sicht nicht. Aber eben genau, um einfache Interaktion mit der API zu ermöglichen, wird m.W. die Null drangehängt. Das müsste dokumentiertes Verhalten sein. Ich bin aber zu faul, das jetzt rauszusuchen.

Und statt @Source[1] lieber den passenden Cast nehmen
Macht keinen Unterschied:
Code:
Unit1.pas.63: RtlInitUnicodeString(@UnicodeString, @Source[1]);
005C7383 8B45F8           mov eax,[ebp-$08]
005C7386 E8252DE4FF      call @WStrToPWChar
005C738B 50               push eax
005C738C 8D45F0           lea eax,[ebp-$10]
005C738F 50               push eax
005C7390 E8B7FFFFFF      call RtlInitUnicodeString
Unit1.pas.64: RtlInitUnicodeString(@UnicodeString, PWideChar(Source));
005C7395 8B45F8           mov eax,[ebp-$08]
005C7398 E8132DE4FF      call @WStrToPWChar
005C739D 50               push eax
005C739E 8D45F0           lea eax,[ebp-$10]
005C73A1 50               push eax
005C73A2 E8A5FFFFFF      call RtlInitUnicodeString
WIMRE macht es einen Unterschied, wenn Source = '' ist. Vielleicht erkennt der Compiler, dass das in dem Beispiel nicht der Fall ist und lässt deshalb die Prüfung weg. Vermutlich taucht ein Unterschied auf, wenn man das ganze z.B. in eine Prozedur mit Source als Argument steckt.
Uli Gerhardt
  Mit Zitat antworten Zitat
SMO

Registriert seit: 20. Jul 2005
178 Beiträge
 
Delphi XE6 Professional
 
#14

AW: Probleme mit RtlRunEncodeUnicodeString

  Alt 24. Sep 2015, 16:30
Wäre mir neu Würde ich mich, selbst wenn es so ist, aber auf keinen Fall drauf verlassen. "Normale" Strings sind in Delphi nicht nullterminiert, sondern enthalten ein vorangestelltes Längenbyte. Unter dem Gesichtspunkt ist für den Delphi Compiler ja keine Notwendigkeit gegeben noch irgendwelche Nullen hinzuzufügen.
Doch, das macht Delphi schon immer (?) so, wie uligerhardt sagte. Nur auf diese Weise können Delphi-Strings, egal ob Ansi oder Unicode, schnell und einfach für die Verwendung mit der Windows-API auf PChar gecastet werden.
Delphi-Strings haben auch schon seit Delphi 2 kein vorangestelltes Längenbyte mehr, sondern einen 32 Bit Integer. Der String mit Längenbyte ist der alte ShortString.
Aktuell steht vor Ansi/UnicodeStrings eine ganze Menge mehr, insgesamt 12 Bytes.
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#15

AW: Probleme mit RtlRunEncodeUnicodeString

  Alt 24. Sep 2015, 16:36
Doch, das macht Delphi schon immer (?) so, wie uligerhardt sagte. Nur auf diese Weise können Delphi-Strings, egal ob Ansi oder Unicode, schnell und einfach für die Verwendung mit der Windows-API auf PChar gecastet werden.
Ja, konnte das grade bei mir auch beobachten. Da wurde wohl tatsächlich einmal mitgedacht.

Delphi-Strings haben auch schon seit Delphi 2 kein vorangestelltes Längenbyte mehr, sondern einen 32 Bit Integer. Der String mit Längenbyte ist der alte ShortString.
Aktuell steht vor Ansi/UnicodeStrings eine ganze Menge mehr, insgesamt 12 Bytes.
Ich weiß ich weiß Ist hier nur nicht wirklich von Relevanz. Ging mir eher um die zwei verschiedenen Techniken Längenprefix vs. Nullterminierung.

WIMRE macht es einen Unterschied, wenn Source = '' ist. Vielleicht erkennt der Compiler, dass das in dem Beispiel nicht der Fall ist und lässt deshalb die Prüfung weg. Vermutlich taucht ein Unterschied auf, wenn man das ganze z.B. in eine Prozedur mit Source als Argument steckt.
Konnte auch mit leerem Source und Source als Funktionsargument keinen Unterschied im Assembly ausmachen, aber kann natürlich sein, dass es irgendwelche Edge-cases gibt.

Glaube aber wir bewegen uns grade etwas vom Thema weg.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)

Geändert von Zacherl (24. Sep 2015 um 16:41 Uhr)
  Mit Zitat antworten Zitat
mkinzler
(Moderator)

Registriert seit: 9. Dez 2005
Ort: Heilbronn
39.804 Beiträge
 
Delphi 10.4 Sydney
 
#16

AW: Probleme mit RtlRunEncodeUnicodeString

  Alt 24. Sep 2015, 16:42
Zitat:
Ich weiß ich weiß Ist hier nur nicht wirklich von Relevanz. Ging mir eher um die zwei verschiedenen Techniken Längenprefix vs. Nullterminierung.
Und wäre Delphi 1 noch die aktuelle Version hättest Du auch Recht.
Markus Kinzler
  Mit Zitat antworten Zitat
slemke76

Registriert seit: 29. Mär 2005
Ort: Quakenbrück
136 Beiträge
 
#17

AW: Probleme mit RtlRunEncodeUnicodeString

  Alt 27. Sep 2015, 12:41
Hallo zusammen,

da habe ich ja was los getreten

*** Vielen Dank an alle, die geholfen haben ..! ***

Inzwischen habe ich das ganze integriert und es funktioniert alles wie es soll. Auch über Pointer, CopyMemory, etc. habe ich einiges gelernt - ich hoffe, ich vergesse es nicht wieder so schnell

Grüße & schönen Sonntag,
Sebastian
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 00:32 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf