Ron Yorston

In general, how ```tar``` handles errors is determined by upstream BusyBox. As a special case busybox-w32 treats failure to create a symlink as a non-fatal error. That seemed the pragmatic...

To answer the original question: it would be nice if upstream BusyBox did match the behaviour of GNU tar. However, I can see why they've done it the way they...

Anyone who knows about Windows networking is welcome to try...

The same issue is present in upstream BusyBox. It probably isn't as pressing a problem there, though: by default upstream uses OpenSSL to handle TLS connections rather than the built...

Indeed, upstream commit 9bab580cd (tls: include signature_algorithms extension in client hello message) has fixed the 'alert code 80' problem.

I don't normally do development work on Windows but in the past I have been able to compile busybox-w32 on Windows 8 with MSYS2. Do let us know if you...

@HuangShumin Many thanks for sharing your work on building busybox-w32 with w64devkit. Since @skeeto had the good taste to include busybox-w32 it's clearly by far the best Microsoft Windows development...

Thanks for the additional information. I've changed the way resources are created to avoid the arguments ```windres``` finds problematic. With this change the patch doesn't need to disable ```VERSIONINFO```: [w64devkit-build-busybox-v2.txt](https://github.com/rmyorston/busybox-w32/files/9858276/w64devkit-build-busybox-v2.txt)...

>when make tries to run it it guesses it's supposed to be at drive C No, that's not make guessing, that's busybox-w32 doing what I told it to. Back in...

>Hmmm.. so make invokes sh with a path starting with slash, and busybox-w32 or ash assumes by design that it should be C: ? It's more complicated than that. If...