Mattias Gaertner schrieb:
On Wed, 03 Dec 2014 16:46:43 +0100
Hans-Peter Diettrich <drdiettri...@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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
