On Fri, 28 Jul 2023, Adriaan van Os via fpc-devel wrote:
Michael Van Canneyt via fpc-devel wrote:
Hello,
I have just completed phase one of the "Unicode RTL" effort.
I object to the name "Unicode" RTL. Where people talk about what they call
"Unicode" they usually mean UCS-16 or UTF-16 o
Michael Van Canneyt via fpc-devel wrote:
Hello,
I have just completed phase one of the "Unicode RTL" effort.
I object to the name "Unicode" RTL. Where people talk about what they call "Unicode" they usually
mean UCS-16 or UTF-16 or UTF-16-mishandled-as-UCS16.
Regards,
Adriaan van Os
On Fri, 28 Jul 2023, Mattias Gaertner via fpc-devel wrote:
On 24.07.23 21:49, Michael Van Canneyt via fpc-devel wrote:
[...]
Subtarget support is explained in more detail here:
https://wiki.freepascal.org/FPC_Subtarget_Support
* compile the various Lazarus widgetsets into different direct
On 24.07.23 21:49, Michael Van Canneyt via fpc-devel wrote:
[...]
Subtarget support is explained in more detail here:
https://wiki.freepascal.org/FPC_Subtarget_Support
* compile the various Lazarus widgetsets into different directories
* ... any other things you may think of ...
all with a si
On Mon, 24 Jul 2023, Kirinn via fpc-devel wrote:
Hi,
A "unicode" RTL is of course great for targeting legacy Windows platforms,
but for those of us on Linux, UTF-8 is the way.
It is not only for legacy windows platforms.
The target platform is secondary.
What to use depends more on your c
Hi,
A "unicode" RTL is of course great for targeting legacy Windows platforms,
but for those of us on Linux, UTF-8 is the way. To this end, it would be
helpful to add a paragraph on the wiki page underlining how to retain the
single-byte RTL; or, if no user action is necessary, mention that, to se
On Fri, 13 Jan 2023 11:25:56 +0100
Tomas Hajny via fpc-devel wrote:
>[...]
> > My /etc/fpc.cfg contains:
> >
> > # searchpath for units and other system dependent things
> > -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
> > -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
> > -Fu/usr/lib/fpc/$fpcve
On Fri, 13 Jan 2023, Tomas Hajny via fpc-devel wrote:
On 2023-01-13 11:22, Mattias Gaertner via fpc-devel wrote:
On Sun, 8 Jan 2023 08:46:37 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
[...]
Should have been
make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler
This d
On Fri, 13 Jan 2023, Mattias Gaertner via fpc-devel wrote:
On Sun, 8 Jan 2023 08:46:37 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
[...]
Should have been
make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler
This does not install the new compiler, so I used the compile
On 2023-01-13 11:22, Mattias Gaertner via fpc-devel wrote:
On Sun, 8 Jan 2023 08:46:37 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
[...]
Should have been
make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler
This does not install the new compiler, so I used the compiler/pp
On Sun, 8 Jan 2023 08:46:37 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
>[...]
> Should have been
>
> make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler
This does not install the new compiler, so I used the compiler/ppcx64
exe directly to compile a program.
I see in the -v
Michael Van Canneyt via fpc-devel wrote:
Seems my warning to prevent heart attacks was on its place but maybe not
entirely effective :-)
Relax, no-one will force you to use UTF16.
But there are people that do not have the luxury of choice, and we should
be kind to them too.
OK. It reminds
On Sun, 8 Jan 2023, Mattias Gaertner via fpc-devel wrote:
On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
[...]
- to create a Unicode RTL, in the rtl directory do a
make clean all SUB_TARGET=unicodertl PP=path/to/the/new/compiler
- if that worked, you can
On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
>[...]
> - to create a Unicode RTL, in the rtl directory do a
>
> make clean all SUB_TARGET=unicodertl PP=path/to/the/new/compiler
>
> - if that worked, you can try then a
>
> make install SUB_TARGET=unicodertl
I
On Sat, 7 Jan 2023, Mattias Gaertner via fpc-devel wrote:
On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
[...]
- to create a Unicode RTL, in the rtl directory do a
make clean all SUB_TARGET=unicodertl PP=path/to/the/new/compiler
The "make clean" deletes
On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
>[...]
> - to create a Unicode RTL, in the rtl directory do a
>
> make clean all SUB_TARGET=unicodertl PP=path/to/the/new/compiler
The "make clean" deletes the new compiler.
Storing the compiler/ppcx64 somewhere e
Michael Van Canneyt via fpc-devel schrieb
am Sa., 7. Jan. 2023, 12:46:
>
>
> On Sat, 7 Jan 2023, Mattias Gaertner via fpc-devel wrote:
>
> > On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
> > Michael Van Canneyt via fpc-devel
> > wrote:
> >
> >> [...]
> >> For those that wish to help in testing:
> >>
>
On Sat, 7 Jan 2023, Mattias Gaertner via fpc-devel wrote:
On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
[...]
For those that wish to help in testing:
- Update your git clone
I used a fresh clone.
- switch to branch unicodertl.
I used git checkout u
> Relax, no-one will force you to use UTF16.
>
> But there are people that do not have the luxury of choice, and we should
> be kind to them too.
I really appreciate this mindset. Thank you.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
h
On Fri, 6 Jan 2023 18:05:43 +0100 (CET)
Michael Van Canneyt via fpc-devel
wrote:
>[...]
> For those that wish to help in testing:
>
> - Update your git clone
I used a fresh clone.
> - switch to branch unicodertl.
I used git checkout unicodertl
> - in the toplevel FPC directory, do a
>
> ma
> Michael Van Canneyt via fpc-devel wrote:
>
>> - String = UnicodeString, Char=WideChar
>
> UnicodeString ? ? I don't know what that is supposed to be. We have UCS-2,
> UCS-4, UTF-16 and UTF-8 Some marketing people, not understanding anything
> about computers, talk about "Unicode" to mean "UT
On Fri, 6 Jan 2023, Adriaan van Os via fpc-devel wrote:
Michael Van Canneyt via fpc-devel wrote:
- String = UnicodeString, Char=WideChar
UnicodeString ? ? I don't know what that is supposed to be. We have UCS-2,
UCS-4, UTF-16 and UTF-8 Some marketing people, not understanding anything
a
On 6-1-2023 20:36, Adriaan van Os via fpc-devel wrote:
Michael Van Canneyt via fpc-devel wrote:
- String = UnicodeString, Char=WideChar
UnicodeString ? ? I don't know what that is supposed to be.
It is named after Microsofts use of the word unicode. Which was
originally UCS2, but morphed
On 06/01/2023 20:36, Adriaan van Os via fpc-devel wrote:
Michael Van Canneyt via fpc-devel wrote:
- String = UnicodeString, Char=WideChar
UnicodeString ? ? I don't know what that is supposed to be. We have
UCS-2, UCS-4, UTF-16 and UTF-8 Some marketing people, not understanding
anything abou
Michael Van Canneyt via fpc-devel wrote:
- String = UnicodeString, Char=WideChar
UnicodeString ? ? I don't know what that is supposed to be. We have UCS-2, UCS-4, UTF-16 and UTF-8
Some marketing people, not understanding anything about computers, talk about "Unicode" to mean
"UTF-16-treated-
> Who knows the future?
> Maybe in 10 years 16bit non multi 'byte' encoding is sufficient for all
> remaining languages.
> Or maybe 32bit encodings will become the default.
the unix and web worlds are going utf-8 the ms and java worlds are going
utf-16 both are variable width
Op Thu, 17 Nov 2005, schreef Felipe Monteiro de Carvalho:
> On 11/17/05, Daniël Mantione <[EMAIL PROTECTED]> wrote:
> > IMHO the "hope" is that if there is a Tnativestring, people will
> > start to design their libraries using Tnativestring, which will result in
> > that those libraries can be c
- Original Message -
From: "Felipe Monteiro de Carvalho" <[EMAIL PROTECTED]>
On 11/17/05, Mattias Gaertner <[EMAIL PROTECTED]> wrote:
> Speaking for lazarus: we want to support the whole unicode and UTF8 is
> the
> easiest to achieve that.
I particulary like this solution.
* It doe
On 11/17/05, Daniël Mantione <[EMAIL PROTECTED]> wrote:
> IMHO the "hope" is that if there is a Tnativestring, people will
> start to design their libraries using Tnativestring, which will result in
> that those libraries can be compiled for 8 of 16 bit strings.
This does not fix everything. Some
On 11/17/05, Mattias Gaertner <[EMAIL PROTECTED]> wrote:
> Speaking for lazarus: we want to support the whole unicode and UTF8 is the
> easiest to achieve that.
I particulary like this solution.
* It doesn´t break existing code
* It makes it easy to make a program unicode. Just change the encodin
Op Thu, 17 Nov 2005, schreef Yury Sidorov:
> I agree. There is no need to make existing RTL APIs unicode aware, because
> there will be no compatibility with existing apps in any case.
> So how about to add alternative unicode versions of RTL APIs via overloading
> or via adding some suffix (eg.
From: "Marco van de Voort" <[EMAIL PROTECTED]>
Unicode RTL is needed for people who want to develop unicode applications
from the beginning. In such case the developer will be aware of unicode
and
will write correct code.
All correct, BUT
1) it is not Unicode RTL but Unicode FPC/Lazarus.
2)
Op Thu, 17 Nov 2005, schreef Mattias Gaertner:
> On Thu, 17 Nov 2005 11:31:45 +0100
> "Dr. Karl-Michael Schindler" <[EMAIL PROTECTED]> wrote:
>
> > Hi
> >
> > Following this discussion, I want to throw in my 2 cents as well:
> > On a real long term (like 5 or 10 years from now), the solution
> From: "Marco van de Voort" <[EMAIL PROTECTED]>
> > Nothing. You can't. It was meant to illustrate that there is more to it
> > than
> > simply declaring an "tbasicstring" or so alias and fixing some internal
> > routines. It will "just" mean full checking and ifdeffing of/in every part
> > of th
On Thu, 17 Nov 2005 11:31:45 +0100
"Dr. Karl-Michael Schindler" <[EMAIL PROTECTED]> wrote:
> Hi
>
> Following this discussion, I want to throw in my 2 cents as well:
> On a real long term (like 5 or 10 years from now), the solution
> should be as "clean" as possible with as little awkward par
From: "Marco van de Voort" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > Dani?l Mantione <[EMAIL PROTECTED]> wrote:
>
> > > > > In other words, you still need to duplicate an awfull lot of
> > > > > code.
> > > >
> > > > That is the same for 8bit and widestring.
> > >
>
Hi
Following this discussion, I want to throw in my 2 cents as well:
On a real long term (like 5 or 10 years from now), the solution
should be as "clean" as possible with as little awkward parts because
of backward compatibility. This favors of a more separate solution
with a compatibility
On Thu, 17 Nov 2005 11:04:01 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > [EMAIL PROTECTED] (Marco van de Voort) wrote:
> >
> > > > Dani?l Mantione <[EMAIL PROTECTED]> wrote:
> > >
> > > > > > > In other words, you still need to duplicate an awfull lot of
> > > > > > > code.
> >
Op Thu, 17 Nov 2005, schreef Florian Klaempfl:
> This makes no sense. If such a thing is done, the encoding of the actually
> used
> mysql db must be taken into care.
Nothing is fun with charsets... The above just demonstrates the
idea. File system encoding would be another of those wild west
> [EMAIL PROTECTED] (Marco van de Voort) wrote:
>
> > > Dani?l Mantione <[EMAIL PROTECTED]> wrote:
> >
> > > > > > In other words, you still need to duplicate an awfull lot of code.
> > > > >
> > > > > That is the same for 8bit and widestring.
> > > >
> > > > No, that is not true. There would b
Daniël Mantione wrote:
>
> Op Thu, 17 Nov 2005, schreef Daniël Mantione:
>
>
E.g. accessing mysql is now done with pchar(ansistring)
>>>
>>>And they should be replaced by what?
>>
>>Pchar(Tnativestring(widestring_variable));
>
>
> Apparently I got too little sleep or something tonight :)
Op Thu, 17 Nov 2005, schreef Daniël Mantione:
> > > E.g. accessing mysql is now done with pchar(ansistring)
> >
> > And they should be replaced by what?
>
> Pchar(Tnativestring(widestring_variable));
Apparently I got too little sleep or something tonight :) It would be
this:
Pchar(ansistrin
Op Thu, 17 Nov 2005, schreef Mattias Gaertner:
> On Thu, 17 Nov 2005 10:27:08 +0100 (CET)
> [EMAIL PROTECTED] (Marco van de Voort) wrote:
>
> > > Dani?l Mantione <[EMAIL PROTECTED]> wrote:
> >
> > > > > > In other words, you still need to duplicate an awfull lot of code.
> > > > >
> > > > > T
On Thu, 17 Nov 2005 10:27:08 +0100 (CET)
[EMAIL PROTECTED] (Marco van de Voort) wrote:
> > Dani?l Mantione <[EMAIL PROTECTED]> wrote:
>
> > > > > In other words, you still need to duplicate an awfull lot of code.
> > > >
> > > > That is the same for 8bit and widestring.
> > >
> > > No, that is
> Dani?l Mantione <[EMAIL PROTECTED]> wrote:
> > > > In other words, you still need to duplicate an awfull lot of code.
> > >
> > > That is the same for 8bit and widestring.
> >
> > No, that is not true. There would be two rtls based on the same code.
>
> Can you give some examples, what parts
On Thu, 17 Nov 2005 08:36:27 +0100 (CET)
Daniël Mantione <[EMAIL PROTECTED]> wrote:
>
>
> Op Wed, 16 Nov 2005, schreef Mattias Gaertner:
>
> > I don't understand, why you connect UTF8 with 'ignorant of MBCS'.
> > UCS-2 can be used as ignorant as UTF8.
> > Even UCS-4 and UTF32 will not solve all
Op Wed, 16 Nov 2005, schreef Mattias Gaertner:
> I don't understand, why you connect UTF8 with 'ignorant of MBCS'.
> UCS-2 can be used as ignorant as UTF8.
> Even UCS-4 and UTF32 will not solve all problems. Think about arabic RTL.
Sure. I am not against UTF-8 or something (if you got that impr
> *sigh* Yes, what he says is correct. Now to do something with
> strings. I.e. reverse them, or any other operation that needs to split
> the string into pieces.
reversing a string properly requires a very deep understanding of unicode
and huge lookup tables (reversing the code point order will b
Op Wed, 16 Nov 2005, schreef Florian Klaempfl:
> Daniël Mantione wrote:
>
> >
> > Op Wed, 16 Nov 2005, schreef peter green:
> >
> >
> >>>pos('ë','Daniël');
> >>>
> >>>... has a different implementation for utf-8 and 8-bit code pages.
> >>
> >>one little desgin feature of utf-8 is that is was
On Wed, 16 Nov 2005 17:25:29 +0100 (CET)
Daniël Mantione <[EMAIL PROTECTED]> wrote:
>
>
> Op Wed, 16 Nov 2005, schreef Tomas Hajny:
>
> > You're right that strings are used everywhere, but I don't think that
> > this really means that you need to add special support for widestrings
> > everywhe
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Daniël
> Mantione
> Sent: 16 November 2005 21:58
> To: FPC developers' list
> Subject: RE: [fpc-devel] Unicode RTL
>
>
> Op Wed, 16 Nov 2005, schreef peter
Daniël Mantione wrote:
>
> Op Wed, 16 Nov 2005, schreef peter green:
>
>
>>>pos('ë','Daniël');
>>>
>>>... has a different implementation for utf-8 and 8-bit code pages.
>>
>>one little desgin feature of utf-8 is that is was carefully designed to be
>>friendly to byte-orientated code. No special
Op Wed, 16 Nov 2005, schreef peter green:
>
> > pos('ë','Daniël');
> >
> > ... has a different implementation for utf-8 and 8-bit code pages.
> one little desgin feature of utf-8 is that is was carefully designed to be
> friendly to byte-orientated code. No special precautions are needed for
>
> pos('ë','Daniël');
>
> ... has a different implementation for utf-8 and 8-bit code pages.
one little desgin feature of utf-8 is that is was carefully designed to be
friendly to byte-orientated code. No special precautions are needed for
substring matching in utf-8!
_
Op Wed, 16 Nov 2005, schreef Micha Nelissen:
> On Wed, 16 Nov 2005 13:38:43 +0100 (CET)
> Daniël Mantione <[EMAIL PROTECTED]> wrote:
>
> > Op Wed, 16 Nov 2005, schreef Micha Nelissen:
> >
> > > Why not use ansistrings with UTF-8 ?
> >
> > Because then you will have to modify routines like pos
On Wed, 16 Nov 2005 13:38:43 +0100 (CET)
Daniël Mantione <[EMAIL PROTECTED]> wrote:
> Op Wed, 16 Nov 2005, schreef Micha Nelissen:
>
> > Why not use ansistrings with UTF-8 ?
>
> Because then you will have to modify routines like pos, insert, delete.
> Since that is not possible, you would get a
Op Wed, 16 Nov 2005, schreef Tomas Hajny:
> You're right that strings are used everywhere, but I don't think that this
> really means that you need to add special support for widestrings
> everywhere. In many places you can pass a DBCS/MBCS string to it today
> (e.g. encoded using UTF-8) and it
On Wednesday 16 November 2005 13:57, Florian Klaempfl wrote:
> Daniël Mantione wrote:
> > Op Wed, 16 Nov 2005, schreef Vincent Snijders:
> >>Daniël Mantione wrote:
> >>>What should be done on Linux/FreeBSD/MacOS is still unknown to me, it is
> >>>a wild west, but likely something similar, internall
Marco van de Voort napsal(a):
>> >> >
>> >> > ... has a different implementation for utf-8 and 8-bit code pages.
>> >>
>> >> Why? With utf-8 a string is searched, with 8-bit cp one char. No
>> other
>> >> char/sequence of char other than ? can generate the byte sequence
>> >> representing ?
>> >
>>
> >> >
> >> > ... has a different implementation for utf-8 and 8-bit code pages.
> >>
> >> Why? With utf-8 a string is searched, with 8-bit cp one char. No other
> >> char/sequence of char other than ? can generate the byte sequence
> >> representing ?
> >
> > const s : 'Dani?l';
> >
> > var accent
Marco van de Voort napsal(a):
>> Dani?l Mantione wrote:
>> > pos('?','Dani?l');
>> >
>> > ... has a different implementation for utf-8 and 8-bit code pages.
>>
>> Why? With utf-8 a string is searched, with 8-bit cp one char. No other
>> char/sequence of char other than ? can generate the byte seque
Florian Klaempfl wrote:
> Felipe Monteiro de Carvalho wrote:
>> On 11/16/05, Daniël Mantione <[EMAIL PROTECTED]> wrote:
>>
>>>I know, I'm all for abolishing Chinese (and perhaps Korean), the only
>>>language(s) that absolutely cannot be written in with an 8 byte
>>> code.
>>
>>
>> why not remov
Daniël Mantione wrote:
> Op Wed, 16 Nov 2005, schreef Tomas Hajny:
>
>> Big overhead (double maintenance efforts for all targets supporting this
>> schisma). :-( I'd say it's better to successively identify the weak
>> points
>> and address these case by case.
>
> I know, I'm all for abolishing Chi
> Dani?l Mantione wrote:
> > pos('?','Dani?l');
> >
> > ... has a different implementation for utf-8 and 8-bit code pages.
>
> Why? With utf-8 a string is searched, with 8-bit cp one char. No other
> char/sequence of char other than ? can generate the byte sequence
> representing ?
const s : 'Da
Daniël Mantione wrote:
>
> Op Wed, 16 Nov 2005, schreef Florian Klaempfl:
>
>
>>Daniël Mantione wrote:
>>
>>>Op Wed, 16 Nov 2005, schreef Micha Nelissen:
>>>
>>>
>>>
Daniël Mantione wrote:
>To be short, Juras B. wants to add a Unicode Win32 target, so in the
>standard RTL
> Dani?l Mantione wrote:
y> >
> >
> > Because then you will have to modify routines like pos, insert, delete.
> > Since that is not possible, you would get a pos_utf8, insert_utf8, etc.
>
> No, why? When working with utf-8 strings, you don't use character positions.
That's pretty much only whe
Op Wed, 16 Nov 2005, schreef Florian Klaempfl:
> Daniël Mantione wrote:
> >
> > Op Wed, 16 Nov 2005, schreef Micha Nelissen:
> >
> >
> >>Daniël Mantione wrote:
> >>
> >>>To be short, Juras B. wants to add a Unicode Win32 target, so in the
> >>>standard RTL things like Tlist etc. use ansistrin
Daniël Mantione wrote:
>
> Op Wed, 16 Nov 2005, schreef Vincent Snijders:
>
>
>>Daniël Mantione wrote:
>>
>>>
>>>What should be done on Linux/FreeBSD/MacOS is still unknown to me, it is
>>>a wild west, but likely something similar, internally a widestring rtl is
>>>used that converts to the rig
Felipe Monteiro de Carvalho wrote:
> On 11/16/05, Daniël Mantione <[EMAIL PROTECTED]> wrote:
>
>>I know, I'm all for abolishing Chinese (and perhaps Korean), the only
>>language(s) that absolutely cannot be written in with an 8 byte code.
>
>
> why not remove all languages that do not fit A
Daniël Mantione wrote:
>
> Op Wed, 16 Nov 2005, schreef Micha Nelissen:
>
>
>>Daniël Mantione wrote:
>>
>>>To be short, Juras B. wants to add a Unicode Win32 target, so in the
>>>standard RTL things like Tlist etc. use ansistrings, while in the Unicode
>>>RTL they use widestrings.
>>
>>Why not u
On 11/16/05, Daniël Mantione <[EMAIL PROTECTED]> wrote:
> I know, I'm all for abolishing Chinese (and perhaps Korean), the only
> language(s) that absolutely cannot be written in with an 8 byte code.
why not remove all languages that do not fit ASCII next???
> Now there are several solutions:
Daniël Mantione wrote:
>
> Op Wed, 16 Nov 2005, schreef Tomas Hajny:
>
>
>>Big overhead (double maintenance efforts for all targets supporting this
>>schisma). :-( I'd say it's better to successively identify the weak points
>>and address these case by case.
>
Yes.
>
> I know, I'm all for a
On 16 nov 2005, at 13:45, Marco van de Voort wrote:
One could argue that codepoints over 40k are rarely used, but if we
really
do major work like this, it should be done good. And it should be a
good
compromise for all OSes, not just windows.
Afaik, on Mac OS X internally pretty much ever
> Op Wed, 16 Nov 2005, schreef Micha Nelissen:
>
> > Dani?l Mantione wrote:
> > > To be short, Juras B. wants to add a Unicode Win32 target, so in the
> > > standard RTL things like Tlist etc. use ansistrings, while in the Unicode
> > > RTL they use widestrings.
> >
> > Why not use ansistrings wi
Op Wed, 16 Nov 2005, schreef Vincent Snijders:
> Daniël Mantione wrote:
> >
> >
> > What should be done on Linux/FreeBSD/MacOS is still unknown to me, it is
> > a wild west, but likely something similar, internally a widestring rtl is
> > used that converts to the right encoding when communica
Op Wed, 16 Nov 2005, schreef Micha Nelissen:
> Daniël Mantione wrote:
> > To be short, Juras B. wants to add a Unicode Win32 target, so in the
> > standard RTL things like Tlist etc. use ansistrings, while in the Unicode
> > RTL they use widestrings.
>
> Why not use ansistrings with UTF-8 ?
Be
Op Wed, 16 Nov 2005, schreef Tomas Hajny:
> Big overhead (double maintenance efforts for all targets supporting this
> schisma). :-( I'd say it's better to successively identify the weak points
> and address these case by case.
I know, I'm all for abolishing Chinese (and perhaps Korean), the on
Daniël Mantione napsal(a):
> Hi,
>
> Please check this discussion:
>
> http://community.freepascal.org:1/bboards/message?message_id=172880&forum_id=24092
>
> Short summary:
> * Many places in the rtl use single character strings, i.e. ansistrings.
> * To make them Unicode proof they need to be
> > allowing to reuse the OS independant code.
> >
> > However this doesn't work fully this way, since unicode internally also hits
> > OS-independant code hard. IOW the separate target only solves the windows
> > unit defaults.
>
> Indeed. What is proposed is that the system independent RTL use
Daniël Mantione wrote:
To be short, Juras B. wants to add a Unicode Win32 target, so in the
standard RTL things like Tlist etc. use ansistrings, while in the Unicode
RTL they use widestrings.
Why not use ansistrings with UTF-8 ?
IMHO this is indeed a good solution, but one with consequences.
Daniël Mantione wrote:
What should be done on Linux/FreeBSD/MacOS is still unknown to me, it is
a wild west, but likely something similar, internally a widestring rtl is used that
converts to the right encoding when communicating externally.
Does that mean string operations will be twice a
Op Wed, 16 Nov 2005, schreef Marco van de Voort:
> > Please check this discussion:
> >
> > http://community.freepascal.org:1/bboards/message?message_id=172880&forum_id=24092
> >
> > Short summary:
> > * Many places in the rtl use single character strings, i.e. ansistrings.
> > * To make th
> Please check this discussion:
>
> http://community.freepascal.org:1/bboards/message?message_id=172880&forum_id=24092
>
> Short summary:
> * Many places in the rtl use single character strings, i.e. ansistrings.
> * To make them Unicode proof they need to be changed into wide strings.
> * Bu
83 matches
Mail list logo
