[Lazarus] FPC 2.7.1 and console output

[Hans-Peter Diettrich]

Mattias Gaertner schrieb:
> On Wed, 03 Dec 2014 16:46:43 +0100
> Hans-Peter Diettrich <DrDiettrich1 at aol.com> wrote:
> 
>> [...]
>> Q: how do I debug the RTL (step into)?
> 
> Compile it with debugging info (-gl) and install it.

Thanks, I added OPT="-gl" to the "make" commandline, and it worked :-)

>> [...]
>>> If your code contains
>>> literals for a specific Windows codepage then you are limiting
>>> yourself to that codepage (not x-platform). That is your choice.
>>> OTOH Lazarus main target is x-platform programs. For example the
>>> UTF8ToConsole solution works on Unix too, while your CP1252
>>> example does not.
>> What's CP1252 specific in my example?
> 
> Your example works if you use CP1252 as source encoding, as I have
> told you. I'm not sure why you call that a 'hack'.

I included the code (readable by everybody), didn't transmit an file.
Also UTF8ToConsole seems not to exist any more in FPC 2.7.1, and should 
not be required any more.
So I'm not sure what you mean :-(

Just tested on WinXP:

program test;
var a: AnsiString;
begin
   a := 'äöü';
   WriteLn(a,'äöü');
end;

works differently with file encoding Ansi, UTF-8 and UTF-8bom. The 
latter correctly shows 'äöüäöü', else a mix of several encodings shows 
up in the console.

Using the default Lazarus file encoding (UTF-8 without BOM) requires to 
add {$codepage UTF8}, to make the program (hopefully) work on either 
platform. {$codepage UTF8} requires UTF-8 file encoding as well, doesn't 
compile when stored as Ansi.

Adding SysUtils, and AnsiUpperCase for the WriteLn arguments, correctly 
shows 'ÄÖÜÄÖÜ' in Ansi file encoding, but 'äöüäöü' in UTF8bom encoding, 
garbage with UTF-8 file encoding, and again 'äöüäöü' with added 
{$codepage UTF8}.

Thus portable source files seem to be bound to both file and $codepage 
UTF-8, disallowing different CP_ACP settings (for now).

Since I'm just exploring the Unicode support, I hope to mention in the 
future all related options, possibly influencing the behaviour of sample 
code. Apart from that I'd expect (hope) that a given (Delphi...) project 
will work in FPC/Lazarus as well, at least on Windows, regardless of 
inobvious requirements like CP_ACP settings (see bottom lines).



>> [...]
>>>> Delphi string literals instead come with their true dynamic encoding, which 
>>>> never can be 0, and thus can be assigned and shown properly. Above code 
>>>> then will show CP=1252 and Len=4 for the AnsiString variable.
>>> No, it should show garbage and Len=7, because the source is UTF-8,
>>> while the compiler treats it as your system codepage.
>> Well, I tested my program with XE, with the default Windows textfile 
>> encoding.
> 
> Ah, so you tested CP1252 encoding under XE.

How else should I compare the results of running the same code in Delphi 
and FPC/Lazarus? Actually I'm testing the Delphi compatibility of FPC 
(trunk).

> The same works under FPC.
> 
>> When FPC or Lazarus has problems with such a program file, 
>> then something is flawed :-(
> 
> PEBCAK

Please point me to the according Lazarus documentation.

When some Delphi user wants to find out whether Lazarus is a usable 
alternative, what should he know before trying to run some Delphi code 
in Lazarus? If this is not documented appropriately, many people may 
drop Lazarus immediately as unusable (incompatible...) :-(

DoDi