<feed xmlns='http://www.w3.org/2005/Atom'>
<title>busybox-w32/include/mingw.h, branch cron_changes</title>
<subtitle>A mirror of https://github.com/rmyorston/busybox-w32.git
</subtitle>
<id>https://git.lua4.win/busybox-w32/atom?h=cron_changes</id>
<link rel='self' href='https://git.lua4.win/busybox-w32/atom?h=cron_changes'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/'/>
<updated>2026-05-04T10:51:00+00:00</updated>
<entry>
<title>win32: add FAST_FUNC annotations</title>
<updated>2026-05-04T10:51:00+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2026-05-04T10:51:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=f26b970e4d22e1b2e3ca6209c3412fa0f683d953'/>
<id>urn:sha1:f26b970e4d22e1b2e3ca6209c3412fa0f683d953</id>
<content type='text'>
I've been far too lax in applying FAST_FUNC annotations.  These
can make function calls smaller and faster, but only on 32-bit
systems and for non-static, non-variadic functions with non-void
arguments.

Saves 4680 bytes in the 32-bit build; 64-bit builds are unaffected.
</content>
</entry>
<entry>
<title>win32: improve urandom/zero device handling</title>
<updated>2026-04-26T19:49:26+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2026-04-26T19:49:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=164015bc98835934ed6437107d874e6987ad9418'/>
<id>urn:sha1:164015bc98835934ed6437107d874e6987ad9418</id>
<content type='text'>
Rearrange the code to avoid a superfluous process creation.

Saves 16 bytes in the 64-bit build, adds 24 in the 32-bit.
</content>
</entry>
<entry>
<title>ash: allow 'times' built-in to report process timing</title>
<updated>2026-04-12T10:49:29+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2026-04-12T10:49:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=333c65ca71f1acb2cc6cd3920a346bb8ddf82dec'/>
<id>urn:sha1:333c65ca71f1acb2cc6cd3920a346bb8ddf82dec</id>
<content type='text'>
Move existing code which obtains process execution times into a
separate function.  Use it to allow times(2) to report execution
times for the current process, though not child execution times.

Change TICKS_PER_SECOND from 100 to 1000 to increase the displayed
resolution of process times (though the measured resolution may
well be less than this).

Adds 48-80 bytes.

(GitHub issue #574)
</content>
</entry>
<entry>
<title>ash: allow execution of busybox-w32 binary without extension</title>
<updated>2026-02-25T09:33:36+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2026-02-25T09:33:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=35e590816a844e3ccc707c841b756e83987d09eb'/>
<id>urn:sha1:35e590816a844e3ccc707c841b756e83987d09eb</id>
<content type='text'>
If the busybox-w32 binary didn't have an extension the shell was
unable to spawn itself:

   $ ls -l busybox
   -rwxrwxr-x    1 rmy      rmy         661006 Feb 25 09:37 busybox
   $ ./busybox sh
   $ ls
   sh: unable to spawn shell

This happened because the shell used spawnve() from the C runtime
to execute itself.  Microsoft insists on trying to add an extension
to the name of the binary unless it has an explicit '.' as its
last character.

Use the internal spawnveq() instead, as it handles various quirks
like the above.

Adds 16-32 bytes.

(GitHub issue #566)
</content>
</entry>
<entry>
<title>win32: add support for /dev/std{in,out,err}</title>
<updated>2026-02-02T15:53:01+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2026-02-02T15:53:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=8e6a6312552343aec7f5cde795ef0a11ef83b8ff'/>
<id>urn:sha1:8e6a6312552343aec7f5cde795ef0a11ef83b8ff</id>
<content type='text'>
Allow applets to open the "files" /dev/stdin, /dev/stdout and
/dev/stderr.  The 'stat' and 'ls' applets pretend they exist.

Adds 48-56 bytes.
</content>
</entry>
<entry>
<title>win32: avoid failure when localtime() argument is out of range</title>
<updated>2025-11-26T12:56:11+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2025-11-26T12:56:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=3b2f7ff1e0733c8224d0c6a0632abbbb87e8db91'/>
<id>urn:sha1:3b2f7ff1e0733c8224d0c6a0632abbbb87e8db91</id>
<content type='text'>
The implementation of localtime(3) in the Microsoft Windows
runtime only accepts arguments between the Unix epoch (1970)
and either 2038 or 3000 for 32-bit or 64-bit systems respectively.
For values outside those limits it returns a NULL pointer.

Unfortunately, upstream BusyBox hardly ever bothers to check the
return value.  Thus, when a call to stat(2) returned an all-zero
FILETIME for a file, the 'stat' applet failed.  An all-zero FILETIME
represents a date in 1600, which is clearly before the Unix epoch.

Add a wrapper to localtime(3) which detects an out-of-range value
and returns a valid 'struct tm' for the Unix epoch.  This is easier
than adding checks on the return value of every call to localtime(3).

Adds 32-48 bytes.

(GitHub issue #548)
</content>
</entry>
<entry>
<title>win32: allow use of /dev/tty</title>
<updated>2025-11-10T11:33:33+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2025-11-10T11:33:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=f53dbcb8edbcfdad1721d0f5c9e8a16d54e983dc'/>
<id>urn:sha1:f53dbcb8edbcfdad1721d0f5c9e8a16d54e983dc</id>
<content type='text'>
Treat /dev/tty as an alias for Windows' 'con' device.  The code
is similar to that used for /dev/null.

Adds 24-48 bytes.

(GitHub issue #538)
</content>
</entry>
<entry>
<title>flock: enable by default</title>
<updated>2025-10-09T10:10:40+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2025-10-09T10:10:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=41bab273afa7cc9f773666622eb888aee8a340ac'/>
<id>urn:sha1:41bab273afa7cc9f773666622eb888aee8a340ac</id>
<content type='text'>
Use the Gnulib implementation of flock(2) to allow the flock
applet to be enabled.

Costs 900-984 bytes.

(GitHub issue #528)
</content>
</entry>
<entry>
<title>win32: use RtlGenRandom for /dev/urandom</title>
<updated>2025-10-09T06:49:58+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2025-10-09T06:49:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=255e7ea4e2a0e3d28c0abf2750f42713eff711d7'/>
<id>urn:sha1:255e7ea4e2a0e3d28c0abf2750f42713eff711d7</id>
<content type='text'>
Use the (somewhat ancient) Microsoft RtlGenRandom() function to
provide random data for /dev/urandom.

Saves 176-240 bytes.

(GitHub issue #519)
</content>
</entry>
<entry>
<title>Further mingw-w64/gcc build tweaks</title>
<updated>2025-10-02T11:29:36+00:00</updated>
<author>
<name>Ron Yorston</name>
<email>rmy@pobox.com</email>
</author>
<published>2025-10-02T06:53:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/busybox-w32/commit/?id=0496280c4589bf33192ab01ce052d66179e0ade3'/>
<id>urn:sha1:0496280c4589bf33192ab01ce052d66179e0ade3</id>
<content type='text'>
Commit 6481bb22b (win32: use 64-bit time on 32-bit platforms) fails
to build with mingw32-gcc prior to mingw-w64 10.0.0.

Don't used 64-bit time for such builds.

mingw-w64 7.0.0 and below don't have some definitions required for
native TLS support.  This is enabled by default in the 64-bit
Unicode build.

Add the definitions required for the default build.  TLS 1.3
support needs more but isn't enabled by default.

(GitHub issue #527)
</content>
</entry>
</feed>
