Unicode und WideChar API-Funktionen

[Dalai]

Hallo ihr :).

Aus bestimmten Gründen versuche ich mich derzeit an Free Pascal. Leider blieb ich sehr schnell an der Thematik Unicode und WideChar API-Funktionen hängen, und auch die vielfältigen Angaben im Internet helfen mir nicht dabei, die Sache für mich zufriedenstellend - mit möglichst wenigen Änderungen am Code - zu lösen.

Gegeben sei folgender, auf das Wesentliche reduzierte Beispiel-Code:

Delphi-Quellcode:

program project1;

{$MODE DELPHI}

uses Classes, SysUtils, CustApp, Windows;

type
  TMyApplication = class(TCustomApplication)
  private
    FStr: string;
  [...]
  end;

procedure TMyApplication.DoRun;
begin
  [...]
  SetLength(FStr, 32768);
  SetLength(FStr, ExpandEnvironmentStrings(PChar('%SystemRoot%\System32'), @FStr[1], Length(FStr))-1);
  WriteLn(FStr);
  ReadLn;
end;

Funktioniert einwandfrei. Aber es wird die ANSI-Variante der API-Funktion (ExpandEnvironmentStringsA) importiert. Nun wollte ich die Sache unicodefähig machen, also dachte ich mir, setze ich

Delphi-Quellcode:

{$MODE DELPHIUNICODE}

. Leider Fehlanzeige:

Code:

Compile Project, Mode: Debug, Target: project1.exe: Exit code 1, Errors: 1, Warnings: 2
project1.lpr(36,14) Warning: Implicit string type conversion from "AnsiString" to "UnicodeString"
project1.lpr(38,44) Warning: Implicit string type conversion with potential data loss from "UnicodeString" to "AnsiString"
project1.lpr(52,50) Error: Incompatible type for arg no. 1: Got "PWideChar", expected "PChar"

(Der Error wird an der Stelle des Calls der API-Funktion gemeldet.) Soweit ich das bisher verstandenn habe, liegt das daran, dass nur die eigene Unit in Bezug auf Strings und PChars umdefiniert wird, die von FPC mitgebrachten Units aber nicht. Es wird also weiterhin ExpandEnvironmentStringsA benutzt.

Wie kann man das lösen bzw. was ist der empfohlene Weg, dass der Code sowohl in Delphi als auch FPC verwendbar ist? Es kann ja nicht Sinn der Sache sein, den Code mit expliziten Aufrufen der Wide-Funktionen und - bei umfangreicherem Code - zahllosen IFDEFs zuzupflastern...

Grüße
Dalai

[himitsu]

Dann mach es doch explizit als Unicode?

Delphi-Quellcode:

  private
    FStr: UnicodeString;  // oder WideString

  SetLength(FStr, ExpandEnvironmentStringsW(PWideChar('%SystemRoot%\System32'), @FStr[1], Length(FStr))-1);

Als ich zuletzt in FreePascal / Lazarus schautet, dann war da nichts mit "Unicode".
Oft wurde aber mit UTF-8 in einem "AnsiString" gearbeitet.

Windows benutzt aber UTF-16 bzw. früher UCS-2.

[Dalai]

Zitat:

Zitat von himitsu (Beitrag 1520408)

Dann mach es doch explizit als Unicode?

Das geht zwar, dann müsste ich aber sämtliche Variablen umstellen und alle API-Aufrufe ersetzen - bei beiden mit einigen Ausnahmen, weil es API-Funktionen gibt, die ANSI-Chars erwarten bzw. ausgeben. Den Aufwand, diese Änderungen in wahrscheinlich einem Dutzend eigener Units durchzuführen, will ich vermeiden. Zumal dabei die Gefahr besteht, im alten Delphi funktionierenden Code zu vermurksen.

Zitat:

Als ich zuletzt in FreePascal / Lazarus schautet, dann war da nichts mit "Unicode".

Auch wenn es den Mode jetzt gibt, nützt das IMO überhaupt gar nichts, wenn nicht auch die mitgelieferten Units mit umgestellt sind/werden. Praktisch verwendbar ist diese nur partielle Umstellung nicht. Aber vielleicht gibt es noch einen mir bislang unbekannten Weg, der keine umfangreichen Umbauarbeiten erfordert.

Grüße
Dalai

[Dalai]

Das Eingangsbeispiel ist wohl etwas zu knapp ausgefallen ist. Hier ein etwas längeres, das die Problematik (hoffentlich) besser verdeutlicht:

Delphi-Quellcode:

program project1;

{$MODE DELPHI}

uses Classes, SysUtils, CustApp, Windows, IniFiles;

type
  TMyApplication = class(TCustomApplication)
  private
    FStr: WideString;
    FValue: WideString;
    FFileName: WideString;
  [...]
  end;

procedure TMyApplication.DoRun;
begin
  [...]
  FFileName:= 'C:\irgendeine.ini';
  FIni:= TIniFile.Create(FFileName);        // <--
  try
    FValue:= FIni.ReadString('foo', 'bar', 'blub');   // <--
    SetLength(FStr, 32768);
    SetLength(FStr, ExpandEnvironmentStringsW(PWideChar(FValue), @FStr[1], Length(FStr))-1);
  finally
    FIni.Free;
  end;
  WriteLn(FStr);
  ReadLn;
end;

Die markierten Zeilen werfen folgende Warnungen:

Code:

Compile Project, Mode: Debug, Target: project1.exe: Success, Warnings: 2
project1.lpr(55,35) Warning: Implicit string type conversion with potential data loss from "WideString" to "AnsiString"
project1.lpr(57,18) Warning: Implicit string type conversion from "AnsiString" to "WideString"

Das heißt, selbst wenn ich explizit WideString nutze, renne ich gegen eine andere Wand. Das muss doch besser gehen.

Grüße
Dalai

[himitsu]

Bei implizitem Cast wird gemeckert,

aber bei expliziten Casts nicht:

Delphi-Quellcode:

  FIni:= TIniFile.Create(AnsiString(FFileName));
  try
    FValue:= WideString(FIni.ReadString('foo', 'bar', 'blub'));

Das Zweite wäre kein Problem, da ja Klein zu Groß und es somit rein passen würde.

Beim Ersten, sieht es anders aus ... also problematisch, wenn Unicodezeichen im Dateiname vorkommen würden, welche außerhalb des jeweiligen ANSI-Zeichenraumes liegen.


ABER, ist das wirklich AnsiString, oder nicht vielleicht doch z.B. UTF-8 String?

Ich dachte der FPC hätte in seiner RTL schon "Unicode" und eben nicht ANSI.
Wenn z.B. ein UTF8-String, dann wäre es schon unpraktisch, wenn FPC keine automatische Konvertierung zwischen den String-Typen bietet.


Wie genau sind denn TIniFile.Create und TIniFile.ReadString "wirklich" deklariert?
https://www.freepascal.org/docs-html...eadstring.html

Wenn tatsächlich "String" und String = AnsiString, dann ... Wo bitte hat FPC denn seine unicode-fähige INI-Klasse versteckt?

[jaenicke]

Es gibt bei Lazarus eine Includedatei für Ansi und eine für Unicode für den Zugriff auf die API. Ich habe aber keine Ahnung, wie man die Unicodeversion aktiviert. Der Schalter in den Projekteinstellungen scheint es nicht zu sein.

Ich habe aktuell Lazarus nicht installiert und kann nicht nachschauen. Ich hatte aber mal gesucht.

Soweit ich das sehe, wird intern zwar UTF-8 verwendet, aber statt dieses dann umgewandelt in UTF-16 automatisch an die Unicode-API zu füttern, wird offenbar (mit den Standarddirektiven) fest Ansi verwendet.

Das war bei Delphi 7, an das ja auch die Oberfläche von Lazarus angelehnt ist, aber auch nicht anders. Insofern...

[Dalai]

Bitte entschuldigt die längere Funkstille meinerseits. Die vergangenen Tage hab ich damit verbracht, einen Teil meiner Units für Free Pascal umzuschreiben. Leider sind die Ergebnisse alles andere als zufriedenstellend. Die Sache ist so undurchsichtig und stellenweise widersprüchlich, dass bei mir einige Fragen aufgetaucht sind und ich die Hoffnung habe, dass jemand sie eindeutig beantworten kann.

• Nehmen wir diese Funktion aus source\rtl\objpas\sysutils\sysutils.inc:
  
  Delphi-Quellcode:

  function GetModuleName(Module: HMODULE): string;
  var
    ResultLength, BufferLength: DWORD;
    Buffer: UnicodeString;
  begin
    BufferLength := MAX_PATH div 2;
    repeat
      Inc(BufferLength, BufferLength);
      SetLength(Buffer, BufferLength);
      ResultLength := GetModuleFileNameW(Module, Pointer(Buffer), BufferLength);
      if ResultLength = 0 then
        Exit('');
    until ResultLength < BufferLength;
    SetLength(Buffer, ResultLength);
    Result := Buffer;
  end;

  Warum wird hier ein UnicodeString an einen String (laut Hint in der Lazarus IDE ist String = AnsiString) zugewiesen? Während der Umstellung meiner Units sind mir noch andere Funktionen aufgefallen, die nach demselben Prinzip arbeiten.
  
  Aus Interesse hab ich die Funktion unverändert in meine Projektdatei kopiert (und umbenannt), und wie erwartet wird die Zuweisung an Result mit der entsprechenden Warnung bemängelt. Andererseits steht im Wiki-Artikel, dass man eine solche Zuweisung machen kann - dort string an UnicodeString, aber das Prinzip bleibt - und der Compiler sich um die Konvertierung kümmert:
  Zitat:

  When a parameter type is a pointer PWideChar, you need a temporary UnicodeString variable. Assign your String to it. The compiler then converts its data.

  Entweder ist die Warnung Banane und die Konvertierung erfolgt sauber, oder die Warnung ist berechtigt und die Zuweisung führt potentiell zu Datenverlust. Beides ist unbefriedigend, letzteres sogar fatal. Was ist richtig?
  
  
• Was passiert bei einem direkten (harten) Cast von UnicodeString nach String, vor allem mit enthaltenen Unicode-Zeichen außerhalb der eigenen ANSI-Codepage? Werden die Zeichen verstümmelt oder landet das zweite Byte des Zeichens unverändert im (Ansi)String? Kommen die Zeichen wieder sauber heraus, wenn ein UnicodeString an einen String und dieser danach wieder an einen UnicodeString zugewiesen wird, oder sind die Zeichen danach kaputt?
• Anschließend an den vorherige Punkt: Sollte ich Casts benutzen oder Konvertierungsfunktionen?
• Sofern die Antwort auf die vorherige Frage "Konvertierungsfunktionen" lautet, sollte ich die Unit LazUnicode verwenden oder könnte ich auch simple Funktionen wie die im Thema Delphi7 mit nur einer Unit Unicode fähig machen zu findenden benutzen? Wenn Unit LazUnicode, sollte ich UseUTF16 definieren/verwenden oder nicht?
  
  Wobei ich mich schon frage, wozu die Unit LazUnicode gut sein soll, wenn doch der Compiler (laut Wiki) die Konvertierung durchführt... Wie schon gesagt, es ist undurchsichtig.
  
  
• Apropos Free Pascal Wiki. Dort ist der Satz zu finden
  Zitat:

  There is also a test program LazUnicodeTest in components/lazutils/test directory.

  Im ganzen Verzeichnis von Lazarus gibt es keine Datei mit einem solchen Namen. Nach einiger Sucherei hab ich das gemeinte Projekt gefunden unter components\lazutils\examples\LazUnicode\LazUnicode Console.lpi.
  Im Wiki steht zuvor noch der Satz
  Zitat:

  Currently the {$ModeSwitch UnicodeStrings} can be tested by defining "UseUTF16".

  Also dachte ich, ich geh in den Projektoptionen meines Projekts zu "Custom Options" > Defines und setze dort UseUTF16. Hat keine Wirkung. Ist meine Annahme falsch, dass die dort definierten Defines für alle Units des Projekts gelten?
  
  Erst nach dem Auffinden des Test-/Beispielprojekts konnte ich sehen, dass UseUTF16 dort im Bereich "Additions and Overrides" der Projektoptionen definiert wird. Solche Ungenauigkeiten bzw. fehlerhafte Angaben nerven und sind für Neulinge in Lazarus bzw. Free Pascal nicht gerade förderlich.

Es gibt noch Klassen und Funktionen (TIniFile, TFileStream, FormatDateTime, AnsiQuotedStr), für die ich keine unicodefähigen Varianten gefunden habe bzw. Konvertierungsmöglichkeiten brauche.

Grüße
Dalai

[himitsu]

Also, wenn man mit Pointer rumpfuscht, anstatt PWideChar zu benutzen ... wenn irgendwann der Typ nicht mehr stimmt, dann beschwere dich bitte nicht, wenn der Compiler dir nichts sagen wird.

Zitat:

Zitat von Dalai (Beitrag 1520675)

Warum wird hier ein UnicodeString an einen String (laut Hint in der Lazarus IDE ist String = AnsiString) zugewiesen?

Jemand hat vergessen zu sagen in welcher Zeile.
Ich rate mal.
Die Letzte? (mit dem Result:=)
Und nun überleg mal was du dort machst. :wink:

Delphi-Quellcode:

SetLength(Buffer, GetModuleFileNameW(Module, nil, 0));
GetModuleFileNameW(Module, PWideChar(Buffer), Length(Buffer)+1);

Aber wenn du sowie so kein Unicode haben willst, dann

Delphi-Quellcode:

function GetModuleName(Module: HMODULE): string;  // oder eben UnicodeString und nachfolgend PWideChar
begin
  SetLength(Result, GetModuleFileName(Module, nil, 0));
  GetModuleFileName(Module, PChar(Result), Length(Result)+1);
end;

Im Delphi war String früher AnsiString und GetModuleFileName ein Alias für GetModuleFileNameA, bzw. PChar ein PAnsiChar,
und nun ist String ein UnicodeString und GetModuleFileName ein Alias für GetModuleFileNameW mit PWideChar.
Eventuell gibt es sowas mit dem genannten

Delphi-Quellcode:

{$ModeSwitch UnicodeStrings}

auch für Lazarus?

Delphi-Quellcode:

Result := Buffer;
Result := String(Buffer);

Mit Cast oder implitzt kommt erstmal das Gleiche bei raus, also vom Inhalt ... nur das Letzteres eben keine Cast-Warnung wirft.

Ich weiß nicht wie Lazarus/FPC das macht.
Vermutlich wie Delphi früher. Da wurde die Codepage des Types verwendet, also von der Variable.
Delphi seit 2009, hat die Codepage zusätzlich im String gespeichert und Verwendet vorzugsweise Dieses. (auch wenn man mal z.B. UTF-8 in einem "AnsiString" drin hat und nicht den UTF8String benutzte)

Zitat:

Currently the {$ModeSwitch UnicodeStrings} can be tested by defining "UseUTF16".

Vielleicht meinen die es andersrum?

vorher irgendwo

Delphi-Quellcode:

{$ModeSwitch UnicodeStrings}

und später dann mit

Delphi-Quellcode:

{$IFDEF UseUTF16}

testen.

[KodeZwerg]

{$mode delphiunicode} sollte dir dabei gut weiterhelfen das alles so bleiben kann.
oder ein anderer ansatz, {$modeswitch m_default_unicodestring}

[Dalai]

Zitat:

Zitat von himitsu (Beitrag 1520678)

Also, wenn man mit Pointer rumpfuscht, anstatt PWideChar zu benutzen ... wenn irgendwann der Typ nicht mehr stimmt, dann beschwere dich bitte nicht, wenn der Compiler dir nichts sagen wird.

Ich dachte, es wäre klar gewesen (vor allem durch Angabe der Quelltextdatei), dass diese Funktion exakt so in den Sourcen von FPC steht. Deswegen auch meine Frage, warum die Funktion so aussieht.

Zitat:

Jemand hat vergessen zu sagen in welcher Zeile.
Ich rate mal.
Die Letzte? (mit dem Result:=)

Es gibt in dieser Funktion nur eine Zeile, wo ein UnicodeString an einen String zugewiesen wird - die Zuweisung an Result.

Zitat:

Und nun überleg mal was du dort machst. :wink:

Ich hab den Code nicht geschrieben, er ist 1:1 aus den Sourcen von FPC übernommen. Die Frage war, warum das dort so steht und ob die Warnung (bzgl. möglichem Datenverlust wegen UnicodeString -> String), die bei Übernahme der Funktion in eine eigene Unit auftaucht, gerechtfertigt ist.

Es sei noch ergänzt, dass ich die Funktion nur aus Neugier und Verwunderung ins eigene Projekt kopiert habe. Beim Lesen der Funktion tauchten sofort die Fragen auf, warum Pointer statt PWideChar benutzt wird und warum ohne Cast/Konvertierung ein UnicodeString an String zugewiesen wird. Ich wollte herausfinden, ob bzgl. des (Unicode)Strings eine Warnung auftaucht oder nicht. Sie taucht auf, und nun würde ich gern wissen, ob die berechtigt ist oder nicht.

Zitat:

Im Delphi war String früher AnsiString und GetModuleFileName ein Alias für GetModuleFileNameA, bzw. PChar ein PAnsiChar,
und nun ist String ein UnicodeString und GetModuleFileName ein Alias für GetModuleFileNameW mit PWideChar.

Das ist mir alles bekannt. Hier im Thread geht's aber explizit um Free Pascal.

Zitat:

Eventuell gibt es sowas mit dem genannten

Delphi-Quellcode:

{$ModeSwitch UnicodeStrings}

auch für Lazarus?

Das hatte ich ja am Anfang probiert, zwar mit

Delphi-Quellcode:

{$Mode DelphiUnicode}

, aber das Ergebnis ist dasselbe wie mit

Delphi-Quellcode:

{$ModeSwitch UnicodeStrings}

. Dabei hab ich festgestellt, dass die Funktionen/Klassen aus der FPC RTL eben nicht alle mit UnicodeString verfügbar sind. Das ist ja der Grund für den Thread hier und meine Fragen.

Zitat:

Delphi-Quellcode:

Result := Buffer;
Result := String(Buffer);

Mit Cast oder implitzt kommt erstmal das Gleiche bei raus, also vom Inhalt ... nur das Letzteres eben keine Cast-Warnung wirft.

Dass die Warnung unterdrückt wird, ist mir klar. Die Frage ist, ob man einfach so casten kann oder ob dadurch Zeichen kaputtgehen. Die Konvertierungsfunktionen (spätestens MultiByteToWideChar/WideCharToMultiByte in der Win32 API) existieren ja sicherlich auch nicht ohne Grund.

Zitat:

Ich weiß nicht wie Lazarus/FPC das macht.

Schade. Ich hoffe, jemand kann etwas zu diesem Punkt sagen.

Zitat:

Delphi seit 2009, hat die Codepage zusätzlich im String gespeichert und Verwendet vorzugsweise Dieses.

String ist doch seit 2009 ein UnicodeString. Inwiefern spielt dabei eine Codepage eine Rolle? Oder meinst du AnsiString?

Zitat:

Vielleicht meinen die es andersrum?

vorher irgendwo

Delphi-Quellcode:

{$ModeSwitch UnicodeStrings}

und später dann mit

Delphi-Quellcode:

{$IFDEF UseUTF16}

testen.

Das glaube ich nicht. In der Unit LazUnicode kann man am Anfang Folgendes finden:

Delphi-Quellcode:

// For testing the UTF16 version.
{$IF DEFINED(FPC) and DEFINED(UseUTF16)}
 {$ModeSwitch UnicodeStrings}   // Sets also FPC_UNICODESTRINGS.
{$ENDIF}

{$IF DEFINED(FPC_UNICODESTRINGS) or not DEFINED(FPC)}
 {$DEFINE ReallyUseUTF16}       // FPC with UTF-16 or Delphi
{$ENDIF}

Und im Code dieser Unit wird dann an bestimmten Stellen

Delphi-Quellcode:

{$IFDEF ReallyUseUTF16

benutzt.

Grüße
Dalai

[Dalai]

Zitat:

Zitat von KodeZwerg (Beitrag 1520681)

{$mode delphiunicode} sollte dir dabei gut weiterhelfen das alles so bleiben kann.

Nein, das genügt nicht, siehe OP bzw. Beitrag #4.

Delphi-Quellcode:

{$Mode DelphiUnicode}

bzw.

Delphi-Quellcode:

{$ModeSwitch UnicodeStrings}

macht String zu UnicodeString, und (P)Char zu (P)WideChar. An den Imports der API-Funktionen ändert sich nichts, d.h. der Alias ExpandEnvironmentStrings verweist weiterhin auf ExpandEnvironmentStringsA statt ExpandEnvironmentStringsW.

Analog gilt das auch für die Klassen und Funktionen der Free Pascal RTL, wie man auch im von dir verlinkten Teil lesen kann. TIniFile und TFileStream kommen nach dem Umschalten nicht automatisch mit Unicode-Dateinamen bzw. -inhalten klar. Naja, vielleicht kommen sie schon damit klar (diese Frage ist ja weiterhin ungeklärt), aber es gibt beim Kompilieren Warnungen. Um die loszuwerden, muss man sich jeden einzelnen Aufruf anschauen und ändern, also eine andere Funktion rufen (z.B. UnicodeFormat statt Format), Casten oder Konvertierungsfunktion rufen. Das bedeutet, es kann eben nicht alles so bleiben.

Zitat:

oder ein anderer ansatz, {$modeswitch m_default_unicodestring}

Meintest du

Delphi-Quellcode:

{$ModeSwitch UnicodeStrings}

?

Grüße
Dalai

[KodeZwerg]

Ich habe mal für Dich im Lazarus Forum nachgefragt und die Antwort ist traurig, es geht schlichtweg nicht per switches oder conditionals.

Die einzige Möglichkeit ist es in der "Windows.pp" unit das hier einzufügen (was allerdings gegen die FPC/Lazarus Programmierung Arbeit, also ohne Gewähr!)

Patch:

Delphi-Quellcode:

{
    This file is part of the Free Pascal run time library.
    This unit contains the record definition for the Win64 API
    Copyright (c) 1999-2006 by Florian KLaempfl,
    member of the Free Pascal development team.

    See the file COPYING.FPC, included in this distribution,
    for details about the copyright.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 **********************************************************************}
unit windows;

{$PACKSET 1}

{$ifndef NO_SMART_LINK}
{$smartlink on}
{$endif}

{ stuff like array of const is used }
{$mode objfpc}
{$modeswitch ADVANCEDRECORDS}
{$modeswitch class}
{$inline on}
{$calling stdcall}

{$define FPC_OS_UNICODE} // <<<--- füge das ein

{$ifdef FPC_OS_UNICODE}
  {$define UNICODE}
{$endif}

getestet mit Lazarus 2.3.0 (rev 3bdbedd91b) FPC 3.2.2 x86_64-win64-win32/win64

[himitsu]

Die bräuchten ja doch nur für ihren Code (INC's) die passenden Unicode-Alternativen, welche über diesen Schalter umgeschaltet werden. :stupid:

[KodeZwerg]

Mir wurde soeben eine bessere Variante gezeigt ohne das die RTL "angegriffen" wird und ich hoffe die ist okay für Deine Zwecke @Dalai

Delphi-Quellcode:

unit Unit1;
// basis settings um es unicode fähig zu machen
{$mode objfpc}
{$modeswitch unicodestrings}

interface

uses
  Windows , // ganz regulär integrieren
  Classes , SysUtils , Forms , Controls , Graphics , Dialogs;

// unicode hack teil 1/2
{$define read_interface}
{$undef read_implementation}
{$i C:\FreePascal\fpcsrc\rtl\win\wininc\unidef.inc}

type

  { TForm1 }

  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
  private
  public
  end;

var
  Form1: TForm1;

implementation

// unicode hack teil 2/2
{$undef read_interface}
{$define read_implementation}
{$i C:\FreePascal\fpcsrc\rtl\win\wininc\unidef.inc}

{$R *.lfm}

{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
var
  lpApplicationName: PChar; // (PWideChar/LPCWSTR)
  lpBinaryType: LPDWORD;
begin
  GetBinaryType(lpApplicationName, lpBinaryType);
  // zeigt nun auf function GetBinaryType(lpApplicationName:LPCWSTR; lpBinaryType:LPDWORD):WINBOOL; external 'kernel32' name 'GetBinaryTypeW';
end;

end.

[Stevie]

Delphi 2009 hat angerufen und will seine Unicodeumstellung zurück :lol:

[Dalai]

Zitat:

Zitat von KodeZwerg (Beitrag 1520897)

Ich habe mal für Dich im Lazarus Forum nachgefragt und die Antwort ist traurig, es geht schlichtweg nicht per switches oder conditionals.

Danke fürs Nachfragen! Nach meinem bisherigen Eindruck ist die Situation wirklich traurig und unbefriedigend.

Zitat:

Die einzige Möglichkeit ist es in der "Windows.pp" unit das hier einzufügen (was allerdings gegen die FPC/Lazarus Programmierung Arbeit, also ohne Gewähr!)

Das FPC_OS_UNICODE kann man wahrscheinlich auch via "Additions and Overrides" in den Projektoptionen definieren. Eigentlich ist dieses Define aber für WinCE, was es nur als Unicode-OS gibt.

Zitat:

Zitat von KodeZwerg (Beitrag 1520935)

Mir wurde soeben eine bessere Variante gezeigt ohne das die RTL "angegriffen" wird und ich hoffe die ist okay für Deine Zwecke @Dalai

Beide Varianten helfen zwar für einige wenige Units, aber bei weitem nicht für alle und vor allem nicht für die Funktionen und Klassen der RTL. Für TStringList, TIniFile, TFileStream und wohl noch viele weitere ändert sich leider nichts. Und logischerweise ändert sich auch nichts, wenn eine RTL-Funktion explizit eine AnsiChar-API-Funktion ruft. All diese Sachen hab ich schon gesehen während der Konvertierung/Portierung eines meiner Projekte. Und das ist noch nicht einmal eines mit GUI. Keine Ahnung, wie die Situation mit Komponenten der LCL wäre.

Dennoch vielen vielen Dank für deinen Einsatz! :-D Bin mal gespannt, wie lange es noch dauert, bis die Umstellung der Free Pascal RTL auf Unicode abgeschlossen ist ... Vielleicht vor dem Ende dieses Jahrzehnts? ;)

Mittlerweile hab ich die Units eines meiner Projekte geändert auf UnicodeString und WideChar. Zum Testen genügt mir das. Mal sehen, ob ich die Entwicklung mit Free Pascal/Lazarus weiter verfolge.

Grüße
Dalai

[himitsu]

Lang lang ist's her.

als ich damals rein sah, gab es in RTL/VCL, bzw. den Quellen des FPC und des Lazarus einen Mischmasch aus ANSI und UTF8, mit einem Hauch von Unicode.


Die RTL kann man zu großen Teilen mit UTF-8 benutzen, also TStringList usw. (so lange intern keine krittischen APIs benutzt werden),
aber mindestens für die Schnittstelle vom/zum Windows (Win32-API), also auch die VCL, braucht es aber eben ANSI oder Unicode, da nicht alles UTF-8 versteht.

Den INI-Inhalt gibt es offiziell (Microsoft) nur als ANSI oder Unicode (UTF-16 und früher UCS-2),
aber so lange man die INI (Inhalt) nur selber benutzt ... UTF-8 ist ja auch eine Art von ANSI.

Nur der Dateiname für die INI/StringList muß eben ANSI oder Unicode sein. (UTF-8 will die ANSI-API nicht verstehen, denn die erwartet dort CP_ACP oder notfalls auch CP_OEM)