Over on the Anaconda Distribution we received a (private) bug report about a crash when trying to use scons. I thought initially it was due to one of our patches but I tested it out with official CPython and also with WinPython and ran into the same crash.

To reproduce this, from cmd.exe on CPython (here I installed CPython as part of Visual Studio 2017, then updated it to the latest 3.6.4 release):

```
set "PATH=C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\Scripts\..;%PATH%"

python.exe

..

python
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x00000328 (most recent call first):
```

The trigger for this bug is the following batch code in scons.bat:

https://bitbucket.org/scons/scons/src/c0172db149b1a151eeb76910d55c81746bfede05/src/script/scons.bat?at=default&fileviewer=file-view-default#scons.bat-19

My current thinking is that the best fix here is to modify get_progpath()/get_program_full_path() so that it uses PathCchCanonicalizeEx() at https://github.com/python/cpython/blob/9bee329130aae5a13050c08dab9d349b76e66835/PC/getpathp.c#L558-L559

.. though I will also ask the scons people to change this to use pushd and %CD% instead. Even if you were to make Python capable of handling such bad input, who knows what other programs will fail, and build systems should be extra careful not to mess the environment up like this.

Here's a way to trigger this error that's unrelated to the PATH environment variable:

    >>> subprocess.call('python', executable=r'C:\Program Files\Python36\.\python.exe')
    Fatal Python error: Py_Initialize: unable to load the file system codec
    ModuleNotFoundError: No module named 'encodings'
    [...]

Apparently Windows doesn't normalize the process image path if it uses only backslash as the path separator. It normalizes it if at least one backslash is replaced with a slash.

I agree that explicitly normalizing in PC/getpathp.c is the correct approach.

As far as I'm aware, GetModuleFileNameW(NULL) can never fail other than a buffer that is too small, so that whole function can probably be simplified to abort if it happens and just remove the PATH search.

Also, we should use a similar process for PathCchCanonicalizeEx as we already use for PathCchCombineExW in this file to avoid failing on earlier OS versions.

For extra measure, you may want to normalize `prefix` prior to calculating its length n in gotlandmark(). Then it would be reliable to truncate it via `prefix[n] = '\0'` after joining with `landmark`. Or at least add a comment there or in the calling function, search_for_prefix(), that gotlandmark assumes the current value of `prefix` is a canonical, normalized path.

New changeset 48e8c82fc63d2ddcddce8aa637a892839b551619 by Steve Dower in branch 'master':
bpo-32457: Improves handling of denormalized executable path when launching Python (GH-5756)
https://github.com/python/cpython/commit/48e8c82fc63d2ddcddce8aa637a892839b551619

New changeset e5a9b3574c89a070fbc43caf541759f504e3d492 by Miss Islington (bot) in branch '3.7':
bpo-32457: Improves handling of denormalized executable path when launching Python (GH-5756)
https://github.com/python/cpython/commit/e5a9b3574c89a070fbc43caf541759f504e3d492

New changeset 1d3c518c5ecbd78478738f068f4f035f81f035f9 by Steve Dower in branch '3.6':
bpo-32457: Improves handling of denormalized executable path when launching Python (GH-5756) (#5818)
https://github.com/python/cpython/commit/1d3c518c5ecbd78478738f068f4f035f81f035f9