在过去几年中，我开发了几个共享大量C ++代码的技术应用程序，特别是在矢量图形方面。这些应用程序始终在Windows和Linux上运行。最近，我一直致力于让这些应用程序在受保护的环境中运行，现在可以为两种操作系统提供和鼓励这些应用程序。像我之前的许多人一样，我正在努力解决在Windows UWP环境中访问应用数据的问题。
看起来它应该是一件简单的事情，我想从操作系统中获取的是我可以存储和访问某些文件的目录的名称。我不关心这个名字是什么或操作系统想要限制访问它的程度，我只想要一个我可以使用的目录的名称。
当然，我的研究让我进入了这个网页：https://docs.microsoft.com/en-us/uwp/api/Windows.Storage.ApplicationData#Windows_Storage_ApplicationData_LocalSettings。但是样本C ++代码还有很多不足之处，例如所需的头文件和库文件。我不能只将该代码放入.cpp文件中并获取目录名称。看来我需要为winRT建立一个完整的环境才能让代码有用，但这并不是一件小事，而且迄今为止我的成功并未成功。我不明白为什么要获得如此简单而关键的信息需要那么多麻烦。我本来不想使用winRT，而且我没有充分利用我的时间来理解它的所有细节。它无法解决我的应用程序的任何目标。我只想要一个简单的函数，我可以从标准C ++调用来获取目录名。那是过分的要求？
坦率地说，Microsoflt让我得出结论，它不希望独立开发Windows应用程序。为Linux开发要容易得多。 Linux可以完成操作系统需要做的事情而不会产生不必要的障碍。我非常希望在Windows下运行这些应用程序，但是我可以投入多少时间和精力是有限的，而微软似乎在每次迭代其技术时都会进一步推动这一要求。
ApplicationData在Windows :: Storage命名空间中，并且在c ++示例的第一行中必须是
StorageFolder^ localFolder = Windows::Storage::ApplicationData::Current->LocalFolder;
除非您添加using namespace Windows::Storage;如果您想将文件夹路径作为wchar_t *
const wchar_t* wPath = localFolder->Path->Data();
这是我构建该代码时所获得的屏幕截图。我将代码添加到class.cpp文件中，该文件是在添加新的“Windows运行时组件（通用窗口）”项目时创建的。
显然，这里有很多缺失，我需要的是一个解释，不需要微软特定技术（我没有，也不想要）的强大背景。更好的解决方案是不需要微软技术的强大背景，一个正常工作的解决方案。为什么微软想要做到这一点，以便只有能够为Windows编程的人才愿意花费所有时间来学习windows，这很难理解。还有其他途径没有这些繁重的要求。
对于任何感兴趣的人，我开发了一个库来检索商店应用数据目录，其中包含可以从桌面应用程序调用的功能。源代码和二进制文件可以在以下位置找到：