Revert start /wait for msiexec and change nulls to ? in UTF-8 mode.

[BillyONeal]

microsoft/vcpkg#23367 was a failure because we still end up trying to download portable git; however as some combination of changes in attempt to debug we drop all msiexec output on the floor now.

This reverts change to add start /wait, replaces nulls with ?s.

[Neumann-A]

as far as I can tell it worked before #394 was merge right? So why not revert that change?

[BillyONeal]

as far as I can tell it worked before #394 was merge right? So why not revert that change?

I don't know which of the 2 changes were the cause of the problem and I think this replace-nulls-with-? behavior is better overall.

[Neumann-A]

It definetly is #394 since @ras0219-msft used the utf16 changes in the boost PR and the output worked.

[Neumann-A]

Here is working output from the CI debug PR: https://dev.azure.com/vcpkg/public/_build/results?buildId=68216&view=logs&jobId=f5997e23-771a-528a-d03c-549a3c7aa976&j=f5997e23-771a-528a-d03c-549a3c7aa976&t=edd0f0a3-c2df-55e3-8a4f-65fe34ccebfa
which is using:
https://github.com/ras0219-msft/vcpkg-tool/commits/dev/roschuma/msiexec
which basically is fcbde26 (+2 commits from the UTF16 changes)

[ras0219-msft]

The start /wait was the change that broke it for me. Additionally, I have not observed issues with not waiting long enough via just cmd /c.

That said, I do support this change to reduce the dependence on "knowing" the encoding of the child process. While it's unlikely to happen to msiexec, I think it's easy to imagine error scenarios in other tools where the encoding can become extremely runtime-dependent. Barring some future heuristic like "If there is at least one embedded null, attempt to decode as UTF-16", I think this is the next best thing. I don't believe that hardcoding the expected encoding of child processes will result in a reliable system.

[dg0yt]

The start /wait was the change that broke it for me. Additionally, I have not observed issues with not waiting long enough via just cmd /c.

I'm sorry for the unintented side effect. The usage of misexec in vcpkg is limited, but my history with this tool is > 10 years. There were lot of strange msi packages and error contexts in that time.

[BillyONeal]

I simplified this a lot based on the feedback above; it preserves the ability to interpret as UTF-16 when we know that's the case, as we do for msiexec, but also keeps the null to ? replacement.

[BillyONeal]

I have an approval now and Robert is out sick so I'm merging this. Thanks for the reviews folks!