Joseph Brill

@mwichmann Two of the workflows appear to have hung (i.e., making no forward progress for hours). Perhaps canceling is in order. EDIT: Nevermind. New commit.

The proposed changes in this PR are similar to an issue that arose in the Godot project. The Godot issue was based on an implementation proposed in a SCons PR...

The following example illustrates the CRLF issue when decoding binary reads of the console output. *Note: any differences in the actual decoding method ("utf-8", "oem", etc., ...), if any, will...

The following example illustrates a decoding issue when using "utf-8" compared to "oem". When the language is English there are no differences. When the language is German there are differences....

> Right... and MSCommon uses oem, as we were advised by someone a while back, once we got to Python versions where that was consistently supported (3.6+). So is there...

*The refactored code introduced bugs.* The stream encoding attribute may not be writable: ``` # Sanitize encoding. None is not a valid encoding. # Since we're handling a redirected shell...

> If I'm understanding correctly though, there's no good way to test this unless we fired up a VM where the system default language was german? Exactly. That is how...

@mwichmann Perhaps an additional dictionary mapping entry would work? `SCons\Tool\MSCommon\vc.py`: ``` # Dict to 'canonalize' the arch _ARCH_TO_CANONICAL = { "amd64" : "amd64", "emt64" : "amd64", "i386" : "x86", "i486"...

Observations: * Forcing the platform to be win32 on non-win32 platforms seems like it is asking for trouble. The win32.py platform module does not raise any errors or warnings likely...

> and you could disable that sanity testing for those cross platform enabled testing? I suppose. Though likely at the expense of simplicity and likely littered across multiple files (e.g.,...