WinRT 中的 MAX_PATH

Posted 2023-02-25

【中文标题】WinRT 中的 MAX_PATH

【英文标题】：MAX_PATH in WinRT

【发布时间】：2011-12-05 11:36:56

【问题描述】：

我知道 WinRT 中的文件系统访问是不同的（阅读：隔离），但我很好奇我们是否仍然需要担心 MAX_PATH，或者是否已经避免了该限制？

【参考方案1】：

不，MAX_PATH 限制尚未解除 - 如果您将比 MAX_PATH 更长的路径传递给接受路径的 Windows 运行时 API，它仍然有可能会失败。但是 MAX_PATH 不太可能是相关的，因为 Windows 运行时 API 通常在字符串上运行，而不是在字符缓冲区上运行。

此外，由于 Metro 风格的应用程序通常被限制在它们访问的目录中，因此不太可能遇到深层路径。

【讨论】：

我很欣赏宝贵的见解，拉里。我知道这个问题主要是没有实际意义的，因为对 Metro 风格应用程序的限制将阻止许多可能出现问题的情况。不过，我很好奇，在内部，与定义了 MAX_PATH 的 Win32 API 做了多少分离。

我不认为修复 MAX_PATH 限制是 Windows 运行时的目标。

当然。但是，在我看来，如果避免了所有 Win32 依赖项，那么它似乎是在创建新框架时遗漏的常数的合理代表。我很乐意接受关于为什么 1) 这是检验该假设的指标的不合理选择或 2) 整个假设被误导的原因；如果你努力这样做，我可能不得不离开地球仍然承担着负担。

谁说过要避免 Win32 依赖？ Windows 运行时的某些部分是 100% 新的，但其他部分是在现有 Win32 API 之上编写的。

据我所知没有人。但这只是问题所在……没有人证实他们也没有被避免。鉴于 WinRT，我不知道如何重新调整我对 Windows 内部依赖项的思维导图。我认为 MAX_PATH 可以让我深入了解这些依赖关系，因为我知道它是 Win32 特定的，尽管我也很高兴在这个问题上接受教育（例如，Win32 API 结束和 MSVCRT 开始的地方对我来说相当模糊） .