locked
How to make a DLL with Windows Runtime Extension be loadable in both Metro and Desktop App?

    Question

  • Hi

    Recently we'd like to develop a DLL which contains multiple threads, and we tried to make this DLL to be loadable  in both Desktop app and Windows Store App. However, we met some problems, such as CreateThread() is not supported in Windows Store App. And then we found ThreadPool::RunAsync, and it requires Windows Runtime extension. But we were not sure whether a DLL that enbales Windows Runtime extension could be loaded in a desktop app and so we did some little experiments, but all failed. 

    Now there are two questions bothering us:

    1. What are the differences between DLL (Windows Store App) and the DLL in Win32Project in VS2012?

    When creating a new project in VS2012, there are two (or more) templates for DLL:  DLL (Windows Store App) and that in Win32Project (Error at runtime: The application was unable to start correctly). I tried to build a very simple Win32 DLL and it can be loaded by a desktop app. But I built a Windows Store DLL with the same code, it can not be loaded by a desktop app. And I noticed that the option "Use Windows Runtime Extension" is "No" in the Windows Store DLL. So what are the differences between them, and how can I make a DLL be loadable by both Metro and Desktop app?

    2. How to Use WinRT extension in a desktop APP/DLL?

    I want to use the TreadPool::RunAsync() API in the DLL so it can be loaded by Metro app, but it needs WinRT extension. In a desktop DLL, when I turned "Use Windows Runtime Extension" on, it cannot be built correctly (fatal error C1107: could not find assembly 'platform.winmd'). Why? And is there a method that I can use WinRT Extension in desktop mode, so that we could build a DLL which is loadable in both Metro and Desktop?


    Thanks a lot.

    Friday, January 25, 2013 8:51 AM

Answers

  • Hi gsdmzht,

    You can create a single DLL which is used by both desktop and Windows Store apps, so long as it calls only API which are available to both. Typically this would be done as a Win32 DLL. Desktop apps cannot import custom Windows Runtime Components. If you need to call API which are available only to one or the other then you will need to separate those out into separate modules.

    The Windows::System::Threading::ThreadPool class is not available to desktop apps. If you look at the requirements section in its documentation it says "Windows 8 [Windows Store apps only]".

    The Enumerate app packages sample demonstrates calling into the Windows Runtime from a desktop app. It uses the PackageManager class, which is valid for desktop apps.

    If you have further questions about writing desktop apps please post in the Windows Desktop Development Forums or in the Visual Studio Languages Forumsas appropriate for your question. Discussion about using C++/Cx in a desktop app would probably be best in the C++ Standards, Extensions, and Interop forum.

    As for the differences between the project types, you can compare the command lines to see for yourself. The Windows Store DLL project will define WINAPI_FAMILY=WINAPI_FAMILY_APP so it gets only the Windows Store app API and not the desktop API. The "Consume Windows Runtime Extension" option sets the /Zw flag to allow C++/Cx in the Win32 DLL. This flag is automatically set for a Windows Store DLL.

    --Rob

    • Marked as answer by Jesse Jiang Wednesday, January 30, 2013 6:26 AM
    Friday, January 25, 2013 10:44 PM
    Owner
  • You may find this article useful: Dual-use Coding Techniques for Games
    • Marked as answer by Jesse Jiang Wednesday, January 30, 2013 6:26 AM
    Friday, January 25, 2013 11:09 PM

All replies

  • Hi gsdmzht,

    You can create a single DLL which is used by both desktop and Windows Store apps, so long as it calls only API which are available to both. Typically this would be done as a Win32 DLL. Desktop apps cannot import custom Windows Runtime Components. If you need to call API which are available only to one or the other then you will need to separate those out into separate modules.

    The Windows::System::Threading::ThreadPool class is not available to desktop apps. If you look at the requirements section in its documentation it says "Windows 8 [Windows Store apps only]".

    The Enumerate app packages sample demonstrates calling into the Windows Runtime from a desktop app. It uses the PackageManager class, which is valid for desktop apps.

    If you have further questions about writing desktop apps please post in the Windows Desktop Development Forums or in the Visual Studio Languages Forumsas appropriate for your question. Discussion about using C++/Cx in a desktop app would probably be best in the C++ Standards, Extensions, and Interop forum.

    As for the differences between the project types, you can compare the command lines to see for yourself. The Windows Store DLL project will define WINAPI_FAMILY=WINAPI_FAMILY_APP so it gets only the Windows Store app API and not the desktop API. The "Consume Windows Runtime Extension" option sets the /Zw flag to allow C++/Cx in the Win32 DLL. This flag is automatically set for a Windows Store DLL.

    --Rob

    • Marked as answer by Jesse Jiang Wednesday, January 30, 2013 6:26 AM
    Friday, January 25, 2013 10:44 PM
    Owner
  • You may find this article useful: Dual-use Coding Techniques for Games
    • Marked as answer by Jesse Jiang Wednesday, January 30, 2013 6:26 AM
    Friday, January 25, 2013 11:09 PM