C++, C# and JavaScript on WinRT

Question

From image below, Windows 8 Platform and tools. I know this mean I can use C++, C# or JavaScript for Metro style App. I also watch some build's keynote and I have couple of questions here.

Windows 8 Platform and Tools http://www.windowsitpro.com/content/content/140554/windows8-platform-tools_2.jpg

1. Do they have any difference in C++, C# and JavaScript on WinRT, e.g. performance, feature, capability etc.
2. How can I create native Metro App using JavaScript, do I need to use js library from MS or I can use whatever js that I familiar with, for example jQuery.
3. In Metro style App, System Services is only WinRT, does this mean I can't use low-level dll anymore? Will this come with performance cost?

Solution 1

Regarding #1, the line-up would be roughly as follows:

JavaScript - highest-level, dynamically typed, GC. You can only use HTML5/CSS for your UI, the XAML framework (Windows.UI.XAML namespace) is not available. Provides some standard JS APIs (specified by HTML5) in addition to the available surface of WinRT, such as local storage or IndexedDB. Being dynamically typed, heavy CPU-bound processing is likely to be slower than either .NET or C++, though the JS engine is still very fast due to being JIT-compiled and heavily optimized. You can consume C++ and .NET WinRT components, but not write your own in JS. Some aspects of language projection seem to be limited correspondingly - e.g. so far as I can see, there's no way to implement a WinRT interface in JS, for example. Existing JS libraries can usually be reused with no or minimal effort, so long as they work in IE10.

.NET (C#/VB) - mid-level, statically typed with optional dynamic typing (dynamic keyword etc) and GC. XAML UI framework is the default one for UI, but you can also use HTML by using WebView control. Provides full access to WinRT libraries, but also some of its own on top of that, which are sometimes more convenient to use (e.g. Stream vs IInputStream/IOutputStream). Also, the only one that includes special language-level support for asynchronous operations (async and await keywords), which are used heavily when using WinRT APIs due to their highly asynchronous design. Generally speaking, provides most syntactic sugar - aside from async stuff, you get LINQ to objects (which works over WinRT collections). Can write your own WinRT components, which can then be used from JS or C++/CX. Existing .NET libraries may or may not be readily reusable, depending on what classes in .NET Framework they rely on; components written for Silverlight or WP7 are most likely to be reusable with no or minimal changes, while components written for .NET 4 Full or Client Profile may require significant changes to run.

C++/CX (Visual C++ Component Extensions) - low/mid-level, statically typed, no GC - refcounting only. Closest "to the metal" in that its object model is designed to map directly to WinRT with no impedance mismatch - hence refcounting - but still high-level enough to avoid boilerplate and be generally safe to use (e.g. exceptions rather than HRESULTs, strings seen as objects and not handles, dynamic_cast rather than QueryInterface etc). No additional layers, proxy objects etc between you and WinRT, all calls are direct. In most cases, fastest of all three, though the exact difference varies significantly depending on the specific task, and can be minuscule for some (e.g. event-driven app with no or little computation), and considerable for others (e.g. parsing or heavy math). UI story is same as for .NET. In addition, you get the entire C++ standard library available to you, as well as a subset of ATL. Can write your own WinRT components, which can then be used from JS or .NET. Existing C++ libraries may or may not be readily reusable, depending on which APIs they use; those that relies strictly on Standard C/C++ will usually work with no changes, while those that call Win32 APIs may pose a problem if they rely on APIs not available in Metro app container.

---

Regarding #3, this video - http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C - should answer most of your questions regarding the use of Win32 (which I presume what "low-level DLL" means) from Metro apps. Note that while the video is about C++, this also fully applies to C#, as P/Invoke and COM Interop are still there. So if you can call it from C++, you can call it from C#.

Solution 2

1) The point of allowing language choice is to let you choose a language for the intrinsic advantages of the language and not because it is the only way to access an API. If you like dynamic languages, choose JavaScript. If you like static typing, but don't want to deal with memory, use C#. If you want the fastest execution (but the most ability to shoot yourself in the foot), choose C++.

2) That depends on what you mean by native. If you just mean that you want them to look like Metro style apps, the best way is to use the WinJS libraries that ship with the developer preview SDK.

3) WinRT gives you the ability to write and call your own C++ DLLs or C# Assemblies from your JavaScript code. The restriction is that you have to expose the DLL as a WinRT object and you can't call any functions that are not otherwise allowed to be used in Metro style apps.

Solution 3

1. Same differences as they have always had. There's no such thing as C# without automatic memory management. Managed languages will have similar overhead as always.

2. If it runs Javascript, you should be able to use jQuery (which is pure javascript). You may need to call some MS functions for initialization, etc., but existing script functions ought to still run.

3. The most reliable sources I've seen have indicated that (at least mostly) WinRT sits on top of Win32. That "Windows Kernel Services" block is Win32's kernel32.dll. Some upper-level Win32 stuff isn't used in Metro, but what application ever used ALL of Win32?

Solution 4

Other people have explain the difference between the 3 options wells, so I will not repeat it.

However I think it comes done to:

• Choose what you know
• Choose what lets you reuse the most code

So

• If you are a .net programmer then use C# or VB.Net
• If you are porting an app from the windows phone use C# or VB.NET
• If you have a big C++ code base, then consider using unmanaged C++ with WinRT
• If you have a website and wish to provide an off-line version of it, you may get good code (and skill) reuse by using JavaScript with HTML
• If you like JavaScript and HTML, but don’t like .Net then use….
• Etc

Solution 5

This video shows how to call your own C++ code from JScript:

http://channel9.msdn.com/posts/Raman-Sharma-Building-Metro-Style-Apps-with-C-and-JavaScript

View more solutions

Comments

[Pavel Minaev]

Re "You may need to call some MS functions for initialization" - in my experiments, I was able to delete all .js files from a newly created Metro web app project, and replace HTML with a blank page - and it still worked, insofar as it got packaged, deployed, and ran. So I think you can get away without any WinRT calls at all.

[Ben Voigt]

C++/CX is adding an additional layer, if it's translating HRESULT into exceptions. Presumably there's also the possibility to use native C++, and use WinRT like any other COM object, with absolutely no wrapper layers.

[Jon Rea]

"Of course you'll still be able to use Win32 .dll's" - No, you cant