win32: fix printable-chars with no-op utf8 manifestHEADmaster

When unicode is enabled at build time, but disabled at runtime
(commit 208649d7), we already do some runtime ACP tests and act
accordingly (we know unicode is not in effect) in mingw non-upstream
code (UTF8_OUTPUT, etc - see previous commit).

However, there's at least one upstream unicode code path which was
not touched until now - printable chars.

This code is used by applets like "ls" to display "?" instead of
non-printable chars, where upstream considers byte values above 127
as non-printable, but the busybox-w32 code should consider them
printable when unicode is disabled (ANSI codepage).

We already have code for that when unicode is disabled at build time
(at printable_string2), but when unicode is enabled at build time then
it enters a different code path (which still tests dynamically whether
unicode is enabled - and correctly deduces that it isn't when unicode
is disabled despite the utf8 manifest).

Modify unicode_conv_to_printable2 similar to how printable_string2 is
modified - but only when unicode is disabled due to the manifest not
being in effect (unicode build on win XP/7/8).

A unicode build on XP/7/8 _should_ now behave reasonably close to
a non-unicode build on such systems.

Known issues:

There's one known issue, and that's tab completion doesn't case-fix
the completion. E.g. ~/desk<tab> completes to ~/desktop/ instead of
to ~/Desktop/ (capital D).

This issue exists in unicode builds also on win10+, and is caused by
the fact that when unicode is enabled at build-time, line-editing
uses (32bit) wchar_t, and of the mingw changes in line-edit, only
the backslash-to-slash was ported also to the wchar_t editing, while
case-fix was not (see FIXME at libbb/lineedit.c in commit 0efc7474).

status:

This combination of unicode-enabled build running on XP/7/8 was NOT
tested extensively, so some issues might remain, but other than the
case-fix with tab-completion, there are no known issues.

Main area where more testing is needed is editing (probably mainly
interactive shell command prompt and vi).

Testing:

To test how a unicode-enabled build behaves when unicode is disabled
in runtime, other than actually running it on win XP/7/8, one way
would be to find a combination of build-config values to enable all
the unicode features but not the manifest itself, but that's tricky.

Instead, one could simply delete the manifest from a pre-compiled
binary (mingw{64u,32w}_defconfig), so that it would run in ANSI mode
even on win10+, with the build-time unicode code paths still enabled
at the binary.

One tool to edit windows binaries is https://github.com/avih/perc .
To delete the manifest, use "perc -D -t MANIFEST busybox.exe" .

0 files changed, 0 insertions, 0 deletions