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
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
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 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
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: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
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
13 matches
Mail list logo
