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
install paswstrings as the unicode manager.
The related bug tracker item is:
http://mantis.freepascal.org/view.php?id=21114
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Episode 3. Addressing and it's limits Part One!
First, let me apologise for this post as it's going to be a large one. Second,
I don't talk about 64 bit modes here because I have never used them. But the
basics will not have altered. IBM really does put a lot of effort into
maintaining backwar
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
On 6-2-2012 17:54, Felipe Monteiro de Carvalho wrote:
The related bug tracker item is:
http://mantis.freepascal.org/view.php?id=21114
IMO This should not be done that way (at all):
MS does it by respecting the PE flag for unicode and expects strings
accordingly: If the PE says it's unicode, a
> 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 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
On 06.02.2012 19:39, Thaddy wrote:
On 6-2-2012 17:54, Felipe Monteiro de Carvalho wrote:
The related bug tracker item is:
http://mantis.freepascal.org/view.php?id=21114
IMO This should not be done that way (at all):
MS does it by respecting the PE flag for unicode and expects strings
accordin
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
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 6-2-2012 20:21, Sven Barth wrote:
Out of interest: Which flag are you talking about? Because I'm not
aware of any such flag.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc
On 2/6/2012 1:55 PM, Thaddy wrote:
> It is known which versions are unicode. I am merely refering to the OS
> version flags. These are the ones which determine if the windows version
> is unicode or ansi.
> There's no point in running an ansi compiled exe on a unicode platform.
> Once a programmer
On 06.02.2012 20:55, Thaddy wrote:
On 6-2-2012 20:21, Sven Barth wrote:
Out of interest: Which flag are you talking about? Because I'm not
aware of any such flag.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.fre
On 6-2-2012 21:04, Craig Peterson wrote:
In C on Windows the UNICODE symbol controls whether undecorated
functions should use the A or W versions, and what the TCHAR symbol
translates to.
This exactly the case and I do noy suggest this to be dropped. (This is
not only C but also FP-C btw)
The
On 6-2-2012 21:07, Sven Barth wrote:
The check you are talking about in C++ is a compile time define that
just switches the defines for e.g. CreateProcess to CreateProcessW or
CreateProcessA (depending on whether UNICODE is defined or not when
including the Windows headers).
There is no oth
On 6-2-2012 21:04, Craig Peterson wrote:
Delphi does the same thing, except the change was built into the
language, rather than done using a conditional symbol, and the A or W
decision was hard-coded rather than wrapping them in {$IFDEF UNICODE}
blocks.
I am not sure about this, (I do not know
On 06.02.2012 21:19, Thaddy wrote:
On 6-2-2012 21:07, Sven Barth wrote:
The check you are talking about in C++ is a compile time define that
just switches the defines for e.g. CreateProcess to CreateProcessW or
CreateProcessA (depending on whether UNICODE is defined or not when
including the Wi
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
On 06.02.2012 21:07, Thaddy wrote:
On 6-2-2012 21:04, Craig Peterson wrote:
In C on Windows the UNICODE symbol controls whether undecorated
functions should use the A or W versions, and what the TCHAR symbol
translates to.
This exactly the case and I do noy suggest this to be dropped. (This is
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
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:41, Sven Barth wrote:
But in FPC you'll need to recompile the Windows RTL if you want to
have UNICODE defined (thus having e.g. CreateProcess default to
CreateProcessW instead of CreateProcessA). In C you just include the
header with the define either defined or not.
Nope, aga
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
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/
Am 03.02.2012 01:37, schrieb Nikolai Zhubr:
> I can set up ssh
> for any FPC developer(s) (though I'll need some time to fix cables etc
> then) Let me know.
It would be nice to get an account, currently I'am still busy with
fixing compilation issue but I'd expect first compiled programs within a
f
On 6-2-2012 21:30, Thaddy wrote:
UNICODE} blocks. I propose FPC follows a similar strategy.
We already did it for Kol, which has a (almost) totally opaque
KOLstring/char type depending on switching on
Meaning/implies: when you are the compiler guardian/owner you can simply
enforce string to uni
27 matches
Mail list logo
