<p>Am 25.06.2012 11:48 schrieb "Marco van de Voort" <<a href="mailto:marcov@stack.nl">marcov@stack.nl</a>>:<br>
><br>
> In our previous episode, Sven Barth said:<br>
> > > says that WinRT is a COM-based API and uses a .NET-like metadata format.<br>
> > > So it is not native code after all then. I don't know why they advertised<br>
> > it as native. I guess it is faster than .NET code because it is not<br>
> > managed. I thought that .NET allows non-managed code, too.<br>
> ><br>
> > Why does "COM-based + .NET-like metadata" imply that it's not native code?<br>
><br>
> It is ambiguous. Some COM forms can be queried for their methods etc, but in<br>
> some cases straight interface use is also possible.<br>
><br>
> But my guess is that it is like DirectX, import the typelib, generate the<br>
> interface units for it, and go.<br>
></p>
<p>More or less yes, but that what we currently extract from the typelib will then be needed to be extracted from the metadata files.</p>
<p>> > The core libraries are written in either C or C++ and the metadata is<br>
> > needed so that runtimes like .NET and languages like JavaScript can<br>
> > interface with WinRT.<br>
><br>
> Usually scripting and non scripting interfaces are separate. (since they<br>
> derive from different base interfaces)</p>
<p>That's the point where WinRT tries to be strong: You only need the library and the metadata to use it from within native or .NET languages or from within JavaScript (which is provided by an engine that can make use if WinRT kind and metadata)</p>

<p>> > We can also use this metadata to generate Object Pascal wrappers (it is<br>
> > basically the successor of IDL which was used for interface definitions in<br>
> > the original COM)<br>
><br>
> A typelib importer is already in svn.</p>
<p>Which won't be of much use for WinRT as this metadata is based on the metadata that .NET assemblies already use and not on IDL.</p>
<p>Regards,<br>
Sven</p>