A mirror of https://github.com/rmyorston/busybox-w32.git https://git.lua4.win/busybox-w32/atom?h=zstd 2026-03-19T15:04:16+00:00 2026-03-19T15:04:16+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2026-03-18T15:50:29+00:00 urn:sha1:5b1e02cde21fef4fb9d8e8130818bb49e422dcfa The "nwritten" argument and failure conditions were added in commit 208649d7b5, as it crashed on windows XP without it, and specifically because WriteConsoleW on XP expects this to be a non-NULL argument. However, writeCon_utf8 should not be called on XP - and indeed it's not since commit 234a3b97d3, because it produces incorrect output unless the UTF8 manifest is in effect - which never happens on XP. So it was called due to a bug, and it's not called on XP anymore. Nevertheless, it's possible that in the future we will support native Windows Unicode without the manifest - also on XP, and in such case writeCon_utf8 might get called on XP as well, so keep this argument. However the nwritten failure condition doesn't belong here. It's not needed on XP, and MS docs doesn't say that this value should tested in addition to the return value in order to determine failure, and theoretically there could be differences unrelated to failure. So ignore this value when determining failure. Return value is enough. 2026-03-19T15:04:16+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2026-03-18T11:38:24+00:00 urn:sha1:df652277439a30a973438577b1a370f4a7d2f47c Previously, at writeCon_utf8, when we detected an invalid byte (for the current state), then we printed one '?' which also covered any following invalid bytes, until a valid byte for state 0 was detected. For instance printf '\377\377\377A' printed '?A' (3 bad bytes, 1 '?'). This was by design to avoid excessive '?' noise. However, other terminals (xterm), and specifically windows console (and terminal), print one '?' for any decoding error, and also reset the decoding state after every error. I.e. the same input would error 3 times, and display '???A'. Now we do the same, which also happens to simplify the code. The reference behavior is windows console/terminal in UTF-8 codepage (which writeCon_utf8 tries to emulate in other console codepages). To compare, do 'chcp 65001' to set the console to UTF-8 - which also bypasses writeCon_utf8, and check how the terminal displays some sequence. We should be the same, up to CONFIG_SUBST_WCHAR value. The "state" comment is updated since we no longer maintain bad state. While at it, refine also few nearby comments. 2025-12-26T12:29:54+00:00 Avi Halachmi (:avih) avihpit@yahoo.com 2025-12-23T23:40:21+00:00 urn:sha1:234a3b97d371f2b2b2296d933a84f5006e2d6ea6 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. 2025-12-02T09:36:14+00:00 Ron Yorston rmy@pobox.com 2025-12-02T09:36:14+00:00 urn:sha1:208649d7b5e27e5473f72381827364e4cfc0fc17 Now that a binary with a UTF-8 manifest can run on Windows XP it's possible to configure a build which supports Unicode on Windows 10+ but which still runs on legacy systems. - Add the config file mingw32w_defconfig. This is a 32-bit build with the UTF-8 manifest which also runs on legacy systems. - A new config option, FEATURE_FAIL_IF_UTF8_MANIFEST_UNSUPPORTED, allows the check for legacy systems to be skipped. - An incompatibility with Windows XP in writeCon_utf8() has been fixed. See this GitHub issue for details: https://github.com/skeeto/w64devkit/issues/315 2025-08-17T19:45:09+00:00 Ron Yorston rmy@pobox.com 2025-08-17T19:45:09+00:00 urn:sha1:f2e7ac8c2a0ef14f2215869a01f3346e332c57af Changes to the ls applet upstream assumed that the return value of isatty() followed the C standard and would be 0 or 1. The wrapper for Windows' _isatty() didn't allow for it returning a non-zero value for a tty, not 1. This confused ls. Fix the wrapper. (GitHub issue #513) 2025-07-25T07:55:06+00:00 Ron Yorston rmy@pobox.com 2025-07-25T07:55:06+00:00 urn:sha1:1354c47894a71699ec1fd0086644627a621250ce Implement a minimal stty applet for Windows. - Display and set terminal rows and columns - Enable/disable raw/cooked mode - Enable/disable echo mode - Implement 'stty sane' to reset raw/cooked/echo Adds 2120-2304 bytes. (GitHub issue #58) 2024-09-27T10:18:26+00:00 Ron Yorston rmy@pobox.com 2024-09-27T10:18:26+00:00 urn:sha1:940f40e371695d6b247f4b406e7eb580fb91e866 Commit 1ade2225d2 (winansi: allow alternative screen buffer to be disabled) added a workaround for the broken alternative screen buffer in the Wine console. The problem has been fixed in Wine for well over a year: https://bugs.winehq.org/show_bug.cgi?id=54287 Remove the workaround. Saves 80-96 bytes. 2024-08-16T10:19:01+00:00 Ron Yorston rmy@pobox.com 2024-08-16T10:19:01+00:00 urn:sha1:2b00b4311ecf4c6f6331f8c969934fa792f7e15c Add the FAST_FUNC qualifier to several Windows-specific functions. This has no effect in 64-bit builds but saves 336 bytes for 32-bit. 2024-06-28T09:56:40+00:00 Ron Yorston rmy@pobox.com 2024-06-28T07:47:41+00:00 urn:sha1:fcb61f38cd937242882dd7ecdfbf3b4f68c18a8a The BB_TERMINAL_MODE variable is only documented to work for values between 0 and 5. Due to an oversight it also accepted the value 6. Like other unsupported values 6 is now replaced with the default value configured at build time. 2024-04-09T07:58:58+00:00 Ron Yorston rmy@pobox.com 2024-04-09T07:58:58+00:00 urn:sha1:fcf3ec2877f042c6957d808e562807089e23ebe6 Implement a 'title' built-in for ash. It's very simple-minded, performs almost no error checking and is completely non-portable. - With no arguments it prints the current console title. - If arguments are provided the *first only* is set as the console title. Costs 88-116 bytes. (GitHub issue #401)