Windows Phone 7 has put the .NET Language Coevolution Promise in Doubt

by Jonathan Allen on Sep 27, 2010 |

In 2009 Microsoft’s Lucas Bolognese announced a commitment to co-evolution for C# and Visual Basic. While the two languages are free to continue putting their own spin on features, neither is supposed to be given a new capability that the other doesn’t have in some fashion. In .NET 4, functional programming features added to Visual Basic and dynamic features for C# went a long way towards honoring this promise. However, a combination of lingering concerns and new insults has brought that promise into question.

At the center of the current controversy is the lack of VB support for Windows Phone 7. We have been watching this story develop for months, looking for any solid commitment from Microsoft on if or when VB would be available on their new platform. With the Windows market saturated with free/shareware, Windows Phone is an important platform for independent software vendors who want to offer mass-market applications without leaving the .NET ecosystem. So it’s no wonder that fans of VB have been up in arms.

With all their resources thrown into just getting the platform ready before they lose any more market share, it is no wonder that Microsoft choose to focus their flagship language alone. While the CLR was specifically designed for both C# and VB (and strangely, Java), C# is the de facto language for core functionality and thus needs to be done first. Still, with a promise made to the larger, albeit less vocal, Visual Basic users must be honored at some point or the whole platform could lose credibility.

Now that a CTP of Visual Basic for Windows Phone 7 has been released, tensions should be relaxed a bit. Microsoft is stressing that this is an “early access” preview and is nowhere near ready for production use. And while Silverlight templates are offered, there still isn’t support for XNA. This has been a sore spot for years, as there is still no way to use Visual Basic on the XBox 360. We thought there was going to be a solution when VB 9 added the ability to build applications without the VB runtime and thus the op-codes not supported by the XBox, but nothing ever came of it.

While currently not covered by the language co-evolution promise, F# is also slowly getting support for Windows Phone 7. Released about a month ago, the August CTP of F# includes a WP7 version of the F# runtime, FSharp.Core.dll. The necessary projects templates for F# Silverlight apps if offered via Windows Gallery. As with VB, templates for F# XNA apps are not currently being offered.

The next most popular language we are seeing requested in the forums isn’t IronPython, though many people do want it. Nor is it the effectively abandoned JScript.NET or IronRuby languages. Instead we are seeing people asking for that odd hybrid known as C++/CLI. Apparently there are a lot of developers who are looking to port legacy C++ applications to the Windows Phone and see C++/CLI as their best route. While the user interface will certainly have to be rewritten, there is a belief that the rest of their codebases could be reused. (It should be noted that C++/CLI is standardized under ECMA-372 and therefore could be offered by a third party if the hardware can support it.)

Related Editorial

451 Group Analyst Report: Review of Intel & Mashery API Management Platform

API Management - Application Security Made Easy

Cloud Identity Buyer’s Guide: Managing Identity in the Cloud

Enterprises Need Hybrid SSO Solutions to Bridge Internal IT and SaaS

Getting Ahead in the Cloud: The Need for Better Identity and Access Controls

Related Sponsor

*Cloud API Management – the Service Gateway Approach
*451 Group Analyst Report: Review of Intel & Mashery API Management Platform

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

porting C++ to C++/CLI? by Stefan Wenig Posted

Re: porting C++ to C++/CLI? by Andy Dent Posted

Re: porting C++ to C++/CLI? by Stefan Wenig Posted

Re: porting C++ to C++/CLI? by Andy Dent Posted

Re: porting C++ to C++/CLI? by Stefan Wenig Posted

I wonder how much I pay? by Jim Leonardo Posted

Re: I wonder how much I pay? by Jim Leonardo Posted

Re: I wonder how much I pay? by Jonathan Allen Posted

porting C++ to C++/CLI? by Stefan Wenig

I've always considered C++/CLI as a language specifically designed for the CLR, suited in particular to writing interop code, or to be used together with standard C++ code, e.g. to make legacy/portable C++ code accessible via web services etc.

I wonder if anybody has ever tried porting a real C++ codebase to C++/CLI, with all its extra syntax and differing semantics (arrays, ref/value types etc, references vs. pointers etc.)

Any experiences anybody?

Re: porting C++ to C++/CLI? by Andy Dent

I've used C++/CLI quite a bit in the last two years as an interop language where large chunks of the existing c++ code have just been dragged in and compiled. It works very well at that, much as Apple's hybrid of Objective-C and C++ allows you to mix the two languages.
You don't need to change the original C++ logic much or change your classes over to the new ref classes unless you're dealing with .Net interfaces and it's easy to have loops copy std strings and vectors to .Net types.

However, with WPF, the dependence on partial class generation needs a little work as WPF relies on being able to generate half a class declaration in a background file (for the controls and other members from XAML) and the rest in the "code behind file". There's a simple, if slightly ugly, C++ idiom that could fix this - just generate a large macro to be included in the code behind file's class declaration, that would expand to provide all the required definitions.

As I've written a code generator that goes from annotated XAML to generate pure XAML, C# and C++/CLI I know for certain this is feasible.

Re: porting C++ to C++/CLI? by Stefan Wenig

I guess I was not specific enough. Did you use /clr:safe to compile? Because otherwise, you're probably just creating unmanaged code via the normal C++ compiler backend. That won't run in Silverlight, WP7, Mono etc.
Unfortunately, if you turn it on, existing C++ code will most likely not compile. What I'd like to know is if anybody has ever tried to port a significant amount of code so that it would compile with /clr:safe.

Re: porting C++ to C++/CLI? by Andy Dent

No, just /clr because I'm creating mixed code. Some of my classes are pure C++/CLI, like a large XML reporting engine that is generating report files used externally by an XSL:FOP chain and internally with a WPF preview window directly binding to the XML (in C#). This is a good example of where I think C++/CLI fits as a language - being able to choose how much stays native and how much is new. I find using the ref-style classes very easy, only being a minor variation on style. That might be because I've used smart pointer idioms for over fifteen years so I'm used to not having many explicit deletes.

Frankly, unless you have problems with memory management, I don't see why you would port a large code base and rewrite it with ref classes.

I researched the Silverlight issue about 18 months ago and it wasn't confidence inspiring, for example forums.silverlight.net/forums/p/5329/16357.aspx says
Even if you take the utmost care to compile your C++ DLL with pure CLR, and you replace the normal references with Silverlight ones, Silverlight still gets upset when it tries to open the DLL because it contains references to MSVCRT90.dll, KERNEL32.dll, and MSVCR90.dll.

and

I just gave Silverlight&C++ it a try by compiling the MSIL from my C++ project into a Silverlight-compatible DLL. The good news: it works, and you can call this code from a Silverlight project. The bad news: The C++ compiler apparently uses MSIL instructions that Silverlight disallows.

So, if you try this, even with the simplest of programs, you'll almost immediately get the exception "Operation could destabilize the runtime." To me, this makes it seem less likely that we'll see Silverlight for C++ soon, as the compiler will need to behave quite a bit differently.

Re: porting C++ to C++/CLI? by Andy Dent

I forgot to mention that Stefan has now of course clarified the other big reason for converting your native C++ to C++/CLI - wanting to run it under anything other than .Net on Windows. stackoverflow.com/questions/2455372/windows-pho... is a good thread.

I wonder how much I pay? by Jim Leonardo

The win7 move makes smart business sense. Put another way: How much do I pay as a C# developer who buys MS tools for keeping VB.net alive? Consider that question both in concrete dollars for the tools and in opportunity cost as MS is diverting resources away from other projects to maintain something for maybe 10% of its developer audience.

Re: I wonder how much I pay? by Jim Leonardo

and I meant winphone7, not win7 ;)

Re: porting C++ to C++/CLI? by Stefan Wenig

the question is not "does c++/cli work with SL/WP7 today?"
sure, it is not supported, but it is easy to see that MS *could* support it - but only in the restricted /clr:safe mode. so the question remains:

does it make sense to port a large c++ codebase over to c++/cli?

or is the porting so much trouble that you might as well just rewrite it?

there's a lot of c++ that you can still do in /clr:safe mode, like templates or some pointer arithmetic.
but no MFC, no ATL, no 3rd party/OSS libs (Boost!) unless you port them too. STL is available, but only in a special version (freaky: combines generics & templates in a _very_ interesting way).

Re: I wonder how much I pay? by Jonathan Allen

According to past Microsoft reports, the VB audience is actually larger than the C# one. I suspect that VB is more popular with non-professionals than those like us, but its hard to say because there are countless IT-department programmers cranking out internal applications that we'll never see.