Why no native WinRT support in Delphi XE3?
We are very keen on supporting WinRT with native Delphi & C++
code. Right now, the issues surrounding the WinRT space center around
the fact that many OS-supplied APIs which are required by anyone
implementing their own language RTL are actually off-limits unless
you’re the VC++ RTL DLL. You know, little things like RtlUnwind for
exception processing and VirtualAlloc (et. al.) for memory
management… Any calls to those APIs from your application will
automatically disqualify your application from being an “official”
WinRT application capable of delivering through the MS app store.
Right now the VC++ RTL DLL is given special dispensation since that is
the library that makes the calls to those forbidden APIs and not
directly from the user’s app. We’re currently rattling some cages at MS
to find out how or if they’re going to allow third-party tools to
target WinRT. Until we can get past that, targeting WinRT isn’t
actually possible from a deliverable product sense. We are able to
build WinRT applications with Delphi that work with a developer
certificate, however they all fail the application qualification checks
because of the aforementioned (an other) APIs.
Like the APIs I mentioned above, there are lots of changes with WinRT
that make targeting it a little more tricky. For instance, you cannot
merely open any file, access the registry, and even use the loopback
(127.0.0.1) adaptor. LoadLibrary cannot be used to load any arbitrary
DLL; you must call LoadPackageLibrary and only on a DLL that is present
in the digitally signed appx package. WinRT is a seriously locked down
sandbox or “walled-garden” with some extremely high walls.
This is a little known or understood “feature” of Windows 8. I see no
press that even talks about this at all. IOW, it’s Windows 8′s “dirty
So here it is, let’s get the secret out and have it be not-so-secret anymore. Microsoft is obviously trying to “pull an Apple” on this, by locking down the 1st-class native compilation for WinRT to MS’s own dev tools.
PS: see also Tim Anderson’s take on the above.