Fix GetModuleFileName in GetProcessPath

[huoyaoyuan]

Fixes #110800

[jkotas]

Ideally, we would have a test for this. Unfortunately, it is not easy to build one because of other issues in the end-to-end handling of longs paths (#58492).

Have you done ad-hoc testing for this? Does the API return the path with or without \\?\ prefix?

[huoyaoyuan]

Ad-hoc testing passed, path is returned without \\?\ prefix:

Explorer refuses to create folder or file exceeding MAX_PATH, and PowerShell can't start process exceeding MAX_PATH. cmd can launch the executable.

[huoyaoyuan]

Does there need to be a bound to prevent integer overflow? It would cause infinite loop again if path length exceeds 2^30, which is unlikely to happen in any situation.

[jkotas]

It would cause infinite loop again if path length exceeds 2^30, which is unlikely to happen in any situation.

I do not think it would lead to infinite loop. EnsureCapacity would throw an exception once there is an overflow and it gets called with negative capacity.

[jborean93]

Ad-hoc testing passed, path is returned without \?\ prefix:

That's interesting, in my manual test in #110800 using PInvoke to call GetModulePath it returned the \\?\ prefix. I wonder if it's due to how the executable was started because I was setting the path to CreateProcess with that prefix.

[am11]

Seems like there is an opportunity for consolidation here, as logically the control wouldn't reach this point if the runtime/corehost initialization had this logic flawed; so corehost (and only corehost) is doing it right. Maybe it's better to delete calls from all these places:

1. runtime/src/native/corehost/hostmisc/pal.windows.cpp

   Line 102 in 2eb59bf

   bool GetModuleFileNameWrapper(HMODULE hModule, pal::string_t* recv)

2. runtime/src/libraries/System.Private.CoreLib/src/System/Environment.Windows.cs

   Line 127 in 2eb59bf

   private static string? GetProcessPath()

3. runtime/src/coreclr/hosts/corerun/corerun.hpp

   Line 108 in 2eb59bf

   inline string_t get_exe_path()

4. runtime/src/coreclr/nativeaot/Runtime/windows/PalRedhawkMinWin.cpp

   Line 244 in 2eb59bf

   REDHAWK_PALEXPORT UInt32_BOOL REDHAWK_PALAPI PalAllocateThunksFromTemplate(_In_ HANDLE hTemplateModule, uint32_t templateRva, size_t templateSize, _Outptr_result_bytebuffer_(templateSize) void** newThunksOut)

(there maybe others)

in favor of

runtime/src/native/minipal/getexepath.h

Line 67 in 2eb59bf

if (GetModuleFileNameA(NULL, path, MAX_PATH) == 0)

and update it to the logic used in hostmisc/pal.windows.cpp. After that, use this minipal_getexepath() as we do on unix repo-wide (and windows+unix on mono).