Embarcadero’s chief scientist Allen Bauer has posted about the problems facing tool vendors who want want to support Microsoft’s Windows Runtime (WinRT) platform with their own compilers, which he calls “Windows 8’s ‘dirty little secret.’”
The issue is that in order to enforce security and isolation in WinRT apps, Microsoft prohibits certain API calls. Even if you find a way to use them, applications that use these calls will not be accepted into the Windows Store, which in effect means no public distribution.
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.
Bauer adds that there are other restrictions that make it hard to create an alternative toolchain:
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.
Embarcadero’s answer has been to create a framework that makes desktop apps look and behave somewhat like WinRT apps. I posted about these fake metro apps here. Even Live Tiles are supported. However, these apps cannot be distributed via the Store either, but only through a desktop setup. In addition, they lack the security of true WinRT, and access to the Contracts system for safe exchange of data.
The company does have a .NET tool in the works, called Prism, that will build WinRT apps.
Who is the villain here? Embarcadero’s concern is understandable, since it is locked out of creating a native code compiler for WinRT. On the other hand, to what extent can Microsoft relax the restrictions without blowing a hole in the WinRT security story. There are parallels with the complaints from Google and Mozilla that they cannot compete equally with IE10 in the Modern UI environment.
Thanks to .NET support, Microsoft does have a measure support for alternative languages; it is the Common Language Runtime after all. What would be better though would be to support LLVM, as Apple does on iOS, though this is not likely to be on Microsoft’s roadmap.
Thanks to Eric Grange for pointing me to this post.
Very interesting, but I’m somewhat surprised that developers of native Windows consumer applications (as opposed to scientific computing etc.) would even consider compilers other than Visual C++. Moreover, aside from security restrictions, native WinRT coding requires Visual C++ language extensions to become tolerable — does Embarcadero plan to offer those, too?
If Microsoft cannot relax the restrictions, so why is it letting Visual C++ developers use those “forbidden” APIs? The issue at stake is that Visual C++ and C++Builder (or Delphi) should have the same rights! More or less like Internet Explorer and Chrome…
VC++ devs can’t use the forbidden apps either. But the VC++ runtime can. At the moment Emba’s runtime cannot call them. That’s the iniquity.
How they were able to know that the app is not compiled using visual C++, But are the attributes in Delphi apps that distinguished from visual c++
In my view only the reason for the popularity of Microsoft Windows is letting third party compilers for their development (pascal , C++builder , power builder , real-basic , qbasic etc).
But now they are coping APPLE, I am sorry EMB, now you may be forced to develop a .Net Compiler again(May be possible) OR Need to file a case against Microsoft(Possible, but…..?????)
IMHO MS should just ask third-party vendors submit their equivalent runtime DLLs for validation – and then sign it in way it is allowed to work inside WinRT. Unluckily Apple iOS paved the way for totalitarian control over applications, and instead of moving forward we are back to the 1960s’ when your hardware supplier had total control of what you were running on your system.
Other WinRT restrictions designed to sandbox applications must be taken into account, I do not understand why Bauer complains about them, WinRT is designed to keep applications outside most of the standard WinApi, of course they will have to develop a VCL-RT that doesn’t attempt forbidden operations, and the application model will be different – it doesn’t look a problem of the build toolchain.
Third party tool chains could get around this by wrapping the VC++ runtime but that would add a dependency on a redistributable that normally doesn’t ship with the OS. That may not be that big a deal anymore seeing as how all other apps in the Windows store will have the same dependency. Its likely the VC++ runtime will come preinstalled the way .NET is already or it may be downloaded alongside the first application a user buys from the store. Either way it still seems like an unnecessary restriction put in place to discourage the use of third party tool chains.
It reminds me of when Apple announced that only applications developed with the Apple tool chain would be accepted to the App Store. After the development community cried fowl Apple changed their tune.
Let’s face it the walled garden model is less about platform security and more about market security. It’s worked quite for the dedicated game console and set top box markets. I wonder how long it will be before both Microsoft and Apple restrict desktop applications from even downloading if they weren’t purchased from their distribution channel (all in the name of security of course).
Maybe Allen Bauer should call Anders Heijsberg for some help 🙂
Well, crap. I didn’t really intend for this to blow up like this. I was merely responding to some valid questions and concerns about the “facts of the case” from our perspective. Clearly, MS is steering third-party tools vendors to the CLR side for WinRT support. However, since Delphi & C++Builder have long been native-code compilers, getting into the WinRT space on the native side is clearly our preference. I would truly like to be wrong here and I’ve missed something. If there is some “program” or protocol for third-party natively-compiled tools, I’m all ears.
Some have suggested (and we’ve even looked into it), wrapping the VC++ runtime and using it for Delphi. Unfortunately, that has a couple of serious hurdles. The first is licensing; we cannot “pass through” a redist license without a special agreement from MS. The second is the technical issues related to how exceptions are managed and propagated. The object-models are different and the exception frames are clearly different. These are not trivial exercises and could have the impact of very subtle semantic changes in the nature of the language.
FTR, we are reaching out to MS on this issue, including some of my personal contacts.
Jo mei. Assuming the spirit of WinRT and the restrictions that apply will become part of the whole Windows WinXX product line … then Windows is dead. MS already tried this years ago and not only one time I think … .net will not help in this case.
In best case MS wants to move Win RT to a version very likely 5.x quick and extend the API. Usually WinRT is very restrictive, one cannot include COM objects that call forbidden functions … not nice.
shutdown init 0
Honestly @Allen B. I don’t want to have to install specific versions of the VC runtime via maybe a redistributable package… this is something many people in IT systems administration don’t like. It’s a system modification in many cases. Imagine someone uninstalls …
DLL would be very likely the next thing. I had this when using the msvcrt in Delphi. Finally it worked after analysis with delayed load of the dll. Don’t consider this way … very evil.
Then it is better to have no support or build something from scratch just for the mobile part. This could become required, we will see.
In Debian you can tell an executable – use this library in this version from now on … and MS has nothing. They should be happy about people who just ship executables.
For the record, to build a WinRT application with VC++ you must link with the VC++ RTL DLL. You cannot statically link in the C++ RTL into your WinRT application. This is because it would give the appearance that your application is calling the forbidden APIs.
maybe Microsoft can make some special thing for compiler vendors, just like they did for browser vendors.
http://www.osnews.com/story/25704/Microsoft_creates_special_application_class_for_Windows_8_browsers
Allen,
Did you attend, or have you seen, this?
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/The-Windows-Runtime
They seem to be offering help.
The *only* problem is that your apps can’t go on MSs shitty app store? Fine.
@Bunny, “In Debian you can tell an executable – use this library in this version from now on … and MS has nothing. They should be happy about people who just ship executables”
There has been support for this in Windows for years through the manifests.
@Allen Bauer, Thanks for sharing the news with us, All the Best.
@Niclas Lindgren
Thank you. Found it. Thats valuable.
http://stackoverflow.com/questions/2100973/dll-redirection-using-manifests
Some clarification/correction to some of the statements on XE3 and beyond. RT is certainly different from traditional windows development from a both a technical and business perspective. From a technical perspective it’s certainly more locked down and less open for various reasons but we do plan to support RT and are working to that end. From a business perspective, much like the Apple iOS platform, consumer transactions will flow thru the Microsoft App Store, which is one of the reasons among others why things are locked down in RT. There is no over arching reason why third parties should not be able participate in the RT platform and store, and we plan to be there. As a third party tool developer this is business as usual. There are always puzzles to solve, and we work with the platform vendors to solve them.
However, that is not the goal for XE3, nor the drive for the Win8 support in XE3. There are millions of existing desktop applications for Windows, and the benefit of XE3 is developers can quickly and cost effectively migrate those applications forward to the Windows 8 UI experience on desktops and Slate devices including Surface Pro with minimal effort. “Metro” isn’t a technology, it’s a UX style guide – it’s been used WinCE Phones, XBox, Silverlight, in upcoming RT, and in new desktop applications like Office 2013. So to suggest there is a fake metro is like saying “Indigo” is a fake “Blue”. Metropolis UI is a desktop flavor of the Windows 8 UI Style, and it’s compatible with existing code bases.
To reiterate, the key benefit for XE3’s Win8 feature set – and it’s significant – is that it allows devs to rapidly migrate their applications to the Windows 8 OS and Style with minimal effort using the same codebase, and run them with the “metro” style on Windows 8 and intel based Slates/Surface and earlier Desktop Win OSes from XP to 7. Those same applications can also be retargeted to OSX Lion and Mountain Lion. A future version of Delphi will support RT and ARM and that will have a different goal and benefit. RT is a different ballgame.
@Michael Thanks for the clarification. My understanding is (and what I have seen in the video) is that the intention of Metropolis is to create apps that the casual user will not distinguish from WinRT apps, complete with Live Tile and App Bar support. That is quite different from, say, Office 2013 which looks nothing like a WinRT app. Which is not to say that Metropolis is a bad idea necessarily; the point about reusing existing code is an important one.
The folks at Embarcadero look to have issues to understand new platforms. It looks since they acquired Firemonkey code, they started to think “skinning” is enough to support a new platform. If you read MSDN (http://msdn.microsoft.com/en-us/library/windows/apps/hh974576.aspx, http://msdn.microsoft.com/en-us/library/windows/apps/hh700360.aspx) it is clear that a “Metro style app” is not just a UX style guide. It’s a new platform technology. Office 2013 is not a “metro style app”, and in its web sites MS never says Office 2013 is such. Sure, it has a new interface style.
In XE3 they acknowledged that their Firemonkey approach to cross-platform development was flawed, especially on mobile devices, and promised native control support and a dedicate tool. Let’s wait for XE4 or XE5 to let them understand “Metro”, or whatever MS calls it now, is not just a skin.
@Michael Swindell
It seems odd that you post this detailed information in a comment on a blog post, not on your official website.
The official information is far less clear. Some people might think you wanted to obscure the fact that WinRT development is not possible in XE3 !
I don’t get the LLVM remark. Does LLVM use VC++ runtime on Windows by default ? Otherwise it would have the same problems?
@Marco van de Voort, LLVM compiles into an intermediate code, and then that is compiled into something else. That “something else” is the trick, there’s loads of targets for LLVM. It can be x86, ARM, etc. code. The Linux 3D stack in most modern distros uses LLVM to turn shader programs into whatever the video card runs. In this case, LLVM would be used to either generate C# (and Microsot’s compiler or Mono would compile that), or to generate .NET CLR directly. If I’m not mistaken, WinRT doesn’t truly support .NET either, there’s an online converter Microsoft supplies where .NET app goes in, WinRT app pops out.