Is new JIT-ed programming language in windows 8 metro/winRT possible?

Question

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:

1. Is it possible to create a JIT that will produce assembly code on the fly - like CLR JIT- without breaking sandbox restrictions?
2. 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?

Answer 1

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:

Dump of file clr.dll

File Type: DLL

  Section contains the following imports:

    KERNEL32.dll
...

              430 RaiseException
              581 VirtualAlloc
              584 VirtualFree
              589 VirtualQuery
              587 VirtualProtect          <=== here!
              339 HeapDestroy
              336 HeapAlloc
              342 HeapValidate
              540 SleepEx
              547 SwitchToThread
              ... etc

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:

  ....
  6898F4D5    10D DebugBreak
  6891FDA1    55E TerminateProcess
  6898EF9E    57E UnhandledExceptionFilter
  6891FD58    43C RaiseException
  68903BB7    59E VirtualProtect                 <=== here!
  6A218590    366 InterlockedPushEntrySList
  6A2185A9    365 InterlockedPopEntrySList
  6A2195AA    35C InitializeSListHead
  689026F9    598 VirtualAlloc
  68902852    59B VirtualFree
  6890603E    4A2 ResetWriteWatch
  ...etc

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.