locked
WinRT/Store sandbox questions.

    Question

  • Hi,

     

    imagine I'm developing a Metro-style WinRT port of Photoshop or 3dsmax.

    Could I use WinRT ( C++/XAML ) in this way?

    1. I need to use SSE compiler intrinsics to optimize.

    2. I need to use native C libraries like ZLib and LUA ( which provides full C source code ).

    3. I need a mechanism to dynamically load WinRT component plugins. I'm not talking directly about Win32 DLLs, just WinRT dll components. However, these components could require some Win32 DLL dependency closed-source libraries, like the Autodesk FBX or PhysX.

    4. I need to be able to upload my app to your Windows Store passing all the required tests.

    thx.


    • Edited by bubu Friday, February 03, 2012 6:38 AM
    Friday, February 03, 2012 6:37 AM

Answers

All replies

  • Hi Bubu,

    Your scenario would not work as a Metro style app. A plug-in centric application relying on non-Metro compliant DLLs such as you describe would need to be done as a Desktop app. All of the code for your app - including the plug-ins and any dependent libraries - will need to be in your app package and can call only API which are available to Metro style apps.

    For more information on the store's requirements see Certification requirements for Windows apps.

    --Rob
    Friday, February 03, 2012 7:50 AM
    Owner
  • Hi Bubu,

    Your scenario would not work as a Metro style app. A plug-in centric application relying on non-Metro compliant DLLs such as you describe would need to be done as a Desktop app. All of the code for your app - including the plug-ins and any dependent libraries - will need to be in your app package and can call only API which are available to Metro style apps.

    For more information on the store's requirements see Certification requirements for Windows apps.

    --Rob

    Thanks for the response and the link.

    Just a doubt... what if I only call plugins as WinRt components?

    The main problem is that I would need to load them dynamically. I cannot add WinRt DLL components directly to the app's manifest because they're 3rd party.

    And... can I use LoadPackagedLibrary/GetProcAddress and other C native functions (like fopen() a file inside my app's sanboxed dir ) or are them prohibited too? It's not clear.


    • Edited by bubu Friday, February 03, 2012 8:27 AM
    Friday, February 03, 2012 8:17 AM
  • The 3rd party would need to provide the plug-ins to you for you to upload with your package so LoadPackagedLibrary could find it. See this previous thread on the subject.

    C native functions like fopen may or may not work, depending on the underlying implementation. If they are implemented using permitted API (as VS11's C runtime will use where possible) then they will be fine. If they rely on prohibited API (likely in older runtimes) then they will fail. These will only allow access to locations the app has access to and cannot break out of the sandbox.

    --Rob

     

    Saturday, February 04, 2012 12:11 AM
    Owner
  • Let me describe a bit more my plug-in system:

    Imagine my app is located at [installdir]. I create a folder called [installdir]\plug-ins for the addons and I provide some interfaces.

    The user then could implement my interfaces and deploy them to [installdir]\plug-ins.

    Then, I list all the .dlls in that folder and call a the register function.

     

    The big question is... can LoadPackagedLibrary load assemblies dynamically or only native DLLs?

    I see that function returns a HGLOBAL, but I'm not sure how to convert that into an Assembly in order to call Assembly::GetMethod("XXXX")->Invoke()...

    I would prefer to use a WinRT component DLL although I can deal with native DLLs too.

    Saturday, February 04, 2012 2:39 AM