From piyushdubey72090 at gmail.com Thu Nov 2 00:05:12 2023 From: piyushdubey72090 at gmail.com (Piyush Dubey) Date: Thu, 2 Nov 2023 09:35:12 +0530 Subject: [python-win32] Seeking help to understand building of Microsoft Appstore Python In-Reply-To: References: Message-ID: Greetings, I am trying to load Python dynamic libraries to interface Microsoft Appstore Python from an application that I am trying to develop. Now when I use the ?LoadLibraryExW? (which is a WIN32 API: https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexw) function to load the path, I receive an error code 5 (implicating access denied). In order to perform this operation I got some support from Microsoft Community and this was their response to it: ?Long standing rule: unpackaged software cannot use packaged bits, because of servicing. Deployment won't service a package while it's in use. A packaged app can declare a static dependency on another via its appxmanifest () but unpackaged apps have no appxmanifest . I don't think MATLAB is packaged on Windows, I assume it is still installed via MSIs. The solution is Dynamic Dependencies. Apps (packaged or not) have APIs to tell Windows at runtime "I want to use that package" so now Deployment knows process X is using package Y and don't service Y until X quits (or tells us it stopped using Y). Now this is where we get to your scenario. Dynamic Dependencies (DynDep) was originally introduced in early Windows 11 allowing you to target a Framework package. However the Python package isn't a Framework, it's a Main package. In Windows 11, build 22621, DynDep was enhanced to support targeting a Main package! But...you can't target just any Main package, only those that opt-in to allow it. Python's a Main package. If it declares uap15:DependencyTargettrue in its appxmanifest then it's allowed to be a target of Dynamic Dependencies. See https://learn.microsoft.com/uwp/schemas/appxpackage/uapmanifestschema/element-uap15-dependencytarget uap15:DependencyTarget - Windows UWP applications This allows a main package manifest to specify whether the package is a valid target for dynamic dependencies. Python's package probably doesn't declare that, so DynDep won't work. If Python's package was updated with that then yes, DynDep would work. Then you'd call TryCreatePackageDependency() + AddPackageDependency() and the Python package would be added to your process' package graph, and then LoadLibrary("python.dll") would work as expected. The primary docs regarding Dynamic Dependency APIs: https://learn.microsoft.com/windows/apps/desktop/modernize/framework-packages/use-the-dynamic-dependency-api Use the Dynamic Dependency API to reference MSIX packages at run time - Windows apps. The link describes how to use the dynamic dependency API to dynamically take a dependency on different MSIX packages (other than the Windows App SDK framework package) in an unpackaged app at run time. You want the Windows 11 (C/C++) API. In order to make this work you need the Win11 API and Python adding that property in their appxmanifest.xml . In summary, the Python build needs to add the property in their appxmainfest.xml file and our Python interface needs to use the Win11 API. While we can simply create an enhancement request in the Python community to make the change, it is not clear to me that?s guaranteed to work. One thing we can do is trying it out ourselves by building Python. If we can confirm it works, it might be helpful to create an issue in the Python community. Totally understandable if you find this intimidating, but please give it a try and let me know how it goes. I have built OpenJDK on all platforms in a different project myself and it wasn?t that bad given all the instructions.? To successfully load Python DLLs and create dynamic dependencies, it is necessary that the appxmanifest is modified while Python is built on the system. This solution will be much efficient and will not involve the risks of altering ownership of permissions to the system files and corrupting them. I attempted manually building CPython from the public repository ( https://github.com/python/cpython) but I could notice that directory structure of CPython code built on Windows is different from the one seen for Microsoft Appstore installation. Requesting the above-mentioned enhancements or any workaround that could serve the purpose without breaching any security policies. Best Regards, Piyush Dubey On Tue, Oct 31, 2023 at 2:13?PM Piyush Dubey wrote: > Greetings community, > > I am trying to load Python dynamic libraries to interface Python from an > application that I am trying to develop. The Python version I am trying > to load is the one available in the Microsoft AppStore. Now when I use the > ?LoadLibraryExW? (which is a WIN32 API: > https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibraryexw) function > to load the path. It throws an error having error code 5 implicating that > access is denied. It could work if I forcefully take ownership (which is > initially with ?TrustedInstaller?) and alter the permissions of the file > to allow full control to the current user or permit administrator access, > but this does not seem to be an authentic or secure workaround for the same. > > > This is the path to the DLL I am trying to load. > > C:\Program Files\WindowsApps > \PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\python39.dll > > > > > In order to allow interfacing I also tried building CPython from the public > repository (https://github.com/python/cpython) but I could notice that directory > structure of CPython code built on Windows is different from the one seen > for Microsoft Appstore installation. I want to understand how the > Appstore version of Python is built and how is it different from the > process adopted by the official website?s Python. So, is there a different > way to build Python for Windows AppStore? If yes, can you please point me > to the webpage which has instructions. > > > Thanks and best regards, > Piyush Dubey > -------------- next part -------------- An HTML attachment was scrubbed... URL: