[Lazarus] Beyond Compare 4 built with Lazarus 1.2

[Marcos Douglas]

On Sat, Dec 28, 2013 at 6:18 AM, Martin Schreiber <mse00000 at gmail.com> wrote:
> On Friday 27 December 2013 21:10:39 Marcos Douglas wrote:
>>
>> Resume:
>> MSElang do no allow to cancatenate different string types (must be
>> explicitely converted)
>
> Correct.
>
>> and the RTL does not will use string8.
>
> Wrong. MSElang RTL suports string8 (utf-8), string16, (utf-16), string32
> (UCS4) without preference. Additionally there is bytestring for any 8-bit
> encoding or binary data. Please remember, MSElang RTL is the bare minimum,

How do you will code this? Overload for each string type?

> file API for example must be implemented in the frameworks.

I think this is an option even in FPC and Lazarus, ie, I see people,
on the future, creating your own "RTL" because FPC and Lazarus do not
agree about Unicode.  :-)

>> So if I want to use Lazarus (LCL) with MSElang I will continue to have
>> the need to convert all call from/to MSElang RTL because they have
>> different encode. Is that right?
>>
> No. You will use LCL as before. LCL implements the needed functions (file API
> for example) optimized for Lazarus purpose. As people who like to use MSEgui
> will use MSEgui functions which are optimized for use in MSEgui framework and
> fpGUI users probably can use a subset of LCL because fpGUI and Lazarus both
> use utf-8 and try to be mainstream compatible. It is possible that the
> framework developers work together in order to build commonly used base units
> and classes. It makes compiler and RTL-framework development somewhat
> independent.

Very interesting.

> The close coupling of compiler and framework is necessary for a commercial
> software producer in order to optimize profit, opensource development does
> not need it. It is not necessary that the compiler and its environment
> dictate how the frameworks must be implemented.

+1
I agree.

Regards,
Marcos Douglas

PS: This thread is very interesting. Maybe you should open this topico
in mse-list too.