busybox-w32, branch zstd

archival: support zstd in rpm and dpkg

2026-03-24T12:15:33+00:00

tar: support zstd compression

2026-03-22T13:30:58+00:00

Use external utilities (not supplied!) to support zstd compression in tar. Adds 232-256 bytes.

build system: add option to place statics in .bss

2026-03-21T15:17:04+00:00

Upstream BusyBox uses the '-fdata-sections' compiler flag. On Windows this has the unfortunate side effect that static variables are placed in the .data section, thus increasing the size of the binary. Add a configuration option, STATICS_IN_BSS, to force statics into .bss on Windows, saving 2-5KB for most binaries. It has no effect on POSIX builds, where statics are always placed in .bss.

win32: UTF8_OUTPUT: don't fail due to nwritten value

2026-03-19T15:04:16+00:00

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.

win32: UTF8_OUTPUT: refine bad-sequence output

2026-03-19T15:04:16+00:00

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.

Update default configurations

2026-03-11T10:14:58+00:00

Merge branch 'busybox' into merge

2026-03-11T10:14:49+00:00

ash: fix here strings causing segfault in function invocation

2026-03-09T14:23:59+00:00

The size of the NFROMSTR struct wasn't initialised in the nodesize array, so we got: $ ./busybox sh $ f() { cat <<< hello; } $ f Segmentation fault (core dumped) ./busybox sh Signed-off-by: Ron Yorston Signed-off-by: Denys Vlasenko

paste: fix output when file lengths differ

2026-03-05T20:46:04+00:00

If the files being pasted had different numbers of lines the output was incorrect. Rewrite the loop over all lines to allow for this. Add tests for such conditions. function old new delta paste_main 458 526 +68 Signed-off-by: Ron Yorston Signed-off-by: Denys Vlasenko

ash: fix here strings causing segfault in subshells

2026-03-04T14:27:16+00:00

A here string in a subshell or function invocation caused a SEGV. This was due to an upstream bug: the size of the NFROMSTR struct wasn't initialised in the nodesize array. (GitHub issue #567)