Type _OSVERSIONINFOA - Verständnisproblem

[Bernhard Geyer]

Zitat:

Zitat von OldGrumpy

Kleines Beispiel: Wenn ich ein japanisches Windows nehme, dann sind da API-Aufrufe ohne Suffix generell die Wide-Varianten.

Falsch! Der Compiler bzw. die compilierte Exe "erkennt" nicht das es jetzt ein japanisches Windows ist auf dem es läuft. Die Bindung ist immer auf die Ansi-Version der API-Funktion/Struktur.

Dort gibt es auch Ansi und Wide-Versionen. Jedoch ist die Ansi-Codepage (wie auch auf chinesischen Windows) so das mehrere Ansi-Characters ein Zeichen darstellen! Damit funktioniert jeder Code nicht mehr korrekt der hart Strings abschneidet oder einzelne Characters aus Strings ändert. Ein String der z.B. 30 1-Byte-Characters beinhaltet ist letztendlich nur 10 (Wide-)Characters lang.

[DGL-luke]

Vielleicht meinte OldGrumpy ja, dass ein japanisches Kompilat die Wideversionen verwenden würde.

[OldGrumpy]

@DGL-luke: Ja, letzteres :) Je nach Compilerumgebung kann der "normale" API-Name entweder auf die A(nsi)- oder W(ide)-Variante gemappt sein. Bin heute irgendwie nicht ganz bei der Sache :(

Edit (2x): Eigen-DAU korrigiert ;)

[Bernhard Geyer]

Zitat:

Zitat von DGL-luke

Vielleicht meinte OldGrumpy ja, dass ein japanisches Kompilat die Wideversionen verwenden würde.

Dazu müßte ja der Quellcode der VCL schon soweit vorbereitet sein das String als Widestring umgesetzt wird und es nicht an Millionen Stellen kracht. Und das kann ich mir beim besten Willen für das Japanische Delphi nicht vorstellen.

[Mazel]

@OldGrumpy, hast du dich hiermit

Zitat:

Ja, letzteres :) Je nach Compilerumgebung kann der "normale" API-Name entweder auf die A(nsi)- oder W(ide)-Variante gemappt sein.

auf meine Frage bezogen?

[OldGrumpy]

Nein, meine Antwort da bezog sich auf DGL-luke, aber generell würde ich dazu tendieren, die W-Apis zu nehmen. Auf Kernelebene ist der Umstieg schon länger komplett vollzogen, insofern werden die Ansi-Apis praktisch nur noch der Kompatibilität wegen mitgeführt.

Edit: Eigen-DAU korrigiert (*sigh*)

[DGL-luke]

Ich dementiere heftigst: Ich bin nicht Luckie!

[OldGrumpy]

ARGH! *schäm* :wall: :wall: :wall:

Ich editiere da oben jetzt nochmal alles :) Mea culpa :(

[Mazel]

So ganz klar ist die Sache für mich aber immer noch nicht, da ich nicht so oft die API verwende bzw. ich mich noch nicht so intensiv beschäftigt habe. Wenn ich eine Funktion zum ermitteln der Windowsversion schreibe, würde die Deklaration des Typen so aussehen, wenn ich die windows.pas nutzte:

Delphi-Quellcode:

function GetWinVer : string;
var
  OSVersionInfo    : TOSVersionInfo;

begin
  ZeroMemory(@OSVersionInfo, SizeOf(TOSVersionInfo));
  OSVersionInfo.dwOSVersionInfoSize := SizeOf(TOSVersionInfo);
  if GetVersionEx(OSVersionInfo) then
   begin
   end;
end;

Das würde doch der Ansi-Variante entsprechen ebenso der Aufruf der Funktion GetVersionEx.
Wenn ich das ganze kompiliere, verarbeite ich doch nur die Ansi-Variante. Demnach müsste das entstande Programm Probleme mit sich bringen, da der Typ _OSVERSIONINFOA verarbeitet und die API Funktion GetVersionExA gebraucht wird aber bei einem Rechner mit nur noch Wide-Version nicht vorhanden ist? Wenn ich die Funktion und den Typ selber in die Unit aufnehme, kann ich die Wide-Version verwenden aber eben nicht wenn ich die Windows.pas einbinde.

[OldGrumpy]

Bisher ist es bei Windows immer so, dass noch ewig lange diverse Rattenschwänze mitgeschleppt werden, um Abwärtskompatibilität zu sichern. (In Delphi gibts z.B. auch immer noch WinExec(), ein Überbleibsel aus Zeiten von Windows 3.x) Wenn 2011 wirklich der Vista-Nachfolger in den Startlöchern steht, womöglich mit .NET 4.0 *g* dann würde ich mich langsam aber nicht mehr darauf verlassen. Wer rechtzeitig umsteigt, hat weniger Probleme - sehr schön sehen konnte man das an der Treibersituation für 64-Bit-Systeme. XP x64 und auch Vista x64 quälen einen immer noch recht derbe durch nicht verfügbare Treiber für allerlei Hardware. Bei den Treibern bleibt den Herstellern nämlich gar nichts anderes übrig, als sich an den neuen Features zu orientieren, die 64-Bit-Varianten brauchen bei Kerneltreibern auch native 64-Bit-Treiber. Und obwohl Vista schon ewig lange für Entwickler verfügbar war, scheinen etliche Hersteller doch wohl TOTAL überrascht worden zu sein, dass Vista jetzt auf einmal in den Läden steht. Hoppla!