The Type System
The type systems for WinRT and Xlang are designed around concepts that are common to many strongly-typed, object-oriented modern programmming languages. Creating a projection for a language that fits this description will generally feel most natural. Building a projection for programming languages that differ from these concepts, such as dynamic languages or functional languages is possible, but may require more thought.
The PyWinRT projection in the xlang repository is a great example of a Windows Runtime projection to a dynamic language. The projected objects don't magically acquire dynamic language properties, but with a little thoughtful type mapping, they can still be created and invoked in much the same way as other objects in python. In addition, dynamic languages have the possibility of having simpler projections using reflection & metadata to dynamically generate calls to underlying xlang or Windows Runtime ABIs.
Languages that do not support object oriented constructs can still host an xlang or Windows Runtime projection as well. In these languages, underlying objects would typically be projected using an opaque handle construct of some sort.
Data Precision
A key component of any projection is to carefully avoid data loss while still providing a natural experience. Sometimes this can require creative engineering. For instance, the Windows Runtime has an intrinsic type GUID, which is a 128-bit value. In C & C++, it's typically represented as a union allowing access to the bits in different-sized chunks. JavaScript has no such construct, but it could still be represented as a struct. The Microsoft Chakra support for WinRT treats GUIDs as a special intrinsic type, which leads to the question of how to create them. The Windows Runtime APIs now include a method for creating GUIDs as part of the system for just this purpose.
The Windows Runtime and xlang also support full IEEE 754 Floating Point numbers. Projections should be careful to preserve full bit-perfect fidelity of these numbers when unmodified by the projection. That is, consider this psuedo-code where x is a Windows Runtime type:
var value = x->RealNumber
x->RealNumber = value
assert(value == x->RealNumber)
In a language that uses an alternate representation (e.g. 56 bit floating point values) and precision isn't managed carefully, this code could potentially fail.
COM Apartments
The xlang type system does not require or rely on COM apartments. Projections for xlang do not need to take this into consideration.
For Windows Runtime projections, the projection also needs to take into consideration COM apartments and apartment lifetime. A full discussion is beyond the scope of this document. However, if UI is not a consideration, a Windows Runtime projection get away with a simple model of using CoIncrementMtaUsage on load, and a corresponding decrement on unload. Alternately, the projection can put this responsibility on the developer. In either case, COM smuggling & marshalling are still considerations in this model, but it prevents the projection from needing to explicitly manage apartments.
Threading and concurrency
Windows Runtime and xlang APIs support the ability to write asynchronous code easily in languages that support coroutines. However, some languages are inherently thread-bound. It's the projection's responsibility to ensure that threading constraints of the projected language or runtime are respected. Components are not expected to take this into account. Windows Runtime APIs that support asynchronous completion will respect COM apartment rules, but will not guarantee a particular thread is used when invoking the completion delegate. xlang does not rely on apartments, and the implementer of an asynchronous operation is free to complete that operation on any thread. If the language runtime requires that the delegate code run on a particular thread, it's the projection's responsibility to marshal the call back to that thread.