Many thirdparty libraries rely on __file__ being set properly, for example to be able to locate data files, so it is easiest to just set this to something remotely sensible (like the executable path).
This is necessary because when Python is initialized, it takes the codec to use from GetConsoleCP() and GetConsoleOutputCP() without bothering to check whether the given codec is available. However, in most cases, the console codepage will be the same as the ANSI codepage (ie. GetACP()) which is always supported by Python via the 'mbcs' codec.
So what we do is we check whether the console codepage is frozen in, and if not, we set the console codepage to the ANSI codepage and set the stdin/stdout/stderr encoding to 'mbcs'.
This is still not a perfect solution because the ACP may not be able to encode all characters that the application is printing, which would still result in unexpected errors. Ideally, we'd pull in Python 3.6's _io._WindowsConsoleIO class, which bypasses this whole mess by directly using the wide-character Windows APIs to write to the console.
This uses FreezeTool and a new deploy-stub binary to create frozen
applications without needing a compiler when running the tool. This tool
is for experimenting with deployment options and is currently inflexible
and hacky.