We (the Go team at @microsoft) recommend removing this undocumented PEB hack.

I am against your proposal. Your proposal will just break existing code. And there are no benefits in your change.

The main concern is that long path support might be internally reimplemented and no longer use the PEB bit used by the Go runtime, in which case that bit could be reused for other purposes. If that happens, then the chances of Go corrupting the PEB are high.

Microsoft have always been pretty good at supporting existing user code. I suspect they will support Go hack until there is better solution than Windows users fiddling with the registry. And if I am wrong, we can remove the hack when it breaks.

... we are working with the Windows team to define and document APIs which will make long path support easier to achieve.

That would be nice. Thank you.

Alex

I am against your proposal. Your proposal will just break existing code. And there are no benefits in your change.

Thanks for your feedback. I wouldn't say it has no benefits. Only using documented, scrutinized and well supported features is a major benefit, even more in these days where everything is prone to be used by bad actors to gain a foothold.

Microsoft have always been pretty good at supporting existing user code. I suspect they will support Go hack until there is better solution than Windows users fiddling with the registry. And if I am wrong, we can remove the hack when it breaks.

That might or might not happen. It is a cost-benefi tradeoff for Microsoft. One data point: AFAIK, Go is the only important runtime/framework that does the PEB trick to enable process-wide long path support.

And if I am wrong, we can remove the hack when it breaks.

Fair point, although I would still prefer to do the "right" and future-proof thing.

Go has a history of making sure the right things work. Sometimes that means looking at undocumented APIs until documented ones come along. Is there an official way to enable long paths on a per-process basis on Windows? The "official way" you linked is a global registry key that affects all processes, not just the current process. Enabling for the current process makes sense because the current process can declare "I know how to handle these long paths" without making that claim for everything else on the machine.

Also, old Go binaries changing this bit exist and cannot be deleted from the world. Given the Windows emphasis on backwards compatibility (I still can run x86 binaries I compiled in the 1990s), it seems impossible that this bit could be repurposed in the future anyway.

It seems like the right path forward would be for Windows to add a per-process official way. Then Go could use that when running on newer Windows. Until then, it doesn't seem like it harms much to keep Go programs running on current and older Windows working with long paths.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

Is there an official way to enable long paths on a per-process basis on Windows? The "official way" you linked is a global registry key that affects all processes, not just the current process.

The global registry key is not sufficient to enable long path support on all processes, but it is a required setting. When that registry key is set, the process will support long paths only if it has an application manifest that includes the longPathAware setting (all these settings are documented here).

It seems like the right path forward would be for Windows to add a per-process official way.

There is already a per-process official way to do so: registry key + application manifest. I doubt that Win32 will ever provide an API to enable long path support from user code, as it will be an incomplete solution which wouldn't apply to code that runs before that call, even if it's in the executable entry point. That includes:

• The Windows loader wouldn't be able to load statically imported DLLs whose path are longer than MAX_PATH.
• Code in DLLMain from DLLs that load before the executable entry point wouldn't be able to use long path.

This is why the Windows team decided to implement this feature via application manifest.

Then Go could use that when running on newer Windows. Until then, it doesn't seem like it harms much to keep Go programs running on current and older Windows working with long paths.

Good point. We should then revisit #17835, which proposes adding a default hardcoded application manifest to Go binaries.