I like to keep examples as simple as possible. I have a Windows Forms application which has a long-running task to perform, and I do not want to lock the UI while it runs. Here is my long-running function:

 private int slowFunc(int a,int b)       
 {          
 System.Threading.Thread.Sleep(10000); 
 return a + b;
 }

Yes, it takes 10 seconds! I am going to click a button on a form, call the function, and show the result on a label control.

Now, here is how I might try to achieve the goal of not locking the UI using Visual Studio 2010 and C# 4.0:

 private void button1_Click(object sender, EventArgs e)
 {            
 this.button1.Enabled = false; //prevent re-entry 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2));
 this.label1.Text = "Result: " + someTask.Result.ToString(); //oops, blocks calling thread 
 this.button1.Enabled = true;       
 }

Oops, this did not work at all! The reason is that although I have gone to the trouble of creating a Task in order to run the slow function on a background thread, my work is undone when I call the Result property of the Task object – since this blocks the thread until the Task completes.

Here is how you can fix it in Visual Studio 2010 – remember, there is an easier way in C# 5.0 coming up soon:

 private void button1_Click(object sender, EventArgs e)        
 {
 this.button1.Enabled = false;          
 var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext(); //get UI thread context 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2)); //create and start the Task 
 someTask.ContinueWith(x =>     
   {                                          
   this.label1.Text = "Result: " + someTask.Result.ToString();   
   this.button1.Enabled = true;   
   }, uiScheduler  
  );        
 }

This one works. I click the button and the UI does not lock up at all; I can minimize the form, move it around the screen, and so on.

However, I have had to do some extra work. The ContinueWith method tells the Task to run some other code after the background thread has completed. By default this code will not run on the UI thread, which means it will raise an exception when it updates the UI, but you can pass in a TaskScheduler object so that it continues on the UI thread.

Now here is a look at the same problem using C# 5.0. The slowFunc is the same, so I will not retype it. Here is the code for the button click:

 private async void button1_Click(object sender, EventArgs e)
 {
 this.button1.Enabled = false; 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2)); 
 await someTask; 
 this.label1.Text = "Result: " + someTask.Result.ToString(); 
 this.button1.Enabled = true;
 }

Less code, same result, which is usually a good thing.

What is going on here though? First, the async modifier is added to the click event handler. This does not mean that the method runs asynchronously. It means that it contains code that will run asynchronously using await. As Eric Lippert explains, it tells the compiler to rewrite the method for you.

Second, there is the await keyword. I cannot improve on Lippert’s explanation so here it is:

The “await” operator … does not mean “this method now blocks the current thread until the asynchronous operation returns”. That would be making the asynchronous operation back into a synchronous operation, which is precisely what we are attempting to avoid. Rather, it means the opposite of that; it means “if the task we are awaiting has not yet completed then sign up the rest of this method as the continuation of that task, and then return to your caller immediately; the task will invoke the continuation when it completes.”

If you refer back to the Visual Studio 2010 examples, you will see that the code is very close to my first, non-working example. In other words,using await makes the code work in the way that intuitively I hoped that it might, without specifically called the ContinueWith method and messing around with the thread context as in the second example.

This is still concurrent programming though. One thing that C# 5.0 cannot prevent is an impatient user clicking several times on the button when the result does not appear immediately, so in all the examples I have disabled the button while the background thread runs.

Related posts:

1. Microsoft .NET gotchas revealed by Visual Studio team
2. Microsoft WebMatrix released: a simple editor for ASP.NET Razor and more, but who is the target user?
3. GPU Programming for .NET: Tidepowerd’s GPU.NET gets some improvements, more needed

“Significant” does not necessarily mean successful, and history will judge whether BUILD 2011 was a new dawn or the beginning of the end for Windows. Nevertheless, I have not heard so much cheering and whooping at a Microsoft conference for a while, and although I am no fan of cheering and whooping I recognise that there was genuine enthusiasm there for the new direction that was unveiled.

So what happened? First, let me mention the Windows Server 8 preview, which looks a solid upgrade to Server 2008 with a hugely improved Hyper-V virtualisation and lots of changes in storage, in IIS, networking, in data de-duplication, in modularisation (enabling seamless transition between Server Core and full Server) and in management, with the ascent of PowerShell scripting and recognition that logging onto a GUI on the server itself is poor practice.

The server team are not suffering the same angst as the client team in terms of direction, though the company has some tricky positioning to do with respect to Azure (platform) and Server 8 (infrastructure) cloud computing, and how much Microsoft hosts in its own datacentres and how much it leaves to partners.

What about Windows client? This is the interesting one, and you can almost hear the discussions among Microsoft execs that led them to create the Windows Runtime and Metro-style apps. There is the Apple iPad; there is cloud; there are smartphones; and Windows looks increasingly like a big, ponderous, legacy operating system with its dependence on keyboard and mouse (or stylus), security issues, and role as a fat client when the industry is moving slowly towards a cloud-plus-device model.

At the same time Windows and Office form a legacy that Microsoft cannot abandon, deeply embedded in the business world and the source of most of the company’s profits. The stage is set for slow decline, though if nothing else BUILD demonstrates that Microsoft is aware of this and making its move to escape that fate.

Its answer is a new platform based on the touch-friendly Metro UI derived from Windows Phone 7, and a new high-performance native code runtime, called Windows Runtime or WinRT. Forget Silverlight or WPF (Windows Presentation Foundation); this is a new platform in which .NET is optional, and which is friendly to all of C#, C/C++, and HTML5/JavaScript. That said, WinRT is a locked-down platform which puts safety and lock-in to Microsoft’s forthcoming Windows Store ahead of developer freedom, especially (and I am speculating a little) in the ARM configuration of which we heard little at BUILD.

BUILD attendees were given a high-end Samsung tablet with Windows 8 pre-installed, and in general the Metro-style UI was a delight, responsive and easy to use, and with some fun example apps, though many of the apps that will come as standard were missing and there was evidence of pre-beta roughness and instability in places.

The client strategy seems to me to look like this:

Windows desktop will trundle on, with a few improvements in areas like boot time, client Hyper-V, and the impressive Windows To Go that runs Windows from a bootable and bitlocker-encrypted USB stick leaving no footprint on the PC itself. Many Windows 8 users will spend all their time in the desktop, and I suspect Microsoft will be under pressure to allow users to stick with the old Start menu if they have no desire or need to see the new Metro-style side of Windows..

A new breed of Intel tablets and touch-screen notebooks will make great devices towards the high end of mobile computing. This is something I look forward to taking with me when I need to work on the road: Metro-style apps for when you are squashed in an aeroplane seat, browsing the web or checking a map, but full Windows only a tap away. These will be useful but slightly odd hybrids, and will tend to be expensive, especially as you will want a keyboard and stylus or trackpad for working in desktop Windows. They will not compete effectively with the iPad or Android tablets, being heavier, with shorter battery life, more expensive and less secure. They may compete well with Mac notebooks, depending on how much value Metro adds for business users mainly focused on desktop applications.

Windows on ARM, which will be mainly for Metro-style apps and priced to compete with other media tablets. This is where Microsoft is being vague, but we definitely heard at BUILD that only Metro-style apps will be available from the Windows Store for ARM, and even hints that there may be no way to install desktop apps. I suspect that Microsoft would like to get rid of desktop Windows on ARM, but that it will be too difficult to achieve that in the first iteration. One unknown factor is Office. It is obvious that Microsoft cannot rework full Office for Metro by this time next year; yet offering desktop Office will be uncomfortable and (knowing Microsoft) expensive on a lightweight, Metro-centric ARM device. Equally, not offering Office might be perceived as throwing away a key advantage of Windows.

Either way, Windows on ARM looks like Microsoft’s iPad competitor, safe, cloud-oriented, inexpensive, long battery life, and lots of fun and delightful apps, if developers rush to the platform in the way Microsoft hopes.

There are several risks for Microsoft here. OEM partners may cheapen the user experience with design flaws and low-quality add-ons. Developers may prove reluctant to invest in an unproven new platform. It may be hard to get the price down low enough, bearing in mind Apple’s advantage with enormous volume purchasing of components for iPad.

Still, one clever aspect of Microsoft’s strategy is that everyone with Windows 8 will have Metro, which means there will be a large installed base even if many of those users only really want desktop Windows.

I also wonder if this is an opportunity for Nokia, to use its hardware expertise to deliver excellent devices for Windows on ARM.

Finally, let me mention a few other BUILD highlights. Anders Hejlsberg spoke on C# and VB futures (though I note that there were few VB developers at BUILD) and I was impressed both by the new asynchronous programming support and the forthcoming compiler API which will enable some amazing new capabilities.

I also enjoyed Don Syme’s session on F#, where he focused on programming information rather than mere algorithms, and showed how the language can query internet data sources with IntelliSense and code hints in the IDE, inferred from schemas retrieved dynamically. You really need to watch his session to understand what this means.

In the end this was a great conference, with an abundance of innovation and though-provoking technology. In saying that, I do not mean to understate the challenges this huge company still faces.

Related posts:

1. A pivotal moment for Microsoft as it attempts to escape its Windows legacy
2. Building Windows – when Microsoft shows its hand
3. Windows Phone at Mix 2011: what Microsoft said and did not say

Make no mistake: Microsoft has re-invented the Windows API in WinRT. Just to recap, WinRT is the API for Metro-style applications, the touch-centric, app-centric API for tablets and, one presumes, eventually for Windows Phone (though Microsoft has yet to admit it).

WinRT is only useable from Metro applications. You cannot call WinRT from a Win32 application, nor vice versa*. I think it is reasonable to assume that a future version of Windows which runs only WinRT is a possibility; and that Windows 8 on ARM will look a bit like that even though Win32 will still be there, but mainly out of sight; but I am speculating.

Does that mean Win32 is now legacy? In a way, but such a huge legacy that for the moment we should think of Windows 8 as two platforms side by side.

There is no inter-app communication in WinRT other than by the pre-defined contracts built into the system (though Lovell noted that you could always use the file system and polling for a crude inter-process communication).

There is no way to install a shared dynamic library. Apps can only use the system libraries together with what you install with the app. Each app lives in its own context and is isolated. In other words, WinRT is not extensible, other than within your app’s code*.

If you figure out a way to bypass limitations of WinRT by calling other Windows APIs, your app might work but the submission process for the Windows Store will prohibit it.

Versioning is built into WinRT. This means that when Windows 9 comes along, you will be able to code just against the Windows 8 versions of the classes, for compatibility, and your IDE can support this by only exposing the Windows 8 version of the API.

The CLR exists in the Metro environment, for use by .NET applications, complete with JIT (Just in time) compilation. However only a subset of the .NET Framework libraries are included. Microsoft aimed to include only what was necessary for Metro. I am not sure yet what is included and what is not, beyond the obvious (no Windows Forms, for example) but will be investigating what is documented. The native WinRT APIs look similar to a COM callable wrapper from the .NET side. That said, you do not normally need to care about WinRT interfaces, even though these are there in WinRT. Normally you interact with WinRT classes, making it more natural for .NET than working with COM.

WinRT is full of asynchronous calls. Lovell told us that Microsoft had seen in the past that if both synchronous and asynchronous APIs are available for the same function, then developers often use the synchronous version even when they should not, making applications less responsive. The new await keyword in C# makes this easy to code.

WinRT makes use of the ILDasm metadata format which is also used by .NET. This means you get rich metadata for IntelliSense and debugging, but note that the actual runtime is not .NET; they just borrowed the same metadata format.

WinRT objects are reference counted like COM for memory management, with weak references to avoid circularity. You should not have to worry about this; you can code according to the conventions of your language.

There are three ways to write WinRT applications. One is C++, in which case you write directly to the “projection” of WinRT into your language. The second is .NET, in which case your code goes via the CLR. The third is HTML and JavaScript, in which case your code goes via the “Chakra” JavaScript engine also used by Internet Explorer 9 and higher. Lovell assured me that there is little difference in performance in most cases, though there could be advantages for C++ in certain niche scenarios. Of course we heard that story for .NET as well, but from what I have seen it is more plausible in WinRT.

There is no message loop in WinRT. There is no GDI in WinRT. All graphics are via DirectX. XNA, the .NET games framework, is not supported. It seems that you will need to use C++ for fancy DirectX coding, though this is not confirmed. Of course your XAML or Canvas code will be rendered by DirectX under the covers.

It is fascinating to see how Microsoft has borrowed XAML and ILDasm from .NET, but that WinRT is native and not .NET at its core. My take on this is that Microsoft intended to preserve the productivity of .NET, but without any performance compromise.

Despite the inclusion of .NET though, the fact that only a subset of the Framework is available, and that interop to the Windows API will not work*, means that most existing apps will need considerable work to be ported to Metro.

*Updates

A few clarifications.

It has been shown that you can call WinRT from Win32 (the favoured word for Win32 seems to be “desktop applications”) though I’m not sure how useful it is.

Concerning P/Invoke (Platform Invocation) to Win32 APIs, apparently this does work for a certain specified, small subset of the Windows API. It also works for your own native code DLL, with the proviso that if your native code DLL calls a disallowed Win32 API it will raise an error.

WinRT is partially extensible. A Framework Extension is a library which you can reference as a dependency in your app’s manifest. When the app is deployed it will download this dependency from the Windows Store. An example is the C Runtime Library. An extension library installs into its own directory, and can be used by multiple WinRT apps provided each one also references it in their manifests. However, the caveat is that only Microsoft can create these extensions: there is no way to create your own shared extension for general distribution, though an enterprise can deploy a shared extension internally.

Related posts:

1. Windows Runtime must come to Windows Phone
2. Windows 8 will run on ARM processors – a natural home for Silverlight?
3. Data Access in Windows 8 WinRT

The agreement grants Xamarin a broad, perpetual license to all intellectual property covering Mono, MonoTouch, Mono for Android and Mono Tools for Visual Studio. Xamarin will also provide technical support to SUSE customers using Mono-based products, and assume stewardship of the Mono open source community project.

Xamarin is a startup formed by Mono founder Miguel de Icaza following the acquisition of Novell and SUSE by Attachmate, which ceased Mono development.

Attachmate acquired Novell in November 2010. Mono has been plucked from the abyss with impressive speed.

That said, the strategy behind Mono has shifted. Mono exists because de Icaza liked what Microsoft announced back in 2000 when it introduced C# and the .NET Framework. Microsoft made a show of standardizing the .NET CLI (Common Language Infrastructure), which made PR sense at the time since there was controversy over Sun’s ownership of Java, though nobody really believed that Microsoft knew how to steward an open source development platform or indeed believed that it was really serious about it. History largely justifies that scepticism; but de Icaza called Microsoft’s bluff and forged ahead with Mono, implementing not only the CLI and C# but most of the .NET Framework as well.

The goal of Mono, as I recall, was to bring the benefits of C# and .NET to Linux developers, and to enable developers to move applications freely between Windows and Linux. Apple OS X was also on the radar, though it took longer to become much use. Recalling Mono’s early days, de Icaza said:

Mono to me is a means to an end: a technology to help Linux succeed on the desktop.

Mono worked remarkably well from quite early on, but never quite well enough to persuade mainstream developers it was a sensible choice for applications that would otherwise have run on Windows. It did emerge as a viable and productive toolset and platform for Linux and a number of Mono applications became popular, including Beagle search, Tomboy notes, and F-Spot photo management. Some ASP.NET applications run on Mono; I have one on this site. Another Mono success was its use as the scripting engine in Unity, a game development platform.

A big problem for Mono though was the lack of a business model. There was support and servicing of course, which must have generated some revenue for Novell, but most Mono use is free. Novell possibly had in mind that Mono could be significant as an application server, but it has never become a really trusted platform in the Enterprise. For example, as Alan Radding (Dancing Dinosaur) notes:

DancingDinosaur has not found any SUSE on z user that has successfully implemented .NET apps on the mainframe. A few have tried but reported that Mono on z wasn’t ready for prime time.

Even among the free software and open source community, Mono was hampered by suspicion of Microsoft. If Mono became successful enough to threaten Microsoft, would lawyers appear? Given the way Microsoft is currently behaving with Android, filing legal actions and signing up licensees, those fears might not be unwarranted.

So what is Mono today? The answer is that Mono is now primarily a mobile platform. The Xamarin home page makes this clear, as well as making it apparent that the Mono team has discovered the value of a business model:

Xamarin is tapping into two real business needs. One is the need for a cross-platform mobile development platform that works. The second is a way for Windows developers to use their existing C# skills for mobile development, given that they might not be happy with the tiny market share currently achieved by Windows Phone 7.

When I had a quick try with Monotouch I was impressed, and I would like to spend some more time with it and with Mono for Android.

Mono has touch competition though. In particular, PhoneGap, Appcelerator’s Titanium, and Adobe AIR. I was interested to see that Adobe is coming up with a packager for AIR on Android, which may significantly improve it as a cross-platform mobile toolkit.

Still, Xamarin is small and nimble and I expect it to succeed. It has also has Visual Studio integration, which is an advantage. One of the pieces Xamarin has now licensed from SUSE is Mono for Visual Studio.

The downside of these latest developments is that if you depend on Mono for the desktop or for ASP.NET, you may find these parts of the Mono project getting little attention from the new company. But Mobile is all that matters now, right?

I write this on July 19 2011. According to Wikipedia:

Recognizing that their small team could not expect to build and support a full product, they launched the Mono open source project, on July 19, 2001 at the O’Reilly conference.

Well, if there was a launch there it was low-key. It is not mentioned in this report. But de Icaza does recall:

We planned the announcement to come by July 19th 2001, so we could announce this at the O’Reilly conference, as Tim O’Reilly had been very supportive of this effort, and had offered his help since the early stages, when it was still a very young idea. When we announced the project launch we had our team in place, and we were shipping our metadata framework and our C# compiler as well as a few initial classes So officially the Mono project was launched on that date, but it had been brewing for a very long time.

Happy Anniversary!

Related posts:

1. Mono splits from Novell/Attachmate to form basis of new company
2. Mono project: no plans for cross-platform WPF
3. Miguel de Icaza on eight years of Mono, its future, and the Silverlight desktop

• There is only a small performance penalty for C# on the desktop versus C++.
• Mono is generally slower than Microsoft .NET but still acceptable, and all the benchmarks ran without modification.
• The Compact Framework, an implementation of .NET for mobile devices, performs poorly.

My observations: this matches my own experiments. Why then do some .NET applications still perform badly? When Evernote switched its application from .NET to native code it got much better performance.

The main reason is a couple of issues that this kind of benchmark hides. One is the GUI layer, which involves a ton of platform invoke code under the covers. Another is the large size of .NET applications because of the runtime and library overhead; a lot more stuff gets loaded into memory.

One thing to like about Silverlight is that it is truly optimized for client programming and load time tends to be faster than for a desktop .NET application.

Note that for mobile these benchmarks suggest that C++ still has a big advantage. It would be interesting to see them applied to Silverlight apps on Windows Phone 7. As I understand it, the Silverlight .NET runtime in Windows Phone 7 shares code with the Compact Framework on Windows Mobile, so it is possible that the poor results for the Compact Framework would also apply to Silverlight on Windows Phone 7. Unfortunately developers do not have the option for C++ on Windows Phone 7.

Related posts:

1. Mono project: no plans for cross-platform WPF
2. Windows Phone 7 incompatibility may drive developers elsewhere
3. Vista vs XP performance: some informal tests

Will Windows 8 support Silverlight and/or some other variety of .NET in its new touch-centric mode? I will be astonished if it does not. Aside from other considerations, this is an essential unifying piece between the Windows Phone 7 developer platform and the Windows 8 developer platform, which from what we have seen have a similar user interface. For further evidence, try an internet search for “Jupiter” and “appx”.

Why isn’t Microsoft already shouting about this? A good question. Part of the answer is that Microsoft wants to get developers enthused about the forthcoming build conference in September, and is holding back information.

Another part of the answer is that Windows historically has kept .NET as a layer above the operating system, rather than as part of it. We saw this in Windows 7, where to take advantage of new features like jump lists or thumbnail toolbars, .NET developers had to use a supplementary Windows API Code Pack. The Windows team delivered only native code or COM APIs.

Admittedly, there are differences this time around. The Windows team is not just delivering native code APIs, but also an HTML and JavaScript API. This is a break with the past, hence the talk of a new platform.

When it comes to desktop applications, would not Silverlight or something .NET based be a better choice than HTML5? I can see both sides of this. On one side is all the effort Microsoft has invested in .NET and Silverlight over the past decade. As I’ve noted before, I see Silverlight as what client-side .NET should have been from the beginning, lightweight, secure, simple installation, but with support for C# and much of the .NET Framework which developers know so well.

On the other hand, I can see Microsoft wanting to tap into the wave of HTML5 development and to make it easy for web developers to build apps for Windows 8.

In the end, developers will most likely have the choice. That puts pressure on Microsoft’s developer division to provide strong tools for two different development models; but I think that is what we will get.

Is .NET itself under threat? As far as I am aware, Microsoft has no plan “B” in terms of web and application server technology, and its Azure cloud is largely a .NET platform though there are are efforts to support other things like PHP and Java. Further, this aspect of the Microsoft Platform is under Server and Tools which is 100% behind .NET as far as I can tell. We have also seen Silverlight crop up in the user interfaces for new server products like InTune and System Center. On the server then, there is no evidence for .NET doubts at Microsoft; and considering the trend towards cloud+device computing the server is now at the heart of most business application development.

That said, Microsoft has challenges in sustaining .NET momentum. It cannot afford to fail with Azure, yet other platforms such as Amazon EC2 have greater developer mindshare as cloud computing platforms. VMWare with its Java-based Spring framework is another key competitor. Microsoft was late to the server virtualisation party with Hyper-V. I also see declining market share for IIS versus Apache in Netcraft’s statistics, although these figures are distorted by millions of little-used domains that get shunted from one platform to another by major hosting providers.

Further, it seems to me that the fortunes of .NET on the server cannot be completely separated from what happens on the client. One of the attractions of .NET is the integration between client and server, with Visual Studio as the tool for both. Windows has lost momentum to Apple in mobile, in tablets, and in high-end laptops, making Windows-only clients less attractive. In that context, the decision of the Windows team to favour HTML5 over .NET is a blow, in that it seems to concede that the future client is cross-platform, though I expect there will be some sort of outcry when we see all the proprietary hooks Microsoft has implemented to get HTML5 apps integrated into Windows 8.

Therefore these really are difficult times for .NET. I do not count Microsoft out though; it still dominates business computing, and amongst consumers the Xbox may prove an important new platform as Tom Warren notes.

While I have reservations about Windows 8, it does demo nicely as a new touch-centric operating system and Microsoft surely has chances in the corporate world with new-style tablets that integrate with its system management tools and which run Microsoft Office.

Finally, the angst over the role of .NET in Windows 8 shows that many developers actually like the platform, including Visual Studio, the C# language, the .NET Framework, and XAML for building a rich user interface.

Related posts:

1. More on Microsoft’s difficult choices: WPF, Silverlight, HTML 5
2. Microsoft refuses to comment as .NET developers fret about Windows 8
3. Microsoft promises Silverlight 5 beta soon, more love for HTML 5 in uncertain blog post

A quick search does not throw up any detailed accounts. Part of the problem is that much of it is internal Microsoft history, confidential at the time.

One strand, mentioned here, is Colusa’s OmniVM:

OmniVM was based on research carried out by Steven Lucco at Carnegie Mellon University. Steven co-founded Colusa Software in February 1994 in Berkeley, California. Omniware was released in August 1995. Colusa started working with Microsoft in February 1996. Microsoft acquired Colusa Software on March 12, 1996. Steven is currently a senior researcher at the Microsoft Bay Area Research Center.

OmniVM was appealing to Microsoft because Colusa had already created Visual Basic and C/C++ development environments for the VM. The VM was also claimed to be capable of running Java.

Microsoft took to calling the VM by the name of CVM, presumably for Colusa Virtual Machine. Or perhaps this is where the code name Cool came into being. Other names used at Microsoft include Universal Virtual Machine (UVM), and Intermediate Language (IL).

Microsoft’s Jason Zander, commenting to a story on this blog, does not mention OmniVM:

The CLR was actually built out of the COM+ team as an incubation starting in late 1996. At first we called it the "Component Object Runtime" or COR. That’s why several of the unmanaged DLL methods and environment variables in the CLR start with the Cor prefix.

Still, the timing pretty much matches. If Lucco came to Microsoft in 1996, he could have been part of an incubation project starting later that year.

In June 1999 Microsoft previewed the Common Executable Format for Windows CE:

A demonstration on Common Executable Format (CEF), a new compiler target within the Visual C++® development system for Windows CE, was also presented. This compiler enables cross-processor portability within a category of devices, such as Palm-size PCs or Handheld PCs. A single program executable under CEF is translated to the native code on either the host PC or the device, as desired. This capability eliminates the need for developers to recompile an application for every possible processor on a given Windows CE-based appliance before bringing it to market, thus enabling them to support every version of a device (Palm-size or Handheld PC) quickly and easily.

In 2000 I interviewed Bob Powell, then at Stingray, who told me this in relation to .NET:

There was an early version of the system for Windows CE called the Common Executable Format (CEF). The Pocket PC, which uses around seven different processor types, and which has many different versions of the operating system, is a deployment nightmare. This problem was addressed by the CEF, which was a test case. What is now in the IL is a more refined version of that.

Hmm, now that Windows is coming to ARM alongside x86, this sounds like it could be useful technology … though despite obvious similarities, I don’t think CEF was really an early version of the CLR. Maybe the teams communicated to some extent.

Now this is interesting and brings the story up to date. Lucco is still at Microsoft and apparently his team built Chakra, the new JavaScript engine introduced in Internet Explorer 9:

Steven E. Lucco is currently the chief architect for the Microsoft Browser Programmability and Tools (BPT) team. BPT builds the Internet Explorer’s Chakra Javascript script engine, as well as the Visual Studio tools for creating scalable, efficient Web client applications.

Right now, these are dark days for .NET, because Microsoft now seems to be positioning HTML and JavaScript as the new universal runtime.

It seems that the man who perhaps began the .NET Runtime is also at the centre of the technology that might overtake it.

Update: this post has prompted some discussion and the consensus so far is that the OmniVM acquisition probably had little to do with the technology that ended up as .NET. The one thing that is beyond doubt is that the COM team created the .NET CLR as Zander reported. I actually spoke to Zander at TechEd recently and we touched on his early days at Microsoft working with Scott Guthrie:

I was actually one of the original CLR developers. When Scott and I first started working together, he invented ASP.NET and my team invented the CLR.

The history is interesting and if the relevant people at Microsoft are willing to talk about it in more detail it is something I would love to write up – so if that is you, please get in touch!

Related posts:

1. Full circle for Microsoft database APIs as OLEDB for SQL Server is deprecated
2. How Microsoft’s Office Web Apps were written in C# and compiled to JavaScript, maybe
3. Fast JavaScript engine in Apple iOS 4.3 is in standalone Safari only, but why?

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface.

When Microsoft introduced IE9 with hardware-accelerated graphics, support for some key parts of HTML 5, and a new fast JavaScript engine, it was not only trying to recover ground in the browser wars. It also had in mind a new application runtime for Windows, for desktop as well as for web applications.

In order to achieve this, we can expect more hooks between the browser engine and the local operating system. There is potential security risk, but Microsoft of all companies will be sensitive to this and I would expect it to get the security right. The further implication is that some parts of a Windows HTML application will be Windows-specific. It is an “Embrace and extend” strategy, as I noted in this Register article back in September last year when former Silverlight product manager Scott Barnes broke the story of how the Windows team at Microsoft was favouring HTML and JavaScript above .NET.

The rationale for this is two-fold. First, I’m guessing that Microsoft thinks it will work better. Although .NET client apps are now commonplace, especially for custom business applications, problems like slow start-up and heavy memory requirements never really went away, though I would argue that in Silverlight they are almost eliminated.

Second, HTML and JavaScript is a universal programming platform. With the new model, any developer who can code a web page can also code a Windows app. Corporate VP Michael Angiulo said at Computex in Taipei:

Windows 8’s new application platform … is based on HTML 5, JavaScript and CSS, the most widely understood programming languages of all time. These languages form the backbone of the web, so that on day 1 when Windows 8 ships hundreds of millions of developers will already know how to build great apps for Windows 8.

These are both compelling arguments. Nevertheless, there are several reasons why making Windows an HTML platform might not be the instant hit that Microsoft will be hoping for. Here are a few:

• Microsoft’s Visual Studio is .NET oriented. It does have a web design tool, Expression Web, which is OK but still falls short compared to Adobe Dreamweaver. Web designers tend to use Dreamweaver anyway, thanks to Mac compatibility and integration with other Adobe tools. Even Dreamweaver is not great as an application development tool, as opposed to a web design tool. Tooling is a problem, and it is fair to say that whatever goodies Microsoft comes up with in this area will likely be a step back compared to what it already has for C# or C++.
• Standards are a mixed blessing if you are trying to sell an operating system. If Microsoft does such a good job of standards support that the same apps run with minor tweaks on an iPad and on Android, users may do just that. If Microsoft encumbers the standards with too many proprietary extensions, the universality of the platform is lost.
• Windows plus HTML and JavaScript sounds a lot like Palm/HP WebOS, which has gained favourable reviews but has yet to take off in terms of sales. Otherwise, Palm would not have been taken over by HP.
• The question of whether HTML and JavaScript will really take over app development is open. I certainly hear voices saying so. I interviewed Nitobi’s president André Charland, in charge of PhoneGap, and he makes a good case. On the other hand, App development today is still dominated by platform-specific development, Objective C for Apple iOS and Java on Dalvik, the Google Android virtual machine.
• The standard in HTML/JavaScript app platforms is not Microsoft’s Internet Explorer, but WebKit, as used in iOS and in Google Android and Chrome. Microsoft did great work in standards support in IE9, but so far it has not stopped its browser share decline. Worldwide figures from StatCounter show Internet Explorer in continuing slow decline overall, and Chrome still growing and set to overtake Firefox in a year or so.

In other words, there is little evidence that embracing HTML and JavaScript as an app platform will ensure success for Windows 8.

That said, other factors count for more. Developers will go where their customers are, and if Microsoft turns out a version of Windows that wins substantial market share in the emerging tablet market as well as on traditional notebooks, the new platform will be a hit.

The risk though is that the market will continue to perceive Windows as an OS for desktop and laptop, and look to iOS or Android for mobile and touch devices. The dual personality of Windows 8 may count against it, if it means devices that are compromised by having to support both user interface models.

Related posts:

1. Windows Phone 8 will run Windows 8, with Silverlight centre stage?
2. Silverlight versus HTML, Flash – Microsoft defends its role
3. Mono project: no plans for cross-platform WPF

At D9 Microsoft showed that Windows 8 has a dual personality. In one mode it has a touch-centric user interface which is an evolved version of what is on Windows Phone 7. In another mode, just a swipe away, it is the old Windows 7, plus whatever incremental improvements Microsoft may add. Let’s call it the Tiled mode and the Classic mode.

Pretty much everything that runs on Windows today will likely still run on Windows 8, in its Classic mode. However, the Tiled mode has a new development platform based on HTML and JavaScript, exploiting the rich features of HTML 5, and the fast JavaScript engine and hardware acceleration in the latest Internet Explorer.

Although D9 is not a developer event, Microsoft did talk specifically about this aspect. Here is the press release:

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface. There’s much more to the platform, capabilities and tools than we showed today.

Program Manager Jensen Harris says in the preview video:

We introduced a new platform based on standard web technologies

Microsoft made no mention of either Silverlight or .NET, even though Silverlight is used as the development platform in Windows Phone 7, from which Windows 8 Tiled mode draws its inspiration.

The fear of .NET developers is that Microsoft’s Windows team now regards not only Silverlight but also .NET on the client as a legacy technology. Everything will still run, but to take full advantage of Tiled mode you will need to use the new HTML and JavaScript model. Here are a couple of sample comments. This:

My biggest fears coming into Windows 8 was that, as a mostly WPF+.NET developer, was that they would shift everything to Silverlight and leave the FULL platform (can you write a Visual Studio in Silverlight? of course not, not designed for that) in the dust. To my utter shock, they did something much, much, much worse.

and this:

We are not Windows developers because we love Windows. We put up with Windows so we can use C#, F# and VS2010. I’ve considered changing the platform many times. What stops me each time is the goodness that keeps coming from devdiv. LINQ, Rx, TPL, async – these are the reasons I’m still on Windows.

Underlying the discussion is that developers have clients, and clients want applications that run on a platform with a future. Currently, Microsoft is promoting HTML and JavaScript as the future for Windows applications, putting every client-side .NET developer at a disadvantage in those pitches.

What is curious is that the developer tools division at Microsoft, part of Server and Tools, has continued to support and promote .NET; and in fact Microsoft is soon to deliver Visual Studio LightSwitch, a new edition of Visual Studio that generates only Silverlight applications. Microsoft is also using Silverlight for a number of its own web user interfaces, such as for Azure, System Center and Windows InTune, as noted here.

Now, I still expect that both Silverlight and native code, possibly with some new XAML-based tool, will be supported for Windows 8 Tiled mode. But Microsoft has not said so; and may remain silent until the Build conference in September according to .NET community manager Pete Brown:

You all saw a very small technology demo of Windows 8, and a brief press release. We’re all being quiet right now because we can’t comment on this. It’s not because we don’t care, aren’t listening, have given up, or are agreeing or disagreeing with you on something. All I can say for now is to please wait until September. If we say more before then, that will be great, but there are no promises (and I’m not aware of any plans) to say more right now. I’m very sorry that there’s nothing else to share at the moment. I know that answer is terrible, but it’s all that we can say right now. Seriously.

While this is clearly not Brown’s fault, this is poor developer communication and PR from Microsoft. The fact that .NET and Silverlight champion Scott Guthrie is moving to Windows Azure is no comfort.

The developer division, and in fact the whole of Server and Tools, has long been a bright spot at Microsoft and among its most consistent performers. The .NET story overall includes some bumps, but as a platform for business applications it has been a remarkable success. The C# language has evolved rapidly and effectively under the guidance of Technical Fellow Anders Hejlsberg. It would be bewildering if Microsoft were to turn its back on .NET, even if only on the client.

In fact, it is bewildering that Microsoft is being so careless with this critical part of its platform, even if this turns out to be more to do with communication than technical factors.

From the outside, it still looks as if Microsoft’s server and tools division is pulling one way, and the Windows team the other. If that is the case, it is destructive, and something CEO Steve Ballmer should address; though I imagine that Steven Sinofsky, the man who steered Windows 7 to launch so successfully, is a hard person to oppose even for the CEO.

Update: Journalist Mary Jo Foley has posted on what she “hears from my contacts” about Jupiter:

Jupiter is a user interface library for Windows and will allow developers to build immersive applications using a XAML-based approach with coming tools from Microsoft. Jupiter will allow users a choice of programming languages, namely, C#, Visual Basic and C++.

Jupiter, presuming her sources are accurate, is the managed code platform for the new Windows shell – “Tiled mode” or “Tailored Apps” or “Modern Shell – MoSH”; though if that is the case, I am not sure whether C++ in this context will compile to managed or unmanaged code. Since Silverlight is already a way to code using XAML, it is also not clear to me whether Jupiter is in effect a new Windows-only version of Silverlight, or yet another approach.

Related posts:

1. Where is Microsoft going with its Rich Client API? Microsoft drops some clues as developers fret
2. Windows Phone 8 will run Windows 8, with Silverlight centre stage?
3. Windows Phone 7 incompatibility may drive developers elsewhere

Today Mono leader Miguel de Icaza has revealed new plans. In a blog post, he announces Xamarin, a new company focused on Mono. This company will build new commercial .NET tools for Apple iOS and Google Android, to enable .NET development on those platforms. Note that they will not be called MonoTouch and MonoDroid, the Novell offerings for this, but will be “source compatible”. I am sure there are brand and intellectual property ownership issues here; but de Icaza is no stranger to negotiating tricky issues of this kind, bearing in mind Mono’s relationship with Microsoft .NET. However I am not sure why the new company cannot acquire the existing brands, since it seems that Attachmate will no longer be able to support them.

The plans are not exactly new, but have been forced by Attachmate’s decision to lay off the entire Mono team:

We have been trying to spin Mono off from Novell for more than a year now. Everyone agreed that Mono would have a brighter future as an independent company, so a plan was prepared last year.

To make a long story short, the plan to spin off was not executed. Instead on Monday May 2nd, the Canadian and American teams were laid off; Europe, Brazil and Japan followed a few days later. These layoffs included all the MonoTouch and MonoDroid engineers and other key Mono developers.

Apparently Xamarin has “angel funding” but is looking for more.

The advent of MonoTouch and MonoDroid has been good for Mono, since it gives the project a stronger business model than it had previously. These mobile platforms are hot, and the ability to code for them in C# is great for Microsoft Platform developers. This factor could enable Xamarin to succeed.

On the other hand, Novell’s name gave Mono enterprise credibility as well as the backing of a large company, and these it now lacks.

The curious thing is that Mono is valuable to Microsoft. The company seems at times to hate Mono, because it removes the need for Windows, and at other times to love it, because it extends the breadth of .NET to include Linux and now iOS and Android. Microsoft gave some sort of official status to Moonlight, the Mono implementation of Silverlight, though the company’s support for Moonlight has always seemed hesitant.

So can we expect now that the company which can afford $8.5 billion for Skype, could expend a few million in support of Xamarin? Or will it stand by and hope that Mono fades away?

I have no idea, though I would like to see both Mono and Xamarin succeed. It is no threat to Microsoft, but does take .NET to places that Microsoft will never support. Without Mono, C# is merely a language for programming Windows.

Related posts:

1. The strategy behind Mono has shifted: ten years of open source .NET
2. Mono project: no plans for cross-platform WPF
3. Trying out MonoTouch – C# for Apple’s iPhone and iPad