locked
How to use a system DLL with LoadPackagedLibrary

    Question

  • Hi David,

    If I want to use a system dll (assume that DLL can be used from Metro package) thru LoadPackageLibrary, documentation says specify the dll as a dependency in app's package manifest file?, I don't see anyway it can be done from the Visual Studio?

    When I add manually like this:

    <Dependencies>

    <PackageDependency Name="x.dll" />

    </Dependencies>

    i'm getting error: DEP0700, windows cannot install the package ...because this package depends on another package...provide the framework along with this package.

    I don't understand the framework part?

    Could you provide some details?

    Appreciate your feedback.

    Thanks


    Wednesday, October 10, 2012 5:22 PM

Answers

  • The rules are pretty simple for Windows Store apps:

    - You can only use LoadPackagedLibrary to load a DLL that is included in your AppX package and it must be listed in your AppX manifest.

    - All EXEs and DLLs in your AppX package must use only Windows Store app available APIs or they will fail the WACK tool so cannot be deployed to the Windows Store.

    If you look in the Xps Rasterization header (xpsrassvc.h) in the Windows 8.0 SDK, you'll see that the entire API is in the WINAPI_PARTITION_DESKTOP partition including the new Windows 8 XPSRasterizationFactory1 interface, which means it is not supported for Windows Store apps. Most of the XPS document API is available to Windows Store apps.

    If the system API you want to use is not in the Windows Store app API family, then it's not accessible. You can't try to circumvent this by trying to do explict loading or including a copy of the unsupported DLL in your AppX package. You may be able to get this to work locally in some cases, but it will fail the WACK tool.

    Thursday, October 11, 2012 6:38 PM

All replies

  • I tried by copying dll into project folder, now it builds and runs the app but LoadPackageLibrary returns ERROR_BAD_EXE_FORMAT, that means dll that i'm loading is desktop library, it is not a metro package library.

    Right?, how MSFT is providing existing component to Metro, is it taking existing source code and building for metro?

    Thanks

    Wednesday, October 10, 2012 7:38 PM
  • What do you mean by a system.dll here? You cannot just copy arbitrary DLLs into app.

    If you have a custom DLL then you can include it in your appxpackage and load it with LoadPackageLibrary.

    You don't need to register a dependency for a file in your package, only if you need to load a file packaged separately (such as the C runtime).

    --Rob

    Wednesday, October 10, 2012 8:40 PM
    Owner
  • Hi Rob,

    Thanks for your feedback. I totally understand that, but just want to know whether the system service( system xps rasterization ) can be used from metro style app, I have checked the msdn documentation, it seems to be it is not one of the supported service (we don't know it is possible that MSFT could add the support at some point) , however, it is tried (for testing purpose) by directly copying files to the part of the package, I got the error. Also I have compared binary format of the metro library versus desktop dll, I don't find any format difference, I may miss something. Providing some help would help us to clearly understand AppStore vs Desktop library and appstore package eco-system.

    Thanks


    Thursday, October 11, 2012 4:53 PM
  • The rules are pretty simple for Windows Store apps:

    - You can only use LoadPackagedLibrary to load a DLL that is included in your AppX package and it must be listed in your AppX manifest.

    - All EXEs and DLLs in your AppX package must use only Windows Store app available APIs or they will fail the WACK tool so cannot be deployed to the Windows Store.

    If you look in the Xps Rasterization header (xpsrassvc.h) in the Windows 8.0 SDK, you'll see that the entire API is in the WINAPI_PARTITION_DESKTOP partition including the new Windows 8 XPSRasterizationFactory1 interface, which means it is not supported for Windows Store apps. Most of the XPS document API is available to Windows Store apps.

    If the system API you want to use is not in the Windows Store app API family, then it's not accessible. You can't try to circumvent this by trying to do explict loading or including a copy of the unsupported DLL in your AppX package. You may be able to get this to work locally in some cases, but it will fail the WACK tool.

    Thursday, October 11, 2012 6:38 PM
  • Thank you and appreciate the details. Totally it makes sense.

    One question, is there any change in the DLL format from Desktop Dll to Windows App Store DLL, I don't see any, but I was getting BAD_EXE_FORMAT(193), is it because DllMain was excluded because of the preprocessor.

    Just want to understand the reason, why Visual studio has provided separate Windows App Store DLL project template?  is it because of the preprocessor WINAPI_FAMILY=WINAPI_FAMILY_APP?

    Thanks

    Thursday, October 11, 2012 7:38 PM
  • Note that in general you can't explicitly load system DLLs in Windows Store apps. You can use /DELAYLOAD if you are concerned about startup time, but implicit linking is really the only option that works for system DLLs. This isn't a problem because if the system DLL contains an API supported by Windows Store apps, it already has to be there on Windows 8 / Windows RT machines.

    In fact because of this, the N and KN editions of Windows 8 still have a MFPLAT.DLL on the system where Windows 7 removed it completely and apps were supposed to rely on explicit linking to deal with the cases where it was missing. Instead, there is a stub MFPLAT.DLL there and you detect the case of an N or KN edition without the Media restore pack being installed by calling MFStartup and getting back E_NOTIMPL.



    Thursday, October 11, 2012 7:52 PM