Tag Archives: .net

.net, microsoft, mobile, silverlight, software development, windows

A glimpse into the internal battles that set the future of Windows and .NET

16 Comments

A couple of posts from Hal Berenson give insight into the internal battles at Microsoft as the company worked out its strategy to rescue Windows from irrelevance in the world of mobile and tablets. Berenson is now President of True Mountain Group LLC but was formerly at Microsoft where his roles included SQL Server development and architecture, Mobile Development Tools strategy, and General Manager of Forefront identity and security products.

image

Berenson left Microsoft in October 2010, but by that time the strategy behind Windows 8 and Windows Phone 8 would have been in place.

According to Berenson, there were two core options for evolving Windows. There may have been others, but the heart of it is this: what to do with .NET. One option was to make .NET the app model for Windows, which is what was planned for the original Longhorn, before it was reset and became the less radical update that was Windows Vista. The other was to create a new app model based on native code. Steven Sinofsky, the Windows President, chose the latter, which is why .NET is only one of three options for programming the new tablet personality in Windows 8. This meant going down the opposite path from that of Windows Phone 7, which has an entirely .NET-based programming model.

You may recall from other sources that Steven Sinofsky has never been known to be a .NET fan.  While others within Microsoft, and even senior people in the (pre-Windows 8) Windows organization, wanted to move to an entirely .NET app model for Windows Steven did not.  He (and others fyi) wanted to re-engage the native code C++ developers that Microsoft had been neglecting.  And they wanted to co-opt the huge base of web developers to create apps for the Windows platform.  Well, what had the Windows Phone guys done?  They’d implemented a .NET only app platform.  Could the Windows Phone app platform evolve to address the native and web developers?  Sure.  But with no existing library of apps and a desire not to have .NET-centric platform at the core of Windows Sinofsky apparently felt pretty comfortable ignoring the Windows Phone team’s work.

This goes a long way to explain the puzzlement many of us experienced when it transpired that having created in Windows Phone 7 the basis for a touch-friendly operating system that could easily be extended to larger form factors such as tablets, Microsoft chose instead to do a new thing entirely for its tablet strategy.

One take on this is that Berenson’s account illustrates the chaos at Microsoft. Windows Phone was created in a mad hurry in reaction to the iPhone and the ascendance of touch UIs, reusing pieces of .NET, Silverlight and Zune to bring something to market quickly. Then the company’s next move was not to build on that, but to throw it away, even in the context of a mobile and device revolution that was and is a huge threat to its core business. And where was CEO Steve Ballmer in all of this?

The other take though is how this shows the determination and strategic focus of Windows boss Steven Sinofsky. He did not believe that rebuilding the Windows user interface on .NET would save it, with the Longhorn experiment no doubt a factor in that conviction, so he refused to go down that path again, despite the cost in terms of time and, perhaps more seriously, the impact on the developer ecosystem. Microsoft platform developers were asked first to bet on .NET and Silverlight, and now to bet on this new thing the Windows Runtime, and many are disillusioned or even angry. A hard decision; but putting long term strategy ahead of the immediate demands of your customers may be the right thing, in fact the only right thing.

Berenson also confirms what many of us have always assumed: that the removal of the Start menu on the Windows 8 desktop is all about making the new personality in Windows hard to avoid:

The Start menu, and indeed the entire desktop, are legacies that will have to be removed from Windows over time.  While the desktop itself is probably with us for a couple of additional major Windows releases (though there may be truly desktop-free editions sooner than that) the start menu was something that Steven has bet he could get away with not bringing forward into Windows 8.  By doing so he forces users to start living in the new usage paradigm rather than totally avoiding it.  Yes you can still set up a system to avoid leaving the desktop most of the time.  But you can’t avoid the new world completely.  In doing so he sets people up to eventually accept systems without the desktop at all (or at least Windows RT systems for personal use even if they need the desktop at work, for example).

Personally I no longer miss the Start menu; but its absence is certainly a barrier to adoption for Windows 8, as new users struggle to navigate the operating system.

Note: Berenson has kindly commented below. Note his point that merely working at Microsoft does not give you detailed knowledge of all decisions made there.

.net, development, microsoft, professional, software development, visual studio

Platform churn? If it is in Windows 8, we are committed to it says Microsoft

4 Comments

I interviewed Corporate VP of Microsoft’s developer division Soma Somasegar at the Visual Studio 2012 launch last week; see the article on the Register here. I asked about the inconsistency of the Microsoft platform, and the way the platform story has changed over the years (Win32, .NET, WPF, Silverlight and now Windows Runtime). Can developers trust in the longevity of today’s platform, especially on the client?

Here is what I thought was interesting about his reply:

Any technology you see shipping as part of Windows 8, we are very committed to that.

So what ships in Windows 8? Well, for reasons which are hard to discern for those of us outside Microsoft, Silverlight is not shipped in Windows 8. It is an optional download. In fact, the only plug-in installed by default is Adobe Flash:

image

No, that does not imply that Microsoft is committed to Flash; but it does suggest lack of commitment to Silverlight, which we knew.

What you do get though is .NET Framework 4.5. This is baked in and cannot be removed as far as I can tell, though you can add and remove some advanced features.

This means you also have Windows Presentation Foundation (WPF); and in fact Somasegar specifically refers to this alongside Win32 and the new Windows Runtime.

The inclusion of technology in a current Microsoft product has implications for its support lifecycle. The ancient Visual Basic runtime, for example, is still assured of a long life since it is part of Office 2013.

image

My guess is that Microsoft’s thinking goes something like this. Right now, as the October launch date of Windows 8 approaches, what Microsoft needs most urgently is a viable ecosystem for its new Windows Runtime environment. This, you will notice, is the focus of the forthcoming BUILD conference as so far announced.

image

What, though, of the Windows desktop, has Microsoft abandoned it as legacy? My guess is that we will get deliberately mixed messaging on the subject. On the one hand, Microsoft has relegated the desktop to a single tile in the new Start screen. On the other hand, most of us will spend most of our time in the desktop, not least developers who need it to run Visual Studio. If Microsoft succeeds in establishing the new Windows Runtime platform, it would not surprise me to see a little more love given to the desktop in, say, Windows 9.

Microsoft’s platform story is messy, without question, and especially so in mobile. We have seen Windows Mobile replaced by the incompatible Windows Phone 7, and now those loyal developers who invested in the Silverlight/XNA Windows Phone 7 technologies are finding that it is all change again in Windows Phone 8 and Windows 8 (though the exact details await the release of the Windows Phone SDK).

It seems clear though that the company’s current intent is that Windows Runtime evolves as the primary client platform for both phone and tablet, while desktop remains for legacy support and for applications that do not fit the new model, such as Visual Studio and (for the time being) Office.

What if Microsoft fails to establish the Windows Runtime as a popular app platform? All I can add is that I know of no Plan B.

.net, development, software development

Using Windows Runtime (WinRT) APIs from desktop applications

After trying out Windows 8 notifications from a Windows Forms application, I did a bit of research into using the Windows Runtime (WinRT) API from desktop applications.

It turns out that this is something Microsoft planned for:

Desktop apps should for the most part be able to use WinRT. This is an area where we should have more information moving forward.

says Microsoft’s David Lamb, in Developer Support. He was answering a question about the Proximity APIs.

How do you do it? In C/C++, according to Steve Harne:

For this to build, you’ll need to set the following compiler switches in the the C++ Win32 Console wizard generated project:

C/C++ / General Settings
    Enable Windows Runtime Extensions (/ZX)
    Additional #Using Directories (/AI) -> set this to "C:\Program Files (x86)\Windows Kits\8.0\Windows Metadata" (modify as per your installation)

C/C++ / Code Generation
    Disable Minimal Rebuild (/Gm-)  -> this is not compatible with /ZX

In .NET applications you can set a reference to Windows.winmd. This is a WinRT metadata file, which you can browse in the Visual Studio object browser.

image

You even get a short summary describing each class and class member.

Note that as Microsoft’s Larry Osterman explains here:

there is absolutely no (zero) il in the windows.winmd file – it’s a metadata-only assembly. This is important because winmd files only describe structure, they don’t contain code (note that the C# compiler can produce hybrid winmd files that also contain some code, this was to support certain C# scenarios)

While a lot of stuff works, there will be WinRT API calls that make no sense other than for real WinRT apps. It is also worth noting that all of this is specific to Windows 8 (and higher, I presume). Since most desktop apps will need to be compatible at least with Windows 7, this requires some care. Lamb also says:

WinRT APIs may be tied to Metro style apps, Desktop apps or potentially available to both. The documentation will list which environments (Desktop, Metro style or both) a given API works in.

and in fact you can see this in the documentation. For example, the docs for the ToastNotification class states:

Applies to: Metro style apps | desktop apps

image

whereas if you look at the ContactPickerUI class, it says:

Applies to: Metro style apps only

For those APIs where desktop use is supported, you can go right ahead.

.net, microsoft, professional, software development, visual studio

New Windows 8, new Visual Studio 2012

Microsoft has released the Release Candidate of Visual Studio 2012 (now the official name), which you can download here, to coincide with the release of Windows 8 Release Preview and Windows Server 2012 Release Preview.

Visual Studio also has a new logo, as you can see from the setup window below.

image

Microsoft’s Jason Zander has posted about the new release here. Some of the main areas of difference between the RC and the Beta are:

  • Better performance
  • User interface tweaks including the return of a little more colour to the product
  • Solution Explorer filtering
  • New Metro style app templates
  • Improved XAML and Blend designers
  • Updated ASP.NET 4.5 web forms to support the await keyword
  • Tweaks to LightSwitch, Team Foundation Server, Architectural Tools

There is also a more detailed post by Scott Hanselman on what’s new in web development here.

.net, javascript, professional

Convert .NET Intermediate Language to JavaScript

3 Comments

Whomever called JavaScript the assembly language of the web was a true prophet.

Compiling .Net code to JavaScript is not new. I have heard that Microsoft’s Office Web Apps, browser-hosted editing of Office documents, are built with Script#.

The difference with JSIL is that it compiles .NET Intermediate Language (IL), and therefore works with any .NET language – though note that:

JSIL is still in development. You will hit bugs

The screenshot says it all

image

.net, microsoft, professional, software development, visual studio, windows

A simple example of async and await in C# 5

10 Comments

I have been playing with the Visual Studio 11 developer preview and exploring its asynchronous features, specifically the async and await keywords which are new to C# 5.0. These features have actually been available as a CTP (Community Tech Preview) since October 2010, but I had not found time to try it.

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.

.net, microsoft, silverlight, software development

Reflections on Microsoft BUILD 2011

11 Comments

I’m just back from Microsoft’s BUILD conference at Anaheim in California, which lived up to the hype as a key moment of transition for the company. Some said it was the most significant PDC – yes, it was really the Professional Developers Conference renamed – since 2000, when .NET was introduced; some said the most significant ever.

image

“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.

.net, professional, silverlight, software development, windows

A few facts about Microsoft’s new Windows Runtime

25 Comments

I’ve just come out of Martyn Lovell’s talk on WinRT internals here at BUILD in Anaheim, California.

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.

.net, development, microsoft, mobile, mono, open source, professional, software development, visual studio, web authoring

The strategy behind Mono has shifted: ten years of open source .NET

Yesterday, SUSE and Xamarin announced, in effect, the transfer of all things Mono to Xamarin.

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:

image

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!

development, microsoft, mono, professional, silverlight, software, software development

C# vs C++ and .NET vs Mono vs Compact Framework performance tests

6 Comments

A detailed benchmark posted on codeproject investigates the performance of basic operations including string handling, hash tables, math generics, simple arithmetic, sorting, file scanning and (for C#) platform invoke of native code. These are the conclusions:

  • 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.