And don't expect programs written for fpc 3.x to work correctly with 2.6.4 or older, because v3 introduces a massive change in string handling.
Oh, there we misunderstood: I do
not try to run programs with FPC 2.6.4, which have been written for FPC 3.x. What I have is a couple of "common libraries", which exist only once, and I use these both for all new programs with FPC 3.x and for a couple of older programs, which I still compile with FPC 2.6.4, because they have originally been written for 2.6.4, and (until now) I did not update them to 3.x.
I am attaching a demo for FindFirst which finds a file "testäöü.txt" which should cause issues according to your description. Me me, it does not. The filename is displayed in the console correctly with fpc 3.2 as well as 2.6.4 (after conversion). (NOTE: my windows cp is 1252. If yours is different the filename may appear differently than shown here). And it does not make a difference whether LazUTF8 is linked in or not (activate/deactivate the define USE_LAZUTF8).
Thank you for your demo and the time you invested to help me. I found out, that to activate/deactivate the define USE_LAZUTF8 made no difference. I found the reason in, that Unit LConvEncoding is used, which contains:
uses SysUtils, Classes, dos, LazUTF8
so LazUTF8 was
always included and you saw no difference.
After deactivating units LazUTF8
and LConvEncoding I had exactly the difference, which I was talking about. I added some lines to make the difference clearer:
begin
...
if FindFirst('test*.*', faAnyFile, SR) = 0 then // to catch file 'testäöü.txt'
begin
repeat
WriteLn('Filename as returned by FindFirst: ', SR.Name);
for i:=1 to length(SR.Name) do write(HexStr(ord(SR.Name[i]),2), ' ');
writeln('len=', length(SR.Name));
...
until FindNext(SR) <> 0;
FindClose(SR);
end;
...
end.
Here is the output, depending on FPC version and whether LazUTF8 (including LConvEncoding) was enabled or not (all on Windows 7 32-bit):
FPC LazUTF8 Output
---------------------
3.0.4 yes 74 65 73 74 5F C3 A4 C3 B6 C3 BC 2E 74 78 74 len=15
3.0.4 no 74 65 73 74 5F E4 F6 FC 2E 74 78 74 len=12
2.6.4 yes 74 65 73 74 5F E4 F6 FC 2E 74 78 74 len=12
2.6.4 no 74 65 73 74 5F E4 F6 FC 2E 74 78 74 len=12 We see, that in FPC 3.x the
same FindFirst() function
changes the charset of the reported filenames between UTF8-charset and Windows-charset, whether you include Unit LazUTF8 or not. All procedures and functions which deal with filenames switch the same. And as I wrote, the charsets of the results of ParamStr() and the results of readln() play the same game. And it might be more (which I only not remember now).
I hope that you now will believe that my list of problems and disadvantages with Unit LazUTF8 is real.