There are several problems on Windows regarding output to the console. In particular all users which require multibyte charsets run into problems. On Windows the Console is a dedicated device an very different from a tty on Unix. Thus it requires special treatment.
- Fixing the output problems will be relatively easy because all current Windows versions support CP_UTF8. Thus a SetConsoleOutputCP(CP_UTF8) will mostly do the job. (The terminal must of course use a font which supports utf8, which is not the default setting on English Windows versions. The CP needs to be restored on exit. Note that by using SetConsoleOutputCP all redirected output will be not be translated and should thus be utf-8.
- The WriteConsole calls in GnuPG need relaxed error checking because the function returns the number of chars actually printed and not the number of bytes given as input parameter. gpg has this bug for a long time ("fatal error: Write Console failed N != M")
- Input via tty can be fixed by using ReadConsoleW and translating to utf-8. This also requires that all gpg internal translations are shortcut; that is the native charset must be fixed at utf-8.
- Input via the command line needs to be changed to wchar_t. However, that would be to hard to implement and thus the suggestion is to do change init_common_subsystems() to re-build the (argc,argv) by using GetCommandLineW, translating that to utf-8m and parsing it into a new argv. Theoretically CommandLineToArgW could be used for the parser but that would require translating each parsed argument to utf-8, so a dedicated parsers is better.
- It needs to be decided whether direct input from stdin typed on the console requires translating or whether we just ignore this case because that is mostly used for debugging. Note that redirecting stdin expects utf-8 as input and thus no changes are required.
- All callers of gpg should use CreateProcessW so that the passed args are multibyte. Changes are required for the GnuPG internal CreateProcess calls as well as for GPGME. Applications which don't change that won't benefit from the new multibyte handling but that is not worse than the current state.