On 7-2-2012 12:20, Marco van de Voort wrote:
In our previous episode, Hans-Peter Diettrich said:
That depends on decisions still to be made. If we also support 1-byte
RTL, it will still be on the level of winNT. But I do think that a
win9x vs winnt split is unavoidable in time. Specially since
Marco van de Voort wrote:
In our previous episode, Hans-Peter Diettrich said:
IMO a more radical solution is desireable, WRT Win9x. Did anybody test
already, how FPC/Lazarus apps behave on such a system, which does not
support themes etc., and does not even support Unicode without system
updat
On Wed, Feb 8, 2012 at 5:28 PM, Craig Peterson
wrote:
> The TNT Unicode controls did it the way you're suggesting, by
> deciding at runtime, so it is possible, but it would overly complicate
> the RTL code for an increasingly irrelevant platform.
We are big boys, I think that we can handle the i
On 2/8/2012 9:21 AM, Felipe Monteiro de Carvalho wrote:
> Windows9x has all W functions,
No it does not. The Microsoft layer for Unicode is a redistributable
DLL that provides W versions of functions and calls the A versions
internally. Win9x does export a bunch of W functions so you can link to
On Wed, Feb 8, 2012 at 4:00 PM, Hans-Peter Diettrich
wrote:
> They *do* the string conversion, necessary for calling the "native"
> functions internally. In Win9x the W functions convert strings into Ansi, on
> NT the A versions convert strings into WideString. So what's the real
> benefit of cond
Felipe Monteiro de Carvalho schrieb:
2012/2/8 Tomas Hajny :
If your intention was to keep the programs
working with Win9x, this won't help because the program containing
unresolved imports wouldn't start anyway. Is there any other reason?
Windows9x has all W functions,
Right. Other (post-9x)
On Tue, Feb 7, 2012 at 12:07 PM, Marco van de Voort wrote:
> Note that this might sound useful now ansistring without codepage is still
> the default string, but if the default string type changes, this is not
> really useful.
You cannot change the default string type without killing the Ansi RTL
2012/2/8 Tomas Hajny :
> If your intention was to keep the programs
> working with Win9x, this won't help because the program containing
> unresolved imports wouldn't start anyway. Is there any other reason?
Windows9x has all W functions, Microsoft added them as stubs to avoid
this kind of problem
On Mon, February 6, 2012 17:39, Felipe Monteiro de Carvalho wrote:
> Hello,
>
> SysUtils for Windows utilizes only A Windows APIs, while it could use
> W APIs in Windows NT. The attached patch starts correcting improving
> the situation.
>
> Advantages of the patch:
>
> * Allows for unicode file na
On 07.02.2012 18:01, Felipe Monteiro de Carvalho wrote:
Stay tunned for the next chapters of the Unicode wars =)
Here we agree... ;) *fetches popcorn*
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
In our previous episode, Hans-Peter Diettrich said:
> IMO a more radical solution is desireable, WRT Win9x. Did anybody test
> already, how FPC/Lazarus apps behave on such a system, which does not
> support themes etc., and does not even support Unicode without system
> updates?
>
> I'd split t
In our previous episode, Felipe Monteiro de Carvalho said:
> No, it will not use UTF-8 by default because that would break
> compatibility. It will use the system encoding by default and you can
> use SetMultiByteConversionCodePage to change it to use UTF-8.
Note that this might sound useful now a
Michael Van Canneyt schrieb:
As you know, we are very keen on backwards compatibility.
ACK.
Are you sure that if a AnsiString filename which contains
codepage-specific characters is used to open a file, it will still open
the same file after this patch is applied ?
Win32 filesystems store
Felipe Monteiro de Carvalho schrieb:
Hello,
SysUtils for Windows utilizes only A Windows APIs, while it could use
W APIs in Windows NT. The attached patch starts correcting improving
the situation.
Advantages of the patch:
* Allows for unicode file names in TStringList.LoadFromFile if you
inst
On Tue, 7 Feb 2012, Felipe Monteiro de Carvalho wrote:
On Mon, Feb 6, 2012 at 9:35 PM, Sergei Gorelkin wrote:
So, this is basically a first step of locking Windows RTL to use utf-8 by
default
No, it will not use UTF-8 by default because that would break
compatibility. It will use the syste
On Mon, Feb 6, 2012 at 9:35 PM, Sergei Gorelkin wrote:
> So, this is basically a first step of locking Windows RTL to use utf-8 by
> default
No, it will not use UTF-8 by default because that would break
compatibility. It will use the system encoding by default and you can
use SetMultiByteConversi
On 6-2-2012 22:14, Sergei Gorelkin wrote:
under 10KBytes
Any decent code under 10k is interesting
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/
06.02.2012 23:45, Marco van de Voort пишет:
In our previous episode, Felipe Monteiro de Carvalho said:
1> makes it impossible to support Unicode and support Windows 9x at
the same time, but I doubt that Free Pascal wants to drop Windows 9x
support (even if it is obsolete).
Afaik we already h
Of course, KOL is a framework, not a compiler.
I merely want to state it can be done in a proper way.
smime.p7s
Description: S/MIME Cryptographic Signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/l
On 6-2-2012 21:35, Sergei Gorelkin wrote:
06.02.2012 20:39, Felipe Monteiro de Carvalho пишет:
So, this is basically a first step of locking Windows RTL to use utf-8
by default and reducing chances it ever will call 'W' API without
conversions?
That is another point that worries me too. Windo
06.02.2012 20:39, Felipe Monteiro de Carvalho пишет:
Hello,
SysUtils for Windows utilizes only A Windows APIs, while it could use
W APIs in Windows NT. The attached patch starts correcting improving
the situation.
Advantages of the patch:
* Allows for unicode file names in TStringList.LoadFrom
In our previous episode, Felipe Monteiro de Carvalho said:
> 1> makes it impossible to support Unicode and support Windows 9x at
> the same time, but I doubt that Free Pascal wants to drop Windows 9x
> support (even if it is obsolete).
Afaik we already have. Recent versions require patches for wi
On 06.02.2012 20:20, Thaddy wrote:
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote:
The Microsoft way is not the same as the Free Pascal way. We are not
required to immitate them when implementing our routines. The
Microsoft way has nasty side effects: 1> makes it impossible to
support Unic
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote:
The Microsoft way is not the same as the Free Pascal way. We are not
required to immitate them when implementing our routines. The
Microsoft way has nasty side effects: 1> makes it impossible to
support Unicode and support Windows 9x at the
On 6-2-2012 19:54, Felipe Monteiro de Carvalho wrote:
The Microsoft way is not the same as the Free Pascal way. We are not
required to immitate them when implementing our routines. The
Microsoft way has nasty side effects: 1> makes it impossible to
support Unicode and support Windows 9x at the
> As you know, we are very keen on backwards compatibility
Ummm, I'll need to investigate that. But if it seams risky we could
always add "and (DefaultSystemCodePage = CP_UTF8)" to the if, which
would disable it for legacy code and enable it only for Unicode
applications. If you use SetMultiBy
On Mon, 6 Feb 2012, Felipe Monteiro de Carvalho wrote:
Hello,
SysUtils for Windows utilizes only A Windows APIs, while it could use
W APIs in Windows NT. The attached patch starts correcting improving
the situation.
Advantages of the patch:
* Allows for unicode file names in TStringList.Loa
27 matches
Mail list logo
