[fpc-devel] bug report 20473: Please add a directive to define string=utf8string

[Marco van de Voort]

In our previous episode, Craig Peterson said:
> >> Plus, isn't Embarcadero pushing FireMonkey anyway?
> >
> > I don't see it that way. I see FM as a Delphi PHP/3rd Rail/Prism like
> > product, not as serious VCL contender. If I understood it correctly, it is
> > mostly a sideproduct of internal efforts to port Embarcadero's non-Borland
> > originating lines.
> 
> Why would you think that? 

No backwards compatibility, no native ties to tie it down. Clearly it is
meant to be fast moving by skipping details. And that doesn't appeal to the
bulk of the Delphi crowd

> FireMonkey isn't mature enough to be usable 
> yet, but it's definitely where future Delphi development will occur. 
> After XE2 shipped Embarcadero laid off a bunch of VCL developers and 
> announced they were growing their overseas teams (likely FireMonkey):

I doubt it, but if that is true, it is the end of Delphi.

> http://community.devexpress.com/blogs/ctodx/archive/2011/09/19/delphi-vcl-is-dead-long-live-firemonkey.aspx
> 
> ARM/iOS/Android support will require FireMonkey, and is their biggest 
> growth opportunity. 

That is however fully true, revenue growth won't come from the traditional
Delphi/VCL users, it will only wane.  But that is something totally, totally
else than killing off VCL and trying to convince them to go to FM.

That is the quickest way to loose that nice big comfy auto-upgrade money
that is coming in every year and pays the fixed bills.

And the same story (new revenue) is true for the other products (Delphi PHP/3rd Rail and Prism)
too, so I'm sticking to my view :_)

> Allen Bauer has also said FireMonkey apps should be able to work with
> Windows 8's Metro interface, which won't be true for VCL apps.

That would be logical yes, since it is not win32 api based. I hope for E. 
that Metro will remain a sideshow, since I think Embarcadero would lose more
Delphi/VCL guys to C# than that would go to FM, if push came to shove.
 
> BTW, I wanted to point out, to anyone arguing for full Delphi 
> compatibility, that on OS X Delphi's DefaultSystemCodePage and 
> AnsiString(0) are *not* the system encoding _or_ UTF-8.  They're the 
> Windows ANSI codepages that correspond to the system's locale (so, 1252 
> for US/UK versions).  It's a weird gotcha, and means it's not safe to 
> rely on AnsiString to communicate with system functions anymore.

I don't understand this. Yes the ansistring system uses 1252, but the
compiler/RTL can make the mappings, so I don't really understand your
problem. 

A numeric enumeration of codepages is more efficient (and less free form)
than a stringbased one, so the Windows system isn't that bad.