On Tue, 12 Apr 2016, Marco van de Voort wrote:
In our previous episode, Jonas Maebe said:
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.
The central place of posix argv/argc in the command processing (including
getopts), also on nonposix systems is indeed a bit of a problem.
I guess the only way, as always, is to have two duplicate systems on
windows. One wide that is for unicode, (unicodestring paramstr and
D2009 compatible tapplication), one for old legacy ansi apps. (getopts etc).
If argv/argc is known to be UTF8 encoded, then I see no problem with keeping
getopts ?
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
