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? 

 

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

Chuck, thanks for your reply. Your blog post is very informative.