Open rmyorston opened 1 year ago
Ha, it's so obvious! Why didn't I think of this before, especially given the context? Thanks for pointing this out, Ron.
Though the benefits are smaller than they might seem. It only takes some tens of milliseconds to compile alias.c, in large part because I don't include windows.h. Compiling and linking all 148 binaries (in parallel) takes less than a second on my desktop. Building one binary and copying it 147 times would take that down to zero, shaving about a second off the build. I can't deduplicate using .zip — otherwise I'd have already done it with the original busybox.exe — so ultimately the user will still have 148 separate copies with merely the opportunity to deduplicate. (Though it looks like NTFS does have this capability.)
Still, seems worth doing! It's actually even simpler than you said: I can pass GetCommandLineW() straight to busybox.exe without looking at it nor allocating a new command line buffer.
pass GetCommandLineW() straight to busybox.exe
Of course, even better!
Currently w64devkit has 148 tiny alias files for the BusyBox applets. These are all the same apart from the hardcoded name of the applet.
If the applet name were obtained from the command line you'd only need to build one binary and make 148 copies of it with different names.
This special case might be specified by giving an empty command name at build time (
gcc -DEXE=busybox.exe -DCMD= ...
).Then, with details left as an exercise for the reader:
Since
COUNTOF(LCMD)
is known at build time only one branch of theif
should be compiled.