win32: fix output conversion with no-op utf8 manifest

Before commit 208649d7, when unicode was enabled (utf8 manifest), the
build refused to run unless the manifest was in effect (the codepage
is UTF8, and argv, win APIs, and internal strings are UTF8 too).

That commit, however, allows such build to also run where the manifest
has no effect (prior to win10 1903), and so some of the unicode code
paths behave incorrectly in such cases when the runtime ACP is ANSI.

This commit fixes the UTF8_OUTPUT code path in such case, to also
check ACP, instead of unconditionally printing to the console as UTF8.

When ACP is not UTF8, it now behaves identically to a non-unicode
build (doing output conversion from ACP to console out-CP if needed).

Example: create a filename which is valid in the ANSI codepage with
chars above 127, and do "echo *" (glob expansion), which now prints the
name correctly, but previously it didn't when the build has unicode
enabled at buildtime but not runtime (see next why not just try "ls").

This covers the existing busybox-w32 unicode code paths, as the others
(UTF8_INPUT and unicode-aware editing) already had runtime ACP test,
so unicode _should_ be disabled correctly if the runtime ACP is ANSI.

However, there are also some new upstream unicode code paths which
can be entered now - when unicode is enabled at build time but
disabled at runtime.

One we know of is printable-chars code, which is used by applets like
"ls", and so currently, when unicode is enabled at build time but
disabled at runtime, "ls" displays valid ANSI chars above 127 as "?".

The next commit will address this.

0 files changed, 0 insertions, 0 deletions