Probleme mit TStrings.IndexOfName unter Vista

[Bernhard Geyer]

Zitat von marabu:

Hallo,

den eigentlichen "Fehler" haben leider die VCL-Macher verbrochen. Sie hätten, auch nach dem seinerzeit aktuellen PSDK, einen eigenen Aufruf von CompareString() mit LOCALE_INVARIANT verwenden müssen, anstatt auf ihre lokalisierte Funktion AnsiSameText() zurückzugreifen. Das Thema gehört jetzt wohl nach Delphi-Bugs ...

Hast du ein damalig aktuelles SDK wohl zur Hand? Gab es damals LOCALE_INVARIANT überhaupt?
Würde sonst wohl in der aktuellen Beschreibung 2 unterschiedliche Versionen aufgeführt. Für XP und neuer mit LOCALE_INVARIANT und für ältere Betriebssysteme mit MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT);
MS hat ja schon öfters mal API-Funktionalität umdefiniert.

[sh17]

Der Wert LOCALE_INVARIANT wird im aktuellen SDK vom Februar in der WinNT.h mittels (MAKELCID(MAKELANGID(LANG_INVARIANT, SUBLANG_NEUTRAL), SORT_DEFAULT)) erzeugt. Also keine Konstante.

[Bernhard Geyer]

Zitat von sh17:

Der Wert LOCALE_INVARIANT wird im aktuellen SDK vom Februar in der WinNT.h mittels (MAKELCID(MAKELANGID(LANG_INVARIANT, SUBLANG_NEUTRAL), SORT_DEFAULT)) erzeugt. Also keine Konstante.

Dann verschiebt sich das Problem nur. Gab es LANG_INVARIANT schon zu Win95-Zeiten?

[sh17]

Tss, klappt sogar unter .NET

Delphi-Quellcode:

if (String.Compare("HÜBNER", "HUEBNER") == 0)
            {
                MessageBox.Show("Gleich");
            }

Das muss ich anders lösen.

[marabu]

Hallo Bernhard,

Zitat von Bernhard Geyer:

Hast du ein damalig aktuelles SDK wohl zur Hand? ...

leider nein, aber der mit Delphi ausgelieferte Win32 SDK sagt eigentlich schon genug:

Win32 SDK : Topic CompareString : Section Remarks

Notice that if the return value is 2, the two strings are "equal" in the collation sense, though not necessarily identical.

Ich denke der für TStrings verantwortliche Entwickler ist einfach ein Opfer seiner Code-Reuse-Praxis geworden.

Zitat von Bernhard Geyer:

Gab es damals LOCALE_INVARIANT überhaupt?

Sicher nicht, aber ein von Lokalisierungseffekten freies Eregbnis würde ich bei Verwendung von LCID(0) erwarten, d.h. LANG_NEUTRAL, SUBLANG_NEUTRAL, SORT_DEFAULT.

Für den Fall, dass es sich dabei um einen special value handeln sollte: Ich habe das jetzt nicht ausprobiert.

Freundliche Grüße

[Nuclear-Ping]

[Offtopic]
Hey ein Radebeuler. Ist ja gleich um die Ecke. *wink* aus Dresden.
[/Offtopic]

[netspy]

Zitat von sh17:

Zitat von sh17:

Vielleicht langt es ja schon, wie bei TNTs InstallTntSystemUpdates die Delphi-Functionen zu patchen.

Hab es getestet, geht super.

Kannst du mir sagen, was du da genau gemacht hast, damit es geht? Ich hab genau das gleich Problem und dreh mich wegen Vista total im Kreis. CompareStringW scheint die angegebene Locale total zu ignorieren und bringt komplett andere Ergebnisse als unter =<XP. Hier mal dein Beispiel mit einer englischen Locale:

Delphi-Quellcode:

if (CompareStringW(MAKELCID(2057, 0), NORM_IGNORECASE, 'HÜBNER', Length('HÜBNER'), 'HUEBNER', Length('HUEBNER')) - 2) = 0 then
begin
  ShowMessage('Fehler');
end;

Selbst wenn Vista unter einer deutschen Locale Umlaute erkennen kann, sollte das mit englischen Spracheinstellungen mit Sicherheit nicht so sein.

Die Unterschiede zwischen Vista und XP sind übrigens nicht auf deutsche Umlaute beschränkt. Bspw. wird chinesischer Text bei gleichen Einstellungen und gleicher Locale komplett anders sortiert.

[sh17]

Hallo NetSpy.

Also einen API-Hook für CompareStringW habe ich nicht geschrieben, sondern nur eine Überladung von Delphi-Funktionen. D.h. genauer nutze ich sie jetzt aber nicht, da mir beides wegen der unbekannten Nebenwirkungen zu unsicher ist. Einige unserer Komponenten sind nicht im Quelltext verfügbar. Und was weiss ich, was da passiert.

Wir haben jetzt alle betreffenden Funktionen (z.B. TStringList.IndexOf) noch mal gekapselt. Die Sortierung haben wir sowieso schon immer selbst gemacht.

Hier aber trotzdem das Beispiel zum Überladen einer Funktion:

Delphi-Quellcode:

procedure OverwriteProcedure(OldProcedure, NewProcedure: pointer; Data: POverwrittenData = nil);
{ OverwriteProcedure originally from Igor Siticov }
{ Modified by Jacques Garcia Vazquez }
var
  x: PAnsiChar;
  y: integer;
  ov2, ov: cardinal;
  p: pointer;
begin
  if Assigned(Data) then
  if (Data.Location <> nil) then
    exit; { procedure already overwritten }

  // need six bytes in place of 5
  x := PAnsiChar(OldProcedure);
  if not VirtualProtect(Pointer(x), 6, PAGE_EXECUTE_READWRITE, @ov) then
    RaiseLastOSError;

  // if a jump is present then a redirect is found
  // $FF25 = jmp dword ptr [xxx]
  // This redirect is normally present in bpl files, but not in exe files
  p := OldProcedure;

  if Word(p^) = $25FF then
  begin
    Inc(Integer(p), 2); // skip the jump
    // get the jump address p^ and dereference it p^^
    p := Pointer(Pointer(p^)^);

    // release the memory
    if not VirtualProtect(Pointer(x), 6, ov, @ov2) then
      RaiseLastOSError;

    // re protect the correct one
    x := PAnsiChar(p);
    if not VirtualProtect(Pointer(x), 6, PAGE_EXECUTE_READWRITE, @ov) then
      RaiseLastOSError;
  end;

  if Assigned(Data) then
  begin
    Move(x^, Data.OldCode, 6);
    { Assign Location last so that Location <> nil only if OldCode is properly initialized. }
    Data.Location := x;
  end;

  x[0] := AnsiChar($E9);
  y := integer(NewProcedure) - integer(p) - 5;
  x[1] := AnsiChar(y and 255);
  x[2] := AnsiChar((y shr 8) and 255);
  x[3] := AnsiChar((y shr 16) and 255);
  x[4] := AnsiChar((y shr 24) and 255);

  if not VirtualProtect(Pointer(x), 6, ov, @ov2) then
    RaiseLastOSError;
end;

function MyWideSameText(const S1, S2: WideString): Boolean;
begin
  Result := false;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  OverwriteProcedure(@SysUtils.WideSameText, @MyWideSameText);
end;

[netspy]

Danke für die Antwort. Das bringt mich aber leider nicht weiter. Ich brauche schon die echte CompareString-Funktion, da ich die für die jeweilige Spracheinstellung passende Sortierung brauche und das für alle möglichen Sprachen selbst zu programmieren ist wohl ein Ding der Unmöglichkeit.

Wenn ich die Antwort in microsoft.public.win32.programmer.international auf deine Frage sehe, dass wohl die "collation tables" grundlegend geändert wurden, dann sieht es aber schlecht mit einer einheitlichen Lösung aus.

[sh17]

Zitat von netspy:

Wenn ich die Antwort in microsoft.public.win32.programmer.international auf deine Frage sehe, dass wohl die "collation tables" grundlegend geändert wurden, dann sieht es aber schlecht mit einer einheitlichen Lösung aus.

Allerdings. Ich frage mich nur, was der Grund für diese gewollte Inkompatibilität sein soll. Alle mal ein wenig ärgern?

Ich arbeite mich grad zu diesem Thema durch MSDN und dem Blog desjenigen, der geantwortet hat http://blogs.msdn.com/michkap/default.aspx