force using longPathAware for all reunion apps

[ghost]

Summary

Make Developing and Developers life less painful on win32 subsystem.

reunion 1.0 is yet to hit us. force using Long path awareness for all apps that use reunion components. can't stuck in 1995 anymore. though maintaining backward compatibilty (is app 32 bit or targeting windows version X ? then stuck in 255 else underlying filesystem's limit. ) win32 subsystem also has to be forward compatible for future relevancy. it's high time the subsystem made full use of NT.

[andrewleader]

Hi ecovio1, thanks for the feedback! @ptorr-msft do you have any thoughts on long path awareness?

[ptorr-msft]

Thanks for the suggestion (and your interest in long paths), but as-written this is not aligned with the broad goals of Reunion because we want to allow incremental adoption of Project Reunion features in existing apps. If an existing app just wants to (e.g.) use a new WinUI control, they shouldn't have to completely rewrite their file handling code (and / or wait until the libraries they're using get updated) to deal with 32k paths.

If you have specific suggestions around how to make it easier to embrace long paths, they would be good proposals.

(I'll also note for completeness that the entire long-path feature is off by default so there is no immediate benefit for users).

[ghost]

if an existing app just wants to (e.g.) use a new WinUI control, they shouldn't have to completely rewrite their file handling code (and / or wait until the libraries they're using get updated)

for that comparatively smaller change, forcing to use anything other than that will be headache, yes sure. I understand what you are saying. that's fine if all apps not require it.

but but , judging on the past changes of most win32 apps since they were created, I suspect if that will be the case here.

If you have specific suggestions around how to make it easier to embrace long paths

should've been "for Existing apps and libraries without buffer overrun" .

accessing long paths using existing libraries will require abstraction and innovation. good proposals will be made here once I find ways(if any) of accomplishing this.

the entire long-path feature is off by default so there is no immediate benefit for users

a cumulative update can fix/overwrite that going downlevel to 1809 .

# the rule of nature is :
things to stay relevant from time to time, things must innovate from time to time.

if that innovation requires a change in the core, changes/innovations must must start at some point. it's inevitable.
reunion was just that fresh water drop in the win32 desert land.

this was the point of the proposal.

[ptorr-msft]

a cumulative update can fix/overwrite that going downlevel to 1809 .

There is a very good reason why it's off by default -- it would cause confusion for customers due to almost-non-existent support amongst consumer apps. Imagine a person who copies a photo into a long path and then is confused because their photo-editing app can't find it. Even Windows Explorer doesn't support long paths today, at least in part because of the ecosystem of 3rd-party add-ins that cannot handle long paths either.

The primary users of the feature today are developers, who generally know how to deal with these problems (assuming their developer tools are updated to support long paths). It would be great to enable the feature more broadly in the future, but there is no timeframe for when that might happen. It's a classic chicken-and-egg problem.

[Marv51]

As a first step, would you accept a PR that adds a commented out line to the app.manifest template?

<!-- This can be used to inform the system that the app is compatible with long file paths. 
More info: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation -->
<!--<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>-->