[Lazarus] TProcess, UTF8, Windows

[Mattias Gaertner]

On Mon, 16 Apr 2012 07:43:22 +0200
Martin Schreiber <mse00000 at gmail.com> wrote:

> On Monday 16 April 2012 00:04:41 Mattias Gaertner wrote:
> > On Sun, 15 Apr 2012 15:58:24 +0200
> >
> > Martin Schreiber <mse00000 at gmail.com> wrote:
> > > And probably Mattias is wrong if he thinks "String" in FPC trunk does not
> > > enforce encoding if I understood correctly.
> >
> > "string" enforces an 8-bit type.
> > It does not enforce a specific codepage like utf8string. At least under
> > Linux.
> 
> "String" = "AnsiString(CP_APC)", quote:
> "
> Martin:
> > And if you use "String" (= AnsiString(CP_ACP) if my assumption about current 
> > FPC trunk is correct) it forces it to the 8bit system encoding. The only 
> > stringtype which does not enforce encoding is "RawByteString".
> > All "AFAIK" of course. ;-)
> 
> Marco:
> That's correct.
> "

And your point is?
I only gave test results. "string" does not enforce CP_ACP under Linux
with current FPC 2.7.1.

 
> > Assign a CP_UTF8 and the string becomes CP_UTF8, assign a CP_ACP and it
> > becomes CP_ACP, assign a CP_UTF16 and it becomes DefaultSystemCodePage.
> > I have not tested under Windows.
> >
> On most Linux CP_ACP is utf-8, on most Windows it is not utf-8.
> 
> > Probably we should wait until the dust has settled before drawing
> > conclusions.
> >
> We wait since several months. Anyway, as I wrote on lazarusforum.de, in the 
> end it probably will be exactly like Delphi because Delphi compatibility has 
> priority, maybe because several FPC core devels professionally work with 
> Delphi.
>
> http://www.lazarusforum.de/viewtopic.php?f=10&t=5855

They will probably implement a very compatible solution. But the FPC
team showed that they are capable of implementing and maintaining more
than the Delphi mode.

Mattias