none
How to support both metro and desktop style applications with a single DLL?

    Question

  • I'd like to reference C runtime symbols taken from system libraries in my DLL. E.g. errno.

    On the desktop I did a loop around GetModuleHandle() to find out currently loaded runtime lib and then GetProcAddress() to resolve the location of errno without a need to link in any import libraries. Thus being effectively compatible with many versions of MS runtimes.

    May I do the same with metro app? I saw the above Get*() APIs are forbidden in metro.

    Should I create a separate version of my DLL to support metro and will I be able to support all possible incarnations of WinRT without actually linking to them?
    Thanks.

    Monday, March 26, 2012 2:47 PM

All replies

  • To start, I want to make sure you have run across Martyn Lovell's talk which discusses the platform versioning story for Metro style apps. This may answer some of your questions.

    Lap around the Windows Runtime
    PLAT-874T
    Speakers: Martyn Lovell

    The replacement for GetModuleHandle would be LoadPackagedLibraryGetProcAddress is still available.

    A Win32 DLL can be packaged in your Appx package as well as long as it conforms to the store rules. It does not need to be a WinRT component.


    David Lamb

    Monday, March 26, 2012 7:13 PM
    Moderator
  • David, thank you.

    I've studied a couple talks from the BUILD conference and also tried couple metro examples in VS11.

    So now I think I should do a LoadPackagedLibrary for msvcr11.dll followed by GetProcAddress to dig out the address of errno symbol.

    But I have follow up questions.

    a) LoadPackagedLibrary description says that it will only load the library if it was mentioned in the application manifest. If I only provide a dynamic library for further use in another, separate application, how can I be sure that the final application's manifest will contain msvcr11.dll? Should my DLL include its own manifest with msvcr11.dll mentioned or I can do a DLL without manifest and it will work? And if I do a static library for use in metro style development, shall I also supply the manifest somehow?

    b) LoadPackagedLibrary description says that it applies to Metro style applications only. Does this mean that a desktop application cannot reference this symbol as it won't get resolved at runtime? Or the symbol is legal, but it just won't work in desktop app? If it is legal, is there a way to detect whether I'm running in metro or desktop app?

    c) Regarding versioning. If I understand it correctly, I will have to add msvcr11.dll to my manifest and when msvcr12.dll appears I would add it to the manifest as well and will try to LoadPackagedLibrary 11 and 12 versions, whichever gets loaded will suite my needs.

    Thanks,

    Nikita

    Friday, April 20, 2012 5:23 PM
  • a) Was just covered in http://social.msdn.microsoft.com/Forums/en-GB/winappswithnativecode/thread/d18269c0-d16c-4d18-b7f4-a407dc4ef79e. Add a reference to the Microsoft.VCLibs package.

    b) http://msdn.microsoft.com/en-us/library/windows/desktop/hh447159(v=vs.85).aspx. From a desktop app, LoadPackagedLibrary will fail with APPMODEL_ERROR_NO_PACKAGE. I don't know of a way to tell if you're running inside of a Metro application -- but you can't use LoadLibrary from within the DLL if you intend to include it in the Metro-style package. LL isn't one of the approved API's for Metro style apps, so telling the difference is moot as you won't be able to have a Metro style code path that calls LPL and non-Metro style code path that calls LL -- You need to restrict the common dll to only Metro style approved api.

    c) I'm not clear on this scenario. Let me research this a bit.

    -Steve

    Friday, April 20, 2012 11:03 PM
    Moderator
  • Steve, thanks for the answers, however both links you suppied are broken.

    Nikita

    Saturday, April 21, 2012 8:24 PM
  • If you remove the period at the end of each link it will resolve. Sorry about that.
    Wednesday, April 25, 2012 12:01 AM
    Moderator