locked
Feature Request: Dynamic code execution as a brokered WinRT API with associated app permission

    General discussion

  • It is my understanding, and forgive me if this assumption is incorrect, that code inside a metro application intended to be eventually submitted to the windows store is not capable of any form of dynamic code execution or generation. This means it is not possible, for example, to implement a dynamic language interpreter that generates native code dynamically and executes it (e.g. a JIT engine).

    It also means that any applications that depend on a plugin model for fast and immediate delivery of time-critical updates are also excluded (tax software, for example, often needs to update plugin components on an extremely tight schedule as state legislatures often release updated specs mere days before a major tax deadline). There are also numerous other scenarios where dynamic code generation and execution is required for optimal code execution. For example - regular expressions that are dynamically generated based on user input (search terms, and so forth).

    The only dynamic code generation facility that I am aware of that is available for metro style apps is Expression<T>.Compile for C#/VB applications and eval for javascript. Neither of which are a sufficient solution to all requirements.

    I understand that dynamic code execution (and to clarify, by this I mean two things: Dynamic code generation and execution, e.g. JIT engines, and dynamic code loading and execution, e.g. plugins downloaded from an external source) represents a security risk in an environment where apps are vetted by Microsoft for inclusion in the Windows Store.

    However for one thing, the security risk is there even without these capabilities - for example a script interpreter could have a sophisticated enough implementation to expose the entire WinRT runtime to scripts downloaded and interpreted from the internet, without the ability to generate assembly code. In fact, we already have one: IE10's javascript engine for metro apps.

    Also, I believe the scenarios that require this capability are valid (even for metro apps). I'm aware that these capabilities are still available in the desktop environment, but I don't believe this is good enough. The current understanding is that the desktop environment for classic apps (whether they are compiled to ARM assembly or not) is not going to be available to ARM devices - only metro style apps from the Windows Store, so this solution is obviously insufficient.

    Therefor, I recommend the following compromise:

    Add dynamic code execution and DLL loading capabilities to the base WinRT platform as a brokered API (LoadLibrary, GetProcAddress, VirtualProtect, some new WinRT api, etc...), as well as the associated managed libraries (Assembly.Load, Reflection.Emit) and special support for these libraries to load and execute code from isolated storage or from memory as necessary. Of course any assembly code or CIL that is executed would run under the same app restrictions as the original app and must target the WinRT api (or one of the Win32 apis that are available to metro apps, i.e. DirectX), and may be pre-verified prior to execution. That's an acceptable performance hit since it is only incurred once prior to execution.

    Second, add a new permission that must be granted in order for an app to make use of these libraries. A warning dialog, similar to existing dialogs for things like permission to access location, should be presented the first time the application runs, with an appropriate warning stating something along the lines of "This application may download and run additional components that may not have been tested by Microsoft."


    • Edited by JeroMiya Wednesday, September 21, 2011 3:51 PM
    Wednesday, September 21, 2011 3:28 PM

All replies

  • You can actually load DLLs that you have packaged along with your app.  You can also implement plug-ins as custom WinRT components.  In that case if your application is architected correctly to dynamically consume newer plug-ins, then you can update your app.

    In this case, an update would not really mean a rebuild of your app.  It would just mean inclusion of a new binary (the new plug-in) along with the existing binaries.  Update to your app in the new model will be much cheaper.

    Thanks

    Raman Sharma, Visual C++

    Tuesday, October 11, 2011 10:24 PM
  • Sharma,  

    Would you care to point out the APIs or sample that described what you mentioned as possible: load DLL, implement plug-ins as WinRT component?

    Thanks,


    Coder
    Monday, January 02, 2012 11:41 PM
  • Any one knows answer to this? I am waiting too, for an answer..
    Tuesday, February 28, 2012 3:23 PM
  • I am also interesseted in how to dynamically load a dll in a metro app.

    Tuesday, March 06, 2012 2:43 PM
  • This walled-garden system is total BS.

    I want to enable extensibility for my application. I want to provide an API for people to write plugins for my application to customize and extend its functionality.

    So you're basically telling me, nope. Not in metro, buddy. You want plugins? Write and package them yourself, or keep out of Metro and out of ARM.

    The limitations imposed on developers in Metro-land are seriously frustrating.

    Monday, March 12, 2012 8:40 AM
  • It's worth noting that for the recent FireFox on Metro project they are being forced to use a hybrid metro/win32 "metrotop" hack (the same one that Microsoft uses to get IE working fast in metro form) to get the functionality they need to run in the metro environment, participate in the extra WinRT functionality (share charm, live tile, etc...), and yet still have a fast javascript engine.

    The fact that they can't really implement FireFox using just WinRT and DirectX concerns me. First, it's apparent that they are using an exception specifically for browsers, and also specifically only for the "default" browser. So, third party applications won't be able to do this. Secondly, I'm guessing the fact that Metro Firefox is still technically a "desktop" app, that it won't be available on ARM.

    How is this better than just allowing JIT and plugins in metro-style applications as a brokered API? At least with metro style application, the user knows exactly what app permissions an application uses and can choose to trust the app, which has been signed and certified by Microsoft. With a desktop app, they have no idea what the app does. And, with it being a brokered API that runs in the metro environment, you can add additional security layers over dynamically generated code. Maybe dynamically generated code doesn't have full access to the WinRT library (like the "web context" for HTML5 apps), or has access to a limited subset of it that doesn't include other brokered APIs like the contacts or the location API.

    Monday, March 12, 2012 4:35 PM
  • How about providing Plugin Support trough through uploading winrt libs to winstore? They could be tracked and verified and then downloaded and executed by the app. Maybe on a per app basis provided by third party contributors, eg. Community. How awesome would that be, plugins in metro style apps and modding support for games.
    Monday, August 27, 2012 4:17 AM
  • The lack of dynamic code generation is also the source of another issue: it's impossible to create dynamic proxies and the like. For instance, I'd like to use Unity.TypedFactories in my Windows Store app, but it's not possible because it uses Castle.DynamicProxy, which in turn uses System.Reflection.Emit.

    I already use System.Linq.Expressions quite extensively to generate code, but unfortunately it's not sufficient for all scenarios, since it can only generate methods, not types.

    If I could pick a single feature to add to WinRT, it would be System.Reflection.Emit. The lack of it is a severe limitation on what we can do in WinRT apps.

    See also this article on the subject.

    Wednesday, July 23, 2014 7:35 PM