locked
Few questions about native support

    Question

  • I have several games running on both ios and android (native code). Since windows 8 finally supports native code I started working on a port. All good ( apart from total mess in documentation - so many similar terms, its a nightmare finding starting point of what you are looking for ) so far, the engine seems pretty much ported. After doing all that I was extremely shocked to find out there is no way I can add ADs in my free games with the "native-only" approach I've chosen. Documentation says "fully native support is planned for a future release -- there is no release ETA", but I am really skeptical about it.

    So two questions comes to mind:

    1) can I find a documentation of whats possible/whats not using native code only anywhere? I really don't want to run into something like that again.

    2) How feasible is using XAML the same way one would normally use JAVA in android when developing native code game? I believe it's possible to build my whole game in a DLL with native code and address it from the C# application, but I can't seem to be able to find a way to call the c# part from the c++ dll. Maybe I am way off here, but if that's actually true its pretty pointless to go there in my opinion - sure i can add ads at the c# side but being unable to control them from the native side is not an option.

    Thanks.

    Monday, April 29, 2013 8:17 AM

Answers

  • For Ad specific questions please post in the Microsoft Advertising support forum

    From Windows' point of view, anything you can do in managed code can be done in native code. The Windows Runtime libraries are all implemented in native code and are projected into native C++/Cx and into managed C# and VB. Any actual Windows features can be called from native code (the inverse is not true: while most Windows features can be called from managed code, some are not projected into managed code and some won't work correctly with the garbage collector's non-deterministic finalization).

    The nuance here is that managed code has access to .Net Framework libraries which cannot be called directly from native code. These libraries cannot do anything that couldn't be done natively, but there can be managed library support which makes it much easier to achieve some goals in managed code rather than in native code. At the extreme, there are some (non-Windows) features which may be implemented purely as a managed library. A Jim says though, the managed library can be wrapped in a Windows Runtime Component which can be called from an otherwise native project. As I understand it that is what the AdControl does: it can be called from a native app, but the AdControl itself is managed and so loads the CLR into the otherwise native process.

    Another limit on the AdControl that you may run into is not related to managed vs. native code: it has a dependency on the Xaml library and so cannot be used in a purely DirectX application. A DirectX app needs to use DirectX and XAML interop to host the AdControl.

    XAML isn't analagous to Java in the Android world: XAML is a language independant library which can be used in both native code and in managed code. Internally, the Xaml library is native code.

    --Rob

    Monday, April 29, 2013 8:27 PM
    Owner
  • I don't know that they've publically said why. Windows Phone 7 had no native code at all (games were written using the XNA Framework, which is a managed wrapper for DirectX 9 technologies). I'm fairly confident that if they were to give an explanation that it would be something to the effect of "we had a lot of things to do within a limited time and so we had to prioritize certain features and defer things we would've liked to have made happen". That's how all large software projects with deadlines (in this case they wanted to ship in time for phones to be on the market in Holiday 2012). It wasn't until the very end that we publically found out that there'd be a XAML + DirectX story at all.

    So yeah, I expect that they did the best they could given limited time and resources and that we will likely see support for native XAML in the next major update to Windows Phone. As to when that will be, they haven't announced. The last rumors I saw were that Windows Phone "Blue" might be out towards the end of this year or the beginning of next year. But they haven't talked about that or what will be in it (all that's generally known is that it'll likely help unify the Windows 8 and Windows Phone 8 runtimes so that more code will be portable across the platforms).

    If they wanted a marketing trick to "promote C#" then they would've stuck with .NET only in Windows Phone 8 rather than adding support for native apps. I doubt there's an underlying issue with supporting it since the core of the Windows Phone OS is the same as the core of Windows 8.

    Generally all you need to do in C# is call in to your C++ component. It's not a lot of .NET code nor is it particularly complex. The hardest part is making sure that your C++ component publically exposes all the properties and interface methods that need to be accessed by the .NET code (which means complying with the rules for writing a Windows Runtime component). But like I said above, this isn't the right forum for this discussion. This is a forum for writing Windows Store (not Phone) apps with native C++ code. I already gave you the link to the forum for Windows Phone development. If you have questions about Windows Phone development, post them there since the people who spend time there will generally be much more knowledgeable about Windows Phone topics.


    Visual C++ MVP | Website | Blog | @mikebmcl | Windows Store DirectX Game Template

    • Marked as answer by Ludusst Friday, May 3, 2013 10:22 AM
    Thursday, May 2, 2013 8:55 PM

All replies

  • Thank you for taking your time posting this, but unfortunately it's an answer to a different question :)
    Monday, April 29, 2013 3:59 PM
  • As I understand your question, you're wanting to place advertising into a C++ native code application, correct?

    Monday, April 29, 2013 4:03 PM
  • Well, not really (although it may come to that). My question basically is - what am I going to lose if I keep my engine port to native only apart from the ads. I was left with the impression everything can be done using native code only, but obviously that's not the case. I think I can live without ads for the moment but if I continue only to discover in couple of days IAP, xbox integration or something like that can't be done using native code only as well, it will be a showstopper.

    Monday, April 29, 2013 4:42 PM
  • You really lose nothing. If part of you application is more easily written, or only possible using C# then you can develop that in a separate assembly and have it callable from your native code.

    Creating Windows Runtime Components in C# and Visual Basic

    Monday, April 29, 2013 5:01 PM
  • For Ad specific questions please post in the Microsoft Advertising support forum

    From Windows' point of view, anything you can do in managed code can be done in native code. The Windows Runtime libraries are all implemented in native code and are projected into native C++/Cx and into managed C# and VB. Any actual Windows features can be called from native code (the inverse is not true: while most Windows features can be called from managed code, some are not projected into managed code and some won't work correctly with the garbage collector's non-deterministic finalization).

    The nuance here is that managed code has access to .Net Framework libraries which cannot be called directly from native code. These libraries cannot do anything that couldn't be done natively, but there can be managed library support which makes it much easier to achieve some goals in managed code rather than in native code. At the extreme, there are some (non-Windows) features which may be implemented purely as a managed library. A Jim says though, the managed library can be wrapped in a Windows Runtime Component which can be called from an otherwise native project. As I understand it that is what the AdControl does: it can be called from a native app, but the AdControl itself is managed and so loads the CLR into the otherwise native process.

    Another limit on the AdControl that you may run into is not related to managed vs. native code: it has a dependency on the Xaml library and so cannot be used in a purely DirectX application. A DirectX app needs to use DirectX and XAML interop to host the AdControl.

    XAML isn't analagous to Java in the Android world: XAML is a language independant library which can be used in both native code and in managed code. Internally, the Xaml library is native code.

    --Rob

    Monday, April 29, 2013 8:27 PM
    Owner
  • Just when I though i finally figure it out ...

    So, after reading your message I went ahead and ported my native game ( windows 8 rt ) to be hosted in a xaml component (if that's the correct term). It took me a while to get it going but it seems to be working as expected now, even passed windows app cert kit.

    But, what's the deal with window 8 phone in this situation?

    Visual studio wizard generates c# project when asked for c++ xaml project (!?). Well, to be fair it actually generates two projects - c# exe and c++ dll. Still its rather misleading.

    I refuse to believe it's possible to have c# only xaml on w8 phone and any xaml on w8 RT. It just makes no sense whatsoever. I've played a bit with the c# exe, c++ dll setting to try it out and it really seems like a lot of work to get it running - things like GetFileAttributesExW, CreateFile2 stopped working all of a sudden (at least not in the way they do when actually get called by c++ exe), c# project pre/post build steps behave totally different than c++ ones and my packaging system doesn't work. I imagine there'll be lots more i'll run into later, that's just after an hour of testing.

    Thanks.

    Thursday, May 2, 2013 9:45 AM
  • For Windows Phone 8, the only way currently to use XAML is via .NET. That's why it creates a C# XAML project with a C++ component. It's not an optimal situation and hopefully a future update to Windows Phone 8 will include the ability to have native XAML. For questions about Windows Phone 8 development, I'd recommend the Windows Phone Development forum: http://social.msdn.microsoft.com/Forums/en-us/wpdevelop/threads . You might also find these samples helpful: http://code.msdn.microsoft.com/wpapps/Direct3D-with-XAML-Marble-1d51a37b and http://code.msdn.microsoft.com/wpapps/Visual-Studio-3D-Starter-ac3ef01b .

    Visual C++ MVP | Website | Blog | @mikebmcl | Windows Store DirectX Game Template

    Thursday, May 2, 2013 4:26 PM
  • I am honestly speachless right now.

    Can I find an explanation why is that anywhere? Is it just a case of "we ran out of time"? It is a marketing trick to promote c#? Is there an underlying issue with supporting it?

    I really don't want to open managed+native can of worms, but if xaml on phone won't happen any time soon I guess there's not much I can do.

    Thursday, May 2, 2013 6:22 PM
  • The basic difference is that Windows phone 8 is using a Silverlight-based XAML engine. Windows 8 uses a newer framework (codenamed "Jupiter"). Windows phone 8 has a few other differences as well (no support for Direct2D or WIC).

    Thursday, May 2, 2013 8:49 PM
  • I don't know that they've publically said why. Windows Phone 7 had no native code at all (games were written using the XNA Framework, which is a managed wrapper for DirectX 9 technologies). I'm fairly confident that if they were to give an explanation that it would be something to the effect of "we had a lot of things to do within a limited time and so we had to prioritize certain features and defer things we would've liked to have made happen". That's how all large software projects with deadlines (in this case they wanted to ship in time for phones to be on the market in Holiday 2012). It wasn't until the very end that we publically found out that there'd be a XAML + DirectX story at all.

    So yeah, I expect that they did the best they could given limited time and resources and that we will likely see support for native XAML in the next major update to Windows Phone. As to when that will be, they haven't announced. The last rumors I saw were that Windows Phone "Blue" might be out towards the end of this year or the beginning of next year. But they haven't talked about that or what will be in it (all that's generally known is that it'll likely help unify the Windows 8 and Windows Phone 8 runtimes so that more code will be portable across the platforms).

    If they wanted a marketing trick to "promote C#" then they would've stuck with .NET only in Windows Phone 8 rather than adding support for native apps. I doubt there's an underlying issue with supporting it since the core of the Windows Phone OS is the same as the core of Windows 8.

    Generally all you need to do in C# is call in to your C++ component. It's not a lot of .NET code nor is it particularly complex. The hardest part is making sure that your C++ component publically exposes all the properties and interface methods that need to be accessed by the .NET code (which means complying with the rules for writing a Windows Runtime component). But like I said above, this isn't the right forum for this discussion. This is a forum for writing Windows Store (not Phone) apps with native C++ code. I already gave you the link to the forum for Windows Phone development. If you have questions about Windows Phone development, post them there since the people who spend time there will generally be much more knowledgeable about Windows Phone topics.


    Visual C++ MVP | Website | Blog | @mikebmcl | Windows Store DirectX Game Template

    • Marked as answer by Ludusst Friday, May 3, 2013 10:22 AM
    Thursday, May 2, 2013 8:55 PM
  • Accepting your answer to close the thread (although there are a lot I disagree with in what you said, but that's way off topic).

    To summarize in case anyone find this topic - windows 8 rt and windows 8 phone are two very different systems. Writing windows 8 RT in native code only is fully supported, writing one for windows 8 phone is not recommended unless your application is not going to use any third party services because they will most likely require xaml to be used.

    Also in case you are reading this topic for the same reason I started it - wondering how to integrate Microsoft ADs in your native code game - go and check whether you can actually use microsoft ads at all, there's a list of countries which you have to live in to actually use the service. I for one, am not in it :(

    Friday, May 3, 2013 10:22 AM