Lets say I want to create a new programming language or use some language not supported by MS (Haskell, Java… whatever) but want to be able to code against windows 8 metro/winRT.
I know that all apps in Metro UI are sandboxed.
I know that I can program in native C++, so I assume that I can do it also in C or assembly.
But:
- Is it possible to create a JIT that will produce assembly code on the fly – like CLR JIT- without breaking sandbox restrictions?
- Assuming that I will use only API allowed in Metro sandbox is it possible to not use XAML as UI interface? – Can I use Direct2D/DirectX directly?
As near as I can tell, it is way too early to make the call on this. I personally don’t know how to write a jitter without using VirtualProtect(), the core winapi function that lets you turn a chunk of memory with machine code generated by the jitter into executable code.
There are a number of native winapi functions available to a WinRT app. The list of blessed system functions is available here. The memory related apis are pretty limited, VirtualQuery is the only one in the list that comes close.
So how do the current language projections do it? Let’s have a look. The CLR has a projection, it gets loaded into any Metro app you write in a managed language like C#. Running dumpbin.exe /imports on c:\windows\microsoft.net\framework\v4.0.30319\clr.dll generates a pretty big list of dependencies on Windows DLLs. A snippet from that dump:
Another language projection is for javascript, implemented in the “Chakra” engine. Hard to figure out exactly what DLL implements that engine, it’s just a code name. Running a sample Javascript project with unmanaged debugging enabled reveals “jscript9.dll” loaded. Let’s do dumpbin.exe /imports on this one:
Well, it is there. It would have to be. Trouble is, right now you can’t call this function. It certainly wouldn’t pass scrutiny from the Store validator.
This needs to stew, at least until the real WinRT becomes available, the one that runs on ARM cores. Not just the one that runs on top of Win32 that you now have running in the Windows 8 Consumer Preview. And can readily take advantage of existing winapi functions, not just the trimmed list. That’s going to be around the end of the year, probably. Real hardware won’t be in your hands until summer of next year.