busybox-w32/win32, branch waitfor

win32: code shrink procps_scan()

2026-07-15T15:26:35+00:00

The principal change is to replace four separate arrays (one for pids and three for time values) with a single array of structs. There are some other minor adjustments. Saves 96-144 bytes. (GitHub PR #609) Signed-off-by: Ron Yorston

fix: procps_scan: do not confirm a process to be parent if either creation time is unknown.

2026-07-15T14:45:39+00:00

fix: procps_scan: compare process creation times to ensure ppid is real

2026-07-15T14:45:39+00:00

Windows aggressively reuses PIDs of exited processes. When a new irrelevant process gets assigned the former PID of the parent of an orphaned process, `pkill -P`, `pgrep -P`, `ps -o ppid` sees the new process as the parent of the orphaned process, and PPID of the orphan is no longer 1. So in theory, all `pkill -P`, `pgrep -P` calls are potentially dangerous and possible to kill an innocent process which outlives its parent. This issue is already discussed in various Internet communities: - https://stackoverflow.com/questions/6593003/how-can-i-reliably-check-whether-one-windows-process-is-the-parent-of-another-in - https://web.archive.org/web/20140701081232/https://www.sapphiresteel.com/Blog/Killing-Trees-the-Windows-way Comparing process creation times seems a feasible mitigation that should almost always work (though not theoretically sound). The executable is added 512 bytes after the patch.

win32: workaround for overflow of 8.3 short name (2)

2026-07-14T07:49:19+00:00

Replace a call to 'FindNextFileA()' in 'get_reparse_tag()'. This has no effect on the standard builds. Builds with the UTF-8 manifest included save 4-8 bytes as this removes the only remaining call to 'FindNextFileA()'. (GitHub issue #506) Signed-off-by: Ron Yorston

win32: workaround for overflow of 8.3 short name

2026-07-13T15:02:56+00:00

In certain circumstances 'FindNextFileA()' can fail because the legacy DOS 8.3 short name doesn't fit in the buffer supplied. This can be avoided by using 'FindFirstFileExA()' instead, but with a setting that isn't available on Windows XP. - The problem doesn't arise in the standard 32 and 64 bit builds, so no change is required. - Builds with full Unicode support target platforms which have the required setting. They can use 'FindFirstFileExA()' unconditionally, at the cost of 36-56 bytes. - Builds which include the UTF-8 manifest but which are allowed to run on systems prior to Windows 10 need to check whether they need to call 'FindFirstFileExA()' at runtime. This adds 100 bytes. (GitHub issue #506) Signed-off-by: Ron Yorston

rpm: respect BB_SYSTEMROOT

2026-07-02T12:11:37+00:00

Update the 'rpm' applet so it also respects the BB_SYSTEMROOT environment variable. Replace chdir_system_drive() with xchdir_system_drive(), which exits on failure to change directory. Saves 32-36 bytes. (GitHub PR #603) Signed-off-by: Ron Yorston

win32: tweak bitmap icon appearance

2026-06-26T11:48:05+00:00

Make the corners of the symbolic bitmap icon look more rounded. Signed-off-by: Ron Yorston

win32: shrink bitmap icons

2026-06-23T15:06:39+00:00

Reduce the colour depth of the bitmap icons from 24-bits colour/ 8-bit alpha to 8-bit colour/1-bit alpha for aterm.ico and 1-bit colour/1-bit alpha for sterm.ico. This reduces the size of the standard builds by 21KB. The builds targeting Windows 10/11 already used smaller PNG icons. Signed-off-by: Ron Yorston

sync: handle certain edge cases

2026-06-23T07:05:34+00:00

Recent changes to our mntent routines added support for Windows volume names. If such a name is available use it in our sync(2) implementation to flush file buffers. Failing that, use the drive letter as before. This handles edge cases where only one or other of the volume name or drive letter is available. Adds 32 bytes. Signed-off-by: Ron Yorston

Fix the flags for stat (again) (#601)

2026-06-22T10:36:43+00:00

* Revert "find: reset stat(2) flags before terminating" This reverts commit 228ee18fbe8cf408440e7bbe91db4ef201312983. * test: fix flags for stat with NOFORK test is a NOFORK applet, so the flags under mingw_stat may not have been reset before calling it. We have it so it also restores the flags after, since it could be called in the middle of another applet. This also needed a way to retrieve the flags, so they are just done through the return value. * Add comments about not having to restore flags Just for future reference * lineedit: use new flag restoring * win32: simplify mingw_access calling Since we now have a way to get the previous flags, mingw_access can be changed to ignore any stat flags * stat: comments from PR Adds 32 bytes.