是否有人成功地为微软商店打包了Windows版的Gtk3应用程序?
我现在正在玩这个:
- Visual Studio 2019;
- Gtk3/Gtkmm发行版通过vcpkg;
- c++应用程序;
- VS应用打包项目。
应用程序自己运行良好。然后对其进行打包，然后运行MSIX包安装程序。当我运行安装的应用程序时，它开始，但是:
- 对话框中出现Access Denied错误;
- 应用程序出现破碎的图标和不正确的颜色(错误或没有主题)。
我已经跟踪了与Gio-2.DLL有关的错误，它试图生成一个子进程，看起来与创建dbus服务器/会话(?? ?)有关。我相信子进程(dbus服务器?)启动，但随后试图做一些在Windows为应用程序创建的沙箱中不允许的事情。
有人知道吗?
经过更多的调查，我可能已经找到了一个解决方法。我把它贴在这里，以防对其他人有帮助。这个解决方法允许为Windows制作一个打包的Gtk3应用程序。Windows打包应用程序运行在各种沙箱中，对包外资源的访问受到严格限制。
首先，问题:在初始化期间，Windows版本的Gio-2.DLL生成一个子进程作为DBus会话守护进程(我可能在这里得到的术语是错误的，因为我不熟悉DBus)。它只对第一个实例这样做。如果启动使用Gio-2.DLL的应用程序的其他实例，则其他实例将使用第一个实例中的现有守护进程。
要启动守护进程，Gio-2.DLL调用CreateProcess()来fork一个RUNDLL32.EXE子进程，其中包含Gio-2.DLL(即其本身)的完整路径，并且g_win32_run_session_bus()作为要调用的函数的名称。看起来RUNDLL32.EXE确实成功启动了，因为它能够显示"RUNDLL"错误对话框。但是，它无法将请求的函数调用到Gio-2.DLL中。我收集到，RUNDLL32.EXE在加载DLL和调用请求的函数时，至少有一个系统调用是被禁止的。
目前，我的解决方案是这样的。假设我的应用程序可执行文件名为"myapp.exe":
- 应用程序包包含myapp.exe, Gtk3和依赖项所需的所有dll，以及另一个可执行文件dbus_daemon_launcher.exe;
- 在进入Gtk主循环之前，myapp.exe调用CreateProcess()来启动dbus_daemon_launcher.exe;
- dbus_daemon_launcher.exe也链接到Gio-2.DLL，使用DLL调用g_win32_run_session_bus(); 然后myapp.exe继续启动Gtk主循环。由于Dbus守护进程已经在运行，所以Gio-2.DLL不会尝试调用RUNDLL32.EXE来启动它，从而避免了错误。
这个解决方法的优点是它不需要制作一个自定义版本的Gio-2.DLL。另外，我使用的是Gtk3:也许这个问题已经在最近的Gtk4中得到了解决，在这种情况下，这个解决方案是不必要的。