Why no native WinRT support in Delphi XE3?

winrtAllen Bauer spilled the beans in reply to a question by Brandon Staggs, and speaks about “Window’s 8 dirty little secret”.

I’ve quoted his reply in full below (highlights are mine):

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
little secret.”

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.

28 thoughts on “Why no native WinRT support in Delphi XE3?

  1. There were times when this sort of thing would bring a non-competitive law suit on Microsoft.

  2. Just remember that Allen said Delphi & C++ code, it doesn’t mean that VCL will be updated. VCL is dead and EMB is trying to push firemonkey, they just don’t understand that we won’t migrate all legacy to firemonkey without a migration tool.

  3. Eric do you really think that Microsoft will lock down apps on their dev tools? Serious?

    I think you need to better understand what Allen said and do some extra research.

  4. Joe :

    I think you need to better understand what Allen said and do some extra research.

    If you have more details or informations, feel free to report them!

  5. I’ve know about this “little secret” for months now, ever since Microsoft published the details about WinRT applications. Anyone who read those would know that “Metro” apps are very limited on the locations it can access, but it’s no secret at all, it’s all laid out on Microsoft page about these type of applications.

  6. Win RT has support for Java. I really dont undertand why Embarcadero can’t do it.

    “we won’t migrate all legacy to firemonkey without a migration tool.”
    Also, I dont trust in FreePascal, i hate the little changes in language, performace and stability. Let’s see the second version.

    About the HTML5 Builder, the language is PHP? Any chance to developer with Delphi Language?

  7. Thanks Eric for this article. One of the first interresting stuff about XE3.

    I found out http://stackoverflow.com/q/10279458/458259 about how Micro$oft does lock down its API outside the C# / VC++ scope.
    Also the COM extensions are very close to the .Net CLR, and will difficultly fit with “classic” COM programming model. “This is, as they say, not your grandfather’s COM. One small example: Intead of IUnknown as the base interface for all things, we now have IInspectable. This brings a lightweight sort of “reflection” which is used in projecting these APIs to different languages and runtime environments, and also to enable better tooling. The IDL compiler and syntax have seen huge investments as well.” (quoted)

    I guess this will be very difficult to create a “Delphi projection”, in the WinRT terminology.

  8. Ste :

    Anyone who read those would know that “Metro” apps are very limited on the locations it can access

    The issue here isn’t about the locations, but about the “super-powers” that MS’s VC++ gets access to thanks to its special dispensations.

    There are also the other Apple-like API limitations that lock out Google & Mozilla from providing competing browser implementations.

  9. Not a big issue. Prism does support Win RT. MS never did anything but protecting their new toys first. Toy story continues. We will see how many people will go for Win RT native, the other 2 options are promising too … EMB should focus on what they have on the list, maybe dig their nose into Intel Atom/Intel Mobile or similar if it does make sense for their perspective … they have the data and market analysis. FM2 should finally run on just normal Desktop PCs too … Don’t know if it already does, … as you mentioned some time ago Intel Graphic Card support.

  10. @A. Bouchez
    One of the blog you posted says:
    “A WinRT component implements the IInspectable interface, which derives from IUnknown”
    They added more RTTI to the old COM model – especially to be used by dynamic languages. Of course WinRT needs some work to be implemented – what MS has done on the C++ side is avoiding plain COM programming and transforming it into a more OO approach, something Delphi already does in its COM object support.

  11. @paston
    Yes, but Apple showed that all those limitations are “the best for consumers”, and noone raised an eyebrow. Now everybody else will adopt the same approach, and those with a tool but without a platform will have hard times…

  12. According to twitter, A. Bauer found this in 8 Jul 2012,
    so I would assume they are late, and this is not necessarily the primary blocking issue as it appears from his post. There are either ways to link the msvcrt???.dll or the official documentation contains alternatives for memory-management like heapalloc. I don’t know the best alternatives, but their existence is very likely, as is the Microsoft goal to give mobile endusers a good experience.

  13. I Think it is a big issue for Delphi (not Delphi Prism) Developers.

    The Tablet market is very big and growing very quickly.
    The fact that Delphi developers cannot develop for Win 8 Tablets is very worrying.

    They should have sorted this by now, they must have known about any problems with MS & WinRT for a long time.

  14. @Peter

    Seems totally irelevant to the issue at hand, IMO. RtlUnwind etc. are routines a compiler needs for the runtime (e.g. to handle exceptions), no matter what framework it uses.

  15. @Joe

    Yes, it seriously looks like it. You may be able to use these routines in another compiler’s runtime, but then the app will not ba admitted to the Store. IOW, they seem to be locking down WinRT.

  16. M.B. :
    According to twitter, A. Bauer found this in 8 Jul 2012,
    so I would assume they are late, and this is not necessarily the primary blocking issue as it appears from his post. There are either ways to link the msvcrt???.dll

    He may have twittered about it at that date. I doubt he didn’t know it before.

    FWIW, have you evet tried to link to msvcrtl.dll? I have and it is not so easy, since that DLL expects certain routines to be implemented as macros and is doing other stuff that would require some of the non-DLL runtime too. The routines and the internal setup are simply not compatible with the runtimes of Delphi or C++Builder. IOW, it would require a considerable rewrite of many routines in the Embacadero runtimes.

  17. @Rudy: So the only limitation would be, I cannot sell on the store? Are you saying this is the ONLY limitation?

    Traditional forms of distribution have worked fine and are preferable to my clients.

  18. @Rudy Velthuis

    I don’t think M$ is restricting others from creating compilers(Then why java script for metro) but they really want others to create a dev tool,so many will use Metro.

    I think it is embarcadero’s responsibilites to create a compatible way to call VC++ RTL DLL, it is their responsibilites to create a compiler with all WinRT Features( Async etc), All the best EMB

  19. VRV :

    @Rudy Velthuis

    Then why java script for metro

    AFAIK JavaScript under “Metro” is provided by the IE engine, which also has special dispensation (Mozilla and Google have complained about it, IE is allowed to JIT its JavaScript, while third party browsers in metro aren’t allowed to JIT)

  20. The question is little different, will WinRT evolve beyond Cloud tablet and change Windows into a totally new operating system. If the whole Windows Platform is going to evolve into a monkey circus as described by Michael Justin with certificates … my decision to switch to Linux turns out to be the right one. Microsoft tried the thing with the ‘certificate’ with .net too.

  21. A new .net story is born!!! WinRT is based in Win32/64 API. Those new technologies like .net, WinRT, DCOM, ActiveX etc pp will disappear sooner or later. The MS history has shown that. I remain on Win32 API.

  22. Aren’t all the details going to be revealed on Build 2012 October, 20 – November, 2? I think, that next CodeRage might better have come after Build to have most questions answered.

Comments are closed.