Re: [Lazarus] non Unicodode application

2016-02-15 Thread Michael Schnell
On 02/15/2016 12:03 PM, Juha Manninen wrote: The real complexity of Unicode is beyond encodings Yep.This I learned from the discussions. E.g. even with a technically perfect UTF string implementation, the problem that exactly the same printable text can be encoded in multiple ways can't be

Re: [Lazarus] non Unicodode application

2016-02-15 Thread Juha Manninen
On Mon, Feb 15, 2016 at 12:20 PM, Michael Schnell wrote: > Sorry I did not intend to express any negative attitude, but on the > contrary am very happy that Lazarus/fpc can provide exactly that > functionality (8 bit Strings - including TStrins, pos , etc - in a 64 Bit >

Re: [Lazarus] non Unicodode application

2016-02-15 Thread Michael Schnell
On 02/12/2016 06:13 PM, Juha Manninen wrote: On Fri, Feb 12, 2016 at 6:52 PM, Michael Schnell wrote: I think that it is *very* desirable to provide configuration options to provide full backwards compatibility (while still allow to use as many of the new features as

[Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
Hi Experts, A friend of mine wants to port an application from Delphi 7 to a be a Lazarus 64 Bit Windows application. This (huge) application only features a very limited GIU, but uses strings lot for "uncoded" characters, going in and out via TCP/IP. Any automatic type conversion would

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Kostas Michalopoulos
I suppose a more clear question would be... is it possible for now and the foreseeable future to have FPC (3.0+, not just 2.x) make the "string" type (not rawbytestring or anything else) behave as it was behaving always since the beginning of time without any source code changes but (say) via

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Van Canneyt
On Fri, 12 Feb 2016, Michael Schnell wrote: On 02/12/2016 03:16 PM, Michael Van Canneyt wrote: On Fri, 12 Feb 2016, Michael Schnell wrote: On 02/12/2016 02:38 PM, Michael Van Canneyt wrote: Just use RawByteString as stringtype for all parameters and variables in calls where you don't

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Juha Manninen
On Fri, Feb 12, 2016 at 4:18 PM, Michael Schnell wrote: > Now a friend of mine is faced by a similar task. But here he wants to keep a > (small) GUI and he does not want to go for Linux but for 64 Bit. Both Delphi and FPC now support 64-bit. I don't know how that relates to

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Juha Manninen
On Fri, Feb 12, 2016 at 3:25 PM, Michael Schnell wrote: > Any automatic type conversion would kill the application. > [...] > will this be possible with future versions of Lazarus ,as well ? I guess you mean automatic encoding conversion for strings. (?) The automatic

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 02:38 PM, Michael Van Canneyt wrote: Just use RawByteString as stringtype for all parameters and variables in calls where you don't want code page conversions to occur. This would mean rewriting the complete application. This obviously is not desired . -Michael --

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 03:16 PM, Michael Van Canneyt wrote: Tish... {$define String:=RawByteString} and you are done. I'll let him know... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Graeme Geldenhuys
On 2016-02-12 14:16, Michael Van Canneyt wrote: > {$define String:=RawByteString} > > and you are done. Awesome! FPC:1 Delphi: 0 :) Regards, G. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 03:16 PM, Michael Van Canneyt wrote: On Fri, 12 Feb 2016, Michael Schnell wrote: On 02/12/2016 02:38 PM, Michael Van Canneyt wrote: Just use RawByteString as stringtype for all parameters and variables in calls where you don't want code page conversions to occur. This

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 02:57 PM, Juha Manninen wrote: And yes, often the same arguments were repeated by the same person who started this thread. At the time I did those researches and discussions, my colleagues here were interested in porting their Delphi application to Linux using Lazarus and I

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Van Canneyt
On Fri, 12 Feb 2016, Michael Schnell wrote: Hi Experts, A friend of mine wants to port an application from Delphi 7 to a be a Lazarus 64 Bit Windows application. This (huge) application only features a very limited GIU, but uses strings lot for "uncoded" characters, going in and out via

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Van Canneyt
On Fri, 12 Feb 2016, Michael Schnell wrote: On 02/12/2016 02:38 PM, Michael Van Canneyt wrote: Just use RawByteString as stringtype for all parameters and variables in calls where you don't want code page conversions to occur. This would mean rewriting the complete application. This

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Juha Manninen
On Fri, Feb 12, 2016 at 3:38 PM, Michael Van Canneyt wrote: > Just use RawByteString as stringtype for all parameters and variables > in calls where you don't want code page conversions to occur. The compiler > will not touch the codepage then. Ok, true. That works, too.

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Mattias Gaertner
On Fri, 12 Feb 2016 15:38:49 +0200 Juha Manninen wrote: > On Fri, Feb 12, 2016 at 3:25 PM, Michael Schnell wrote: > > Any automatic type conversion would kill the application. > > [...] > > will this be possible with future versions of Lazarus ,as

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 05:37 PM, Dmitry Boyarintsev wrote: In this particular case (of porting Delphi 7 code straight to FPC 3.0.0) is a matter of backward compatibility. Yep. Not only to D7, but also to legacy fpc and Lazarus versions, that (as we all know) were modeled after D7 (and friends). I

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Juha Manninen
On Fri, Feb 12, 2016 at 6:52 PM, Michael Schnell wrote: > I think that it is *very* desirable to provide configuration options to > provide full backwards compatibility (while still allow to use as many of > the new features as possible when explicitly writing coding for

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
This does sound good. :-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 05:23 PM, Mattias Gaertner wrote: If your friend use string literals in Delphi they are encoded in system code page. Here might be some traps. He will easily be able to handle this . Thanks a lot ! -Michael -- ___ Lazarus mailing

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 03:54 PM, Juha Manninen wrote: Sure there is hope. See the new UTF-8 support: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus I'll let him know... And of course I will take read this myself, too. In fact he does not want "Better_Unicode_Support" but

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 03:54 PM, Juha Manninen wrote: Both Delphi and FPC now support 64-bit. I don't know how that relates to dynamic String encoding. . http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus AFAIK, any 64 bit Delphi forces UTF-16 Unicode and cant do what is described in

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 03:54 PM, Juha Manninen wrote: Sure there is hope. See the new UTF-8 support: http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus This page says: "This page covers Unicode support in Lazarus programs (console or server, no GUI) and applications (GUI with LCL) using

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Mattias Gaertner
On Fri, 12 Feb 2016 16:41:23 +0100 Michael Schnell wrote: > On 02/12/2016 03:54 PM, Juha Manninen wrote: > > Sure there is hope. See the new UTF-8 support: > >http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus > > > This page says: > > "This page covers Unicode

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Dmitry Boyarintsev
On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt wrote: > {$define String:=RawByteString} > > and you are done. > How to achieve the same effect from command line? thanks, Dmitry -- ___ Lazarus mailing list

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Mattias Gaertner
On Fri, 12 Feb 2016 17:16:29 +0100 (CET) Michael Van Canneyt wrote: >[...] > >> {$define String:=RawByteString} >[...] > Type >T = Type Ansistring(850); AFAIK this was introduced with Delphi 2009. Not available in Delphi 7. Mattias --

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Mattias Gaertner
On Fri, 12 Feb 2016 15:16:38 +0100 (CET) Michael Van Canneyt wrote: >[...] > {$define String:=RawByteString} > > and you are done. Won't compile when calling RTL functions with var parameters. I fail to see why RawByteString should do less conversions than using

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Van Canneyt
On Fri, 12 Feb 2016, Mattias Gaertner wrote: On Fri, 12 Feb 2016 15:16:38 +0100 (CET) Michael Van Canneyt wrote: [...] {$define String:=RawByteString} and you are done. Won't compile when calling RTL functions with var parameters. I fail to see why RawByteString

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 03:55 PM, Mattias Gaertner wrote: True, although the wording might be misleading. FPC 3.0+ does not arbitrarily change encoding of strings. That's why the LCL can use UTF-8 in AnsiStrings even without the new UTF-8 mode. It then works pretty similar to FPC 2.6.4. This is exactly

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Schnell
On 02/12/2016 03:53 PM, Mattias Gaertner wrote: Your friend can use the LCL for the GUI with disabled UTF-8 mode. Sounds great ! He has to check (convert) the strings between his TCP/IP code and the LCL controls (e.g. UTF8ToSys). As he has only a small GUI this should be easy. No problem.

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Mattias Gaertner
On Fri, 12 Feb 2016 16:53:12 +0100 Michael Schnell wrote: >[...] > > even without the new UTF-8 mode. > How to set this mode when compiling with Lazarus ? See here http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode > What mode do you think is more

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Dmitry Boyarintsev
On Fri, Feb 12, 2016 at 11:24 AM, Sven Barth wrote: > Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" < > skalogryz.li...@gmail.com>: > > > > On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt < > mich...@freepascal.org> wrote: > >> > >> {$define

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Sven Barth
Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" : > > On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt < mich...@freepascal.org> wrote: >> >> {$define String:=RawByteString} >> >> and you are done. > > > How to achieve the same effect from command line? Just

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Michael Van Canneyt
On Fri, 12 Feb 2016, Sven Barth wrote: Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" wrote: {$define String:=RawByteString} and you are done. How to achieve the same effect

Re: [Lazarus] non Unicodode application

2016-02-12 Thread Sven Barth
Am 12.02.2016 17:37 schrieb "Dmitry Boyarintsev" : > > On Fri, Feb 12, 2016 at 11:24 AM, Sven Barth wrote: >> >> Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" < skalogryz.li...@gmail.com>: >> > >> > On Fri, Feb 12, 2016 at 9:16 AM,