locked
Writing C++ WinRT component for cross-language use.

    Question

  • After watching Herb's "Using the Windows Runtime from C++" (TOOL-532T BUILD2011) and looking at slide #9 I got an impression that one can take an existing C++ dll and add a WinRT wrapper around it. The resulting dll could then be consumable from native C++ apps as well as WinRT apps.

    I created a sample dll which has two sets of classes, WinRT classes and pure native classes exported using __declspec(dllexport). I then created two apps: a Windows Store app and a pure native C++ console application. Windows Store app runs fine, it calls into the custom WinRT component and executes the native code. The console app on the other hand links fine against the native interface but when I try to run it I get "The application was unable to start correctly (0xc000a200). Click Ok to close the application".

     

    Am I missing something here? Is it possible to have a single module with the C/C++ external surface and the WinRT external surface as described by Herb Sutter? 

     

    • Changed type twilk Saturday, January 19, 2013 12:26 PM question not discussion
    Saturday, January 19, 2013 12:25 PM

Answers

  • I don't believe Herb meant to imply that the same project would necessarily work for both, but you should be able to write code that will compile in both scenarios.

    You can have a WinRT component make use of a "Win32" static library or even a "Win32" DLL that is included with the app as part of the implementation, assuming:

    * It's compiled with VS 2012 since it must use the VS 2012 CRT version

    * It does not make use of (i.e. result in an API import in your app or in any of the DLLs shipping inside your Windows Store app package) Win32 functions that are not available to Windows Store apps via the WACK tests.

    You may want to take a moment to read this article on my blog.



    Monday, January 21, 2013 10:25 PM

All replies

  • Hi,

    Actually, the class in Windows Runtime component should be WRL object. It is like COM object, so the native C++ in console application can not use it directly.
    Please check these documents
    http://blogs.msdn.com/b/vcblog/archive/2012/09/17/cxxcxpart02typesthatwearhats.aspx

    http://msdn.microsoft.com/en-us/library/vstudio/hh438466.aspx

    But if we include some wind file and enable /ZW, we can use the WinRT object in console. Here is a project template, you can try it.
    http://blogs.msdn.com/b/livingcrazy/archive/2012/09/28/learning-c-cx-with-a-console-app.aspx

    Best regards,
    Jesse


    Jesse Jiang
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 21, 2013 6:26 AM
  • Thank you for your reply but unfortunately it does not answer my question. I know I can use WRL to consume WinRT interface or upgrade my C++ project to C++/CX and take advantage of language extensions.

    Herb in his slides shows a module written in C++ which has two external surfaces: WinRT which can be consumed from any language, and C/C++ for native callers. Let's assume that I have some snazzy physics library that does not use COM. From what he is saying I should be able to add WinRT layer and be able to consume the same module from both Windows Store apps as well as legacy native apps.

    I would like to see an example of how to do this properly. As soon as I add WinRT layer to my native module the native callers fail to initialize properly. I guess one way to solve this would be to have 2 separate projects for my physics library. One project would compile my library for native callers and second for WinRT callers.

    Monday, January 21, 2013 5:26 PM
  • I don't believe Herb meant to imply that the same project would necessarily work for both, but you should be able to write code that will compile in both scenarios.

    You can have a WinRT component make use of a "Win32" static library or even a "Win32" DLL that is included with the app as part of the implementation, assuming:

    * It's compiled with VS 2012 since it must use the VS 2012 CRT version

    * It does not make use of (i.e. result in an API import in your app or in any of the DLLs shipping inside your Windows Store app package) Win32 functions that are not available to Windows Store apps via the WACK tests.

    You may want to take a moment to read this article on my blog.



    Monday, January 21, 2013 10:25 PM
  • Chuck, thanks for your reply. Your blog post is very informative.
    Monday, January 21, 2013 10:38 PM