Marco van de Voort wrote:
Well, afaik on Windows unicode commandlines are supported in $mode
delphiuncode.
They are not supported, because we get the original command line data
using the ansi version of the API call (see setup_arguments() in
rtl/win/syswin.inc). If this is "fixed", then we also have to decide
what to do with the argv p(ansi)char (a good place would be to check
what Windows itself returns from the ansi API call when passing command
line arguments that contain characters that cannot be represented in the
ansi code page.
Another way to know it is not supported, is that it is not listed at
http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes (*)
Jonas
(*) I know you recently committed unicode support for executing external
programs and it isn't listed there yet either, but that's because I
think it is broken on *nix: encoding the command line parameters using
DefaultFileSystmCodePage is wrong, because the receiving/executed
applications will interpret them according to what they deduce as being
DefaultSystemCodePage from the environment instead. We have a routine
that can deduce this code page from the environment (GetSystemCodepage),
so we should probably use that (although it may need some refactoring to
be able to use it in case the environment for the executed process is
specified separately from that of the invoking process)
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
