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).

[jkotas]

so corehost (and only corehost) is doing it right

I think that all shipping code is fine, except Environment.ProcessPath. Mono on Windows and corerun are non-shipping code. It is fine to fix the non-shipping code, it is low priority though.

use this minipal_getexepath() as we do on unix repo-wide (and windows+unix on mono).

Note that some of these places want paths for arbitrary modules. For managed implementations on Windows, we tend to avoid the native shims and call the OS APIs directly from C#, even if it means a bit of duplication.

This change LGTM. Number of end-to-end scenarios with process long paths do not work, but that's tracked by other issues.

[jkotas]

Thanks!

[jkotas]

/ba-g DeadLetterered linux-arm32 Helix queue, testing not relevant to this change.