The program that was being executed was "fc-cache -fv" with the FC_DEBUG=128 environment variable set. This produced output like the small section below
FC_DEBUG=128 C:/WINDOWS/fonts: Scanning dir C:/WINDOWS/fonts Scanning file C:/WINDOWS/fonts/8514fix.fon...done Scanning file C:/WINDOWS/fonts/8514fixe.fon...done Scanning file C:/WINDOWS/fonts/8514fixg.fon...done Scanning file C:/WINDOWS/fonts/8514fixr.fon...done Scanning file C:/WINDOWS/fonts/8514fixt.fon...done Scanning file C:/WINDOWS/fonts/8514oem.fon...done Scanning file C:/WINDOWS/fonts/8514oeme.fon...done
What might not make it through the bug report is that the first character of each "Scanning" line is a tab character.
3 issues:
1. the tab expansion resulted in large chunks of the output being lost. I isolated this to a bad value for TAB_REPLACE_SIZE, apparently the macro expansion was not correct. This resulted in a NULL being inserted after each tab character, terminating the string improperly.
2. The tab expansion depended on the buffer to contain NULLs to terminate the string, while this worked, I judged it risky. I adjusted so that the string was alway terminated with NULL.
3. The tab expansion was nine characters, instead of eight.
Patch attached that should correct the issues.
I'm assuming this only happens in Unicode installers?
I'm using the mingw64 version of nsis, if I understand your question nsis was built with UNICODE='yes'. I did not test any other versions.
Built with UNICODE='yes' and "Unicode True" in your .nsi.
I don't think unicode has anything to do with it. The bug appears to be in the wide character processing for tab expansion which seems (by code inspection) to be independent of any Unicode functionality. My nsi file is very simple and doesn't include any "Unicode True".
I have no idea what fc-cache.exe is so I just tried to reproduce it on my own and had more luck with the Unicode version.
Please try https://nsis.sourceforge.io/temp/Anders/p-x86-ansi/nsExec.dll