Tag Archives: .net

Red Gate to charge for .NET Reflector, runs into storm of protest

Tools company Red Gate is to discontinue the free version of .NET Reflector, a popular tool for debugging and decompiling .NET code.

image

The tool itself is amazing. It takes advantage of the fact that .NET code is not compiled to native code until runtime. The code that is distributed is in .NET “intermediate language”, which means it can easily be decompiled. Reflector makes this as easy as opening a file. This is invaluable for debugging when you do not have the original source code, though a further implication is that if you want to protect your source code you need to obfuscate it.

Reflector was created by Lutz Roeder, who shared it freely with the community. In 2008 Roeder sold Reflector to Red Gate, stating:

Red Gate will continue to provide the free community version and is looking for your feedback and ideas for future versions.

Red Gate developed Visual Studio integration and some further features, offering a free version as well as a paid-for premium edition. Now it has decided this is no longer viable. Watch this video as distinctly uncomfortable CEO Simon Galbraith answers the question “Didn’t we promise that Reflector was always going to be free?”:

Right now owning Reflector doesn’t make commercial sense. Further development of Reflector doesn’t make commercial sense. Reflector’s a tool that needs to stay up to date. We need to spend money on it. At the moment we can’t do so in a commercially justifiable way.

We’re really regretful that we ever made such a statement that we were going to try not to charge for it. In hindsight we wish we hadn’t done that. It was never a promise by the way. Two years ago we thought we could make a success of it without having to charge for it, it turns out that wasn’t the case.

Galbraith says that Red Gate had expected two benefits from Reflector: sales of other tools to Reflector users, and up-sell to the premium version. Neither has really happened, he says, adding:

We know that people are going to be cross with us.

What has particularly annoyed users in the feedback forum is that the existing free version is time-bombed, and will expire on May 30th. So users will be forced to upgrade.

i have been a happy (paying) customer of red-gate for some time now – sql tools, .net tools.
i have told many other developers of your products – happy to explain how good they are and how awesome red-gate is.
i won’t be doing that any more. IMO you have managed to destroy your company reputation such that purely on principle i won’t be recommending you to anyone anymore.

says one user.

Reflector has actually been time-bombed for years. I have a download from 2008, and if I run it I get this message:

image

If I click Yes, I am told that automatic update is impossible and directed to the Red Gate download page. If I click No, the dialog closes. In either case, the Reflector executable deletes itself. This is not so bad if you can download another free version; but following the change of policy that will not be the case.

Red Gate might not have made money from Reflector, but now it has the opposite problem: bad PR because of withdrawing an existing and popular free tool.

The price for the new Reflector will be just $35.00; not much for such as useful tool. There is nothing wrong with a software company charging for its work. This is a difficult transition though, and the question is: would Red Gate have been better off releasing Reflector back to the community and ceasing its own investment, rather than making a renewed effort to make it a viable commercial product?

How Microsoft’s Office Web Apps were written in C# and compiled to JavaScript, maybe

While researching another product I came across this 2009 tweet from Microsoft’s Nikhil Kothari:

Office 2010 web apps – perhaps one of the most ambitious script# projects!

Script# is loosely equivalent to the Google Web Toolkit, but whereas GWT compiles Java to JavaScript, Script# compiles C# to JavaScript. According to the site:

Script# is used extensively by developers within Microsoft building Ajax experiences in Windows Live, Office to name just a couple, as well as by a external developers and companies including Facebook.

I had come across the project before, but was waiting to see if would evolve beyond what looks like a personal project for Kothari. It is hosted on http://projects.nikhilk.net rather than on an official Microsoft domain, and the latest release is 0.6.2. In other words, it does not have the look of a project that you would recommend for production work, interesting though it is. Nor is there much public activity around Script# that I can see, though there is a CodePlex site dedicated to improving its JQuery support.

Seeing Kothari’s tweet though raises several questions.

  • Did Microsoft really use it for Office Web Apps, a high profile project which is a key part of Microsoft’s cloud computing strategy?
  • Is there another, more up-to-date version of Script# that is used internally and which may one day burst into the public arena?
  • How might it impact the Silverlight vs HTML5 debate, if Microsoft comes up with a C# to JavaScript compiler in Visual Studio that lets developers code in .NET but deploy to cross-platform JavaScript?

I am sure there are readers of this blog who know more than I do, so by all means let me know.

Adobe AIR is user-hostile compared to native apps says BankSimple CTO

Alex Payne, CTO at BankSimple, has written an analysis of Adobe AIR from the user’s perspective. The scenario: his team was looking for a an alternative to Campfire for group chat, and selected HipChat. They liked the features of HipChat, but not the desktop app, which is built using Adobe AIR:

My team experienced a number of the usual problems one has with AIR applications: lousy performance, odd interface bugs, key combinations and UI elements that didn’t conform to our operating system. AIR apps exist in an uncanny valley between a web application and a desktop application, and the result is unsettling and annoying. Pretty soon, we were itching to go back to Campfire (via the native Mac client Propane), even though HipChat has better features and the promise of improved reliability.

Payne investigated further and came to the conclusion that users prefer native apps; and that cross-platform toolkits are for the benefit of software companies not users. Echoes of Steve Jobs’ Thoughts on Flash:

Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps.

And lest you think this is bad for AIR but good for Java, note that Payne adds:

For anyone who used a computer in the 1990s, AIR probably brings back scarring memories of Java apps: slow, ugly, inconsistent, awkward.

I was also reminded of Evernote’s experience with .NET versus native code, which I blogged here.

Payne is not all wrong, neither is Jobs. That said, the distinction between what is good for users and what is good for developers is not absolute. Maintaining a single cross-platform code-base, for example, is good for both users and developers, because it reduces bugs and assists feature-compatibility across platforms. It is also good for users of minority platforms who might otherwise have nothing.

Another question: how many of the issues Payne identifies are inherent to using AIR (or another cross-platform runtime), and how many are implementation issues? It is impossible to know without drilling into the details; but I don’t believe that all AIR (or Java, or .NET) apps have “lousy performance”.

It is true that ActionScript code is slower than Java or .NET code, and much slower than compiled C/C++, but speed of script execution is not always the performance bottleneck that users will notice most.

This is seemingly one of those never-ending computing debates; but a post like Payne’s is a reminder that neither Adobe AIR, nor any cross-platform runtime, is a perfect solution to the challenge of multiple client platforms.

Windows 8 will run on ARM processors – a natural home for Silverlight?

Microsoft announced today at CES in Las Vegas that the next version of Windows will run on ARM as well as Intel CPUs. But why? The reason is that ARM CPUs have huge momentum in mobile computing, thanks to their low power consumption. Microsoft wants Windows to support System on a Chip (SoC) architectures such as NVIDIA’s Tegra 2, which has two ARM Cortex-A9 CPUs combined with an HD-capable graphics processor in a single package. In its press release, the company is careful not to upset established x86/x64 partners Intel and AMD too much, emphasising that Windows will run on SoC packages based on those CPUs as well.

It is an interesting announcement, but one that raises as many questions as answers. The first concerns Microsoft’s mobile strategy, with Windows now seeming to encroach on territory that you have thought belonged to its embedded operating system, Windows CE, which underlies both Windows Mobile and Windows Phone 7. With all its legacy APIs, full-blown Windows does not seem ideal for low-powered, resource-constrained mobile devices; yet the company seems set on bringing full Windows rather than something based on Windows Phone 7 to the emerging tablet market.

The second issue is that applications will need at least re-compiling, and in many cases some re-coding, in order to run on ARM CPUs. Microsoft says it will deliver Office for ARM:

Sinofsky: Microsoft Office is an important part of customers’ PC experience and ensuring it runs natively on ARM is a natural extension of our Windows commitment to SoC architectures.

Windows and Office alone is enough for a decent business device; but customers who buy Windows on ARM expecting their existing games or applications to run will be disappointed.

We have been here before. In the early days of Windows CE, devices ran a variety of processors such as MIPS or Hitachi SH3, and developers had to compile multiple binaries and create setups that installed the right one on each device. In an attempt to overcome the friction this created, Microsoft introduced the Common Executable Format (CEF) with Windows CE 3.0 in 2000. This was an intermediate language format which was translated to native code by a “translator” when it was installed onto a device.

It sounds  a bit like .NET or Java; and it was indeed a forerunner of the .NET Common Language Runtime, which appeared in 2002. However, CEF never really caught on. Although it solved deployment issues, it introduced performance problems and was troublesome to debug. Most developers preferred to stick with true native code.

Today though .NET is mature; and we also have Silverlight, a cross-platform implementation of the .NET Framework combined with multimedia player and graphics framework. If Microsoft includes .NET and Silverlight in its ARM build of Windows, that would solve some of the deployment problems, especially for business devices. Many custom applications are built for .NET; and these would in principle run without any need to recompile, since a .NET executable is intermediate code which is compiled to native code at runtime, though any code which includes “platform invoke” calls to native APIs would not work.

It is surprising therefore that neither .NET nor Silverlight is mentioned in Windows president Steve Sinofsky’s Q&A about Windows on ARM. Still, we should not read too much into that. It would be madness if Microsoft did not support its .NET technologies on this new platform, would it not?

Single sign-on from Active Directory to Windows Azure: big feature, still challenging

Microsoft has posted a white paper setting out what you need to do in order to have users who are signed on to a local Windows domain seamlessly use an Azure-hosted application, without having to sign in again.

I think this is a huge feature. Maintaining a single user directory is more secure and more robust than efforts to synchronise a local directory with a cloud-hosted directory, and this is a point of friction when it comes to adopting services such as Google Apps or Salesforce.com. Single sign-on with federated directory services takes that away. As an application developer, you can write code that looks the same as it would for a locally deployed application, but host it on Azure.

There is also a usability issue. Users hate having to sign in multiple times, and hate it even more if they have to maintain separate username/password combinations for different applications (though we all do).

The white paper explains how to use Active Directory Federation Services (ADFS) and Windows Identity Foundation (WIF, part of the .NET Framework) to achieve both single sign-on and access to user data across local network and cloud.

image

The snag? It is a complex process. The white paper has a walk-through, though to complete it you also need this guide on setting up ADFS and WIF. There are numerous steps, some of which are not obvious. Did you know that “.NET 4.0 has new behavior that, by default, will cause an error condition on a page request that contains a WS-Federation authentication token”?

Of course dealing with complexity is part of the job of a developer or system administrator. Then again, complexity also means more to remember and more to troubleshoot, and less incentive to try it out.

One of the reasons I am enthusiastic about Windows Small Business Server Essentials (codename Aurora) is that it promises to do single sign-on to the cloud in a truly user-friendly manner. According to a briefing I had from SBS technical product manager Michael Leworthy, cloud application vendors will supply “cloud integration modules,” connectors that you install into your SBS to get instant single sign-on integration.

SBS Essentials does run ADFS under the covers, but you will not need a 35-page guide to get it working, or so we are promised. I admit, I have not been able to test this feature yet, and aside from Microsoft’s BPOS/Office 365 I do not know how many online applications will support it.

Still, this is the kind of thing that will get single sign-on with Active Directory widely adopted.

Consider FaceBook Connect. Register your app with Facebook; write a few lines of JavaScript and PHP; and you can achieve the same results: single sign-on and access to user account information. Facebook knows that to get wide adoption for its identity platform it has to be easy to implement.

On Microsoft’s platform, another option is to join your Azure instance to the local domain. This is a feature of Azure Connect, currently in beta.

Are you using ADFS, with Azure or another platform? I would be interested to hear how it is going.

What you are saying about the Java crisis

A week or so ago I posted about the Java crisis and what it means for developers. The post attracted attention both here and later on The Guardian web site where it appeared as a technology blog. It was also picked up by Reddit prompting a discussion with over 500 posts.

So what are you saying? User LepoldVonRanke takes a pragmatic view:

I’d much rather have Java given a purpose and streamlined from a central authoritative body with a vision, than a community-run egg-laying, wool-growing, milk-giving super cow pig-sheep, that runs into ten directions at the same time, and therefore does not go anywhere. The Java ship needs a captain. Sun never got a good shot at it. There was always someone trying to wrestle control over Java away. With the Oracle bully as Uberfather, maybe Java has a place to go.

which echoes my suggestion that Java might technically be better of under more dictatorial control, unpalatable though that may be. User 9ren is sceptical:

Theoretically, the article is quite right that Java could advance faster under Oracle. It would be more proprietary, and of course more focussed on the kinds of business applications that bring in revenue for Oracle. It would be in Oracle’s interest; and the profit motive might even be a better spur than Sun had.

But – in practice – can they actual execute the engineering challenges?

Although Oracle has acquired many great software engineers (eg. from Sun, BEA Systems, many others), do they retain them? Does their organizational structure support them? And is Oracle known for attracting top engineering talent in general?

In its formation, Oracle had great software engineers (theirs was the very first commercial relational database, a feat many thought impossible). But that was 40 years ago, and now it’s a (very successful) sales-driven company.

There’s an important point from djhworld:

Java is hugely popular in the enterprise world, companies have invested millions and millions of pounds in the Java ecosystem and I don’t see that changing. Many companies still run Java 1.4.2 as their platform because it’s stable enough for them and would cost too much to upgrade.

The real business world goes at its own pace, whereas tech commentators tend to focus on the latest news and try to guess the future. It is a dangerous disconnect. Take no notice of us. Carry on coding.

On Reddit, some users focused on my assertion that the C# language was more advanced than Java. Is it? jeffcox111 comments:

I write in C# and Java professionally and I have to say I prefer C# hands down. Generics are very old news now in .Net. Take a look at type inference, lambdas, anonymous types, and most of all take a look at LINQ. These are all concepts that have been around for 3 years now in .Net and I hate living without them in Java. With .Net 5 on the horizon we are looking forward to better asynchronous calling/waiting and a bunch of other coolness. Java was good, but .Net is better these days.

and I liked this remark on LINQ:

I remember my first experience with LINQ after using C# for my final-year project (a visual web search engine). I asked a C# developer for some help on building a certain data structure and the guy sent me a pseudocode-looking stuff. I thanked him for the help and said that I’d look to find a way to code it and he said "WTF, I just gave you the code".

From there on I’ve never looked back.

Another discussion point is write once – run anywhere. Has it ever been real? Does it matter?

The company I work for has a large Java "shrinkwrap" app. It runs ok on Windows. It runs like shit on Mac, and it doesn’t run at all on Linux.

write once, run anywhere has always been a utopian pipe dream. And the consequence of this is that we now have yet another layer of crap that separates applications from the hardware.

says tonymt, though annannsi counters:

I’ve worked on a bunch of Java projects running on multiple unix based systems, windows and mac. GUI issues can be a pain to get correct, but its been fine in general. Non-GUI apps are basically there (its rare but I’ve hit bugs in the JVM specific to a particular platform)

Follow the links if you fancy more – I’ll leave the last word to A_Monkey:

I have a Java crisis every time I open eclipse.

The Java crisis and what it means for developers

What is happening with the Java language and runtime? Since Java passed into the hands of Oracle, following its acquisition of Sun, there has been a succession of bad news. To recap:

  • The JavaOne conference in September 2010 was held in the shadow of Oracle OpenWorld making it a less significant event than in previous years.
  • Oracle is suing Google, claiming that Java as used in the Android SDK breaches its copyright.
  • IBM has abandoned the Apache open source Harmony project and is committing to the Oracle-supported Open JDK. Although IBM’s Sutor claims that this move will “help unify open source Java efforts”, it seems to have been done without consultation with Apache and is as much divisive as unifying.
  • Apple is deprecating Java and ceasing to develop a Mac-specific JVM. This should be seen in context. Apple is averse to runtimes of any kind – note its war against Adobe Flash – and seems to look forward to a day when all or most applications delivered to Apple devices come via the Apple-curated and taxed app store. In mitigation, Apple is cooperating with the OpenJDK and OpenJDK for Mac OS X has been announced.
  • Apache has written a strongly-worded blog post claiming that Oracle is “violating their contractual obligation as set forth under the rules of the JCP”, where JCP is the Java Community Process, a multi-vendor group responsible for the Java specification but in which Oracle/Sun has special powers of veto. Apache’s complaint is that Oracle stymies the progress of Harmony by refusing to supply the test kit for Java (TCK) under a free software license. Without the test kit, Harmony’s Java conformance cannot be officially verified.
  • The JCP has been unhappy with Oracle’s handling of Java for some time. Many members disagree with the Google litigation and feel that Oracle has not communicated well with the JCP. JCP member Doug Lea stood down, claiming that “the JCP is no longer a credible specification and standards body”. Another member, Stephen Colebourne, has a series of blog posts in which he discusses the great war of Java and what he calls the “unravelling of the JCP”, and recently  expressed his view that Oracle was trying to manipulate the recent JCP elections.

To set this bad news in context, Java was not really in a good way even before the acquisition. While Sun was more friendly towards open source and collaboration, the JCP has long been perceived as too slow to evolve Java, and unrepresentative of the wider Java community. Further, Java’s pre-eminence as a pervasive cross-platform runtime has been reduced. As a browser plug-in it has fallen behind Adobe Flash, the JavaFX initiative failed to win wide developer support, and on mobile it has also lost ground. Java’s advance as a language has been too slow to keep up with Microsoft’s C#.

There are a couple of ways to look at this.

One is to argue that bad news followed by more bad news means Java will become a kind of COBOL, widely used forever but not at the cutting edge of anything.

The other is to argue that since Java was already falling behind, radical change to the way it is managed may actually improve matters.

Mike Milinkovich at the Eclipse Foundation takes a pragmatic view in a recent post. He concedes that Oracle has no idea how to communicate with the Java community, and that the JCP is not vendor-neutral, but says that Java can nevertheless flourish:

I believe that many people are confusing the JCP’s vendor neutrality with its effectiveness as a specifications organization. The JCP has never and will never be a vendor-neutral organization (a la Apache and Eclipse), and anyone who thought it so was fooling themselves. But it has been effective, and I believe that it will be effective again.

It seems to me Java will be managed differently after it emerges from its crisis, and that on the scale between “open” and “proprietary” it will have moved towards proprietary but not in a way that destroys the basic Java proposition of a free development kit and runtime. It is also possible, even likely, that Java language and technology will advance more rapidly than before.

For developers wondering what will happen to Java at a technical level, the best guide currently is still the JDK Roadmap, published in September. Some of its key points:

  • The open source Open JDK is the basis for the Oracle JDK.
  • The Oracle JDK and Java Runtime Environment (JRE) will continue to be available as free downloads, with no changes to the existing licensing models.
  • New features proposed for JDK 7 include better support for dynamic languages and concurrent programming. JDK 8 will get Lambda expression.

While I cannot predict the outcome of Oracle vs Google or even Apache vs Oracle, my guess is that there will be a settlement and that Android’s momentum will not be disrupted.

That said, there is little evidence that Oracle has the vision that Sun once had, to make Java truly pervasive and a defence against lock-in to proprietary operating systems. Microsoft seems to have lost that vision for .NET and Silverlight as well – though the Mono folk have it. Adobe still has it for Flash, though like Oracle it seems if anything to be retreating from open source.

There is therefore some sense in which the problems facing Java (and Silverlight) are good for .NET, for Mono and for Adobe. Nevertheless, 2010 has been a bad year for write once – run anywhere.

Update: Oracle has posted a statement saying:

The recently released statement by the ASF Board with regard to their participation in the JCP calling for EC members to vote against SE7 is a call for continued delay and stagnation of the past several years. We would encourage Apache to reconsider their position and work together with Oracle and the community at large to collectively move Java forward.  Oracle provides TCK licenses under fair, reasonable, and non-discriminatory terms consistent with its obligations under the JSPA.   Oracle believes that with EC approval to initiate the SE7 and SE8 JSRs, the Java community can get on with the important work of driving forward Java SE and other standards in open, transparent, consensus-driven expert groups.   This is the priority.   Now is the time for positive action.  Now is the time to move Java forward.

to which Apache replies succinctly:

The ball is in your court. Honor the agreement.

Microsoft pledges commitment to Silverlight – but is it enough?

Microsoft’s president of Server and Tools Bob Muglia has posted a response to the widespread perception that the company is backing off its commitment to Silverlight, a cross-browser, cross-platform runtime for rich internet applications. He is the right person to do so, since it was his remark that ”Our strategy with Silverlight has shifted” which seemed to confirm a strategy change that had already been implied by the strong focus in the keynote on HTML 5 as an application platform.

Muglia says Silverlight is in fact “very important and strategic to Microsoft”. He confirms that a new release is in development, notes that Silverlight is the development platform for Windows Phone 7, and affirms Silverlight both as a media client and as “the richest way to build web-delivered client apps.”

So what is the strategy change? It is this:

When we started Silverlight, the number of unique/different Internet-connected devices in the world was relatively small, and our goal was to provide the most consistent, richest experience across those devices.  But the world has changed.  As a result, getting a single runtime implementation installed on every potential device is practically impossible.  We think HTML will provide the broadest, cross-platform reach across all these devices.  At Microsoft, we’re committed to building the world’s best implementation of HTML 5 for devices running Windows, and at the PDC, we showed the great progress we’re making on this with IE 9.

The key problem here is Apple’s iOS, which Muglia mentioned specifically in his earlier interview:

HTML is the only true cross platform solution for everything, including (Apple’s) iOS platform.

Muglia’s words are somewhat reassuring to Silverlight developers; but not, I think, all that much. Silverlight will continue on Windows, Mac and on Windows Phone; but there are many more devices which developers want to target, and it sounds as if Microsoft does not intend to broaden Silverlight’s reach.

Faced with the same issues, Adobe has brought Flash to device platforms including Android, MeeGo, Blackberry and Google TV; and come up with a packager that compiles Flash applications to native iOS code. There is still no Flash or AIR (out of browser Flash) on Apple iOS; but Adobe has done all possible to make Flash a broad cross-platform runtime.

Microsoft by contrast has not really entered the fight. It has been left to Novell’s Mono team to show what can be done with cross-platform .NET, including MonoTouch for iOS and MonoDroid for Google’s Android platform.

Microsoft could have done more to bring Silverlight to further platforms, but has chosen instead to focus on HTML 5 – just as Muglia said in his earlier interview.

Whether Microsoft is right or wrong in this is a matter for debate. From what I have seen, the  comments on Microsoft’s de-emphasis of Silverlight at PDC have been worrying for .NET developers, but mostly cheered elsewhere.

The problem is that HTML 5 is not ready, nor is it capable of everything that can be done in Silverlight or Flash. There is a gap to be filled; and it looks as if Microsoft is leaving that task to Adobe.

It does seem to me inevitable that if Microsoft really gets behind HTML 5, by supporting it with tools and libraries to make it a strong and productive client for Microsoft’s server applications, then Silverlight will slip further behind.

Microsoft’s Silverlight dream is over

Remember “WPF Everywhere”? Microsoft’s strategy was to create a small cross-platform runtime that would run .NET applications on every popular platform, as well as forming a powerful multimedia player. Initially just a browser plug-in, Silverlight 3 and 4 took it to the next level, supporting out of browser applications that integrate with the desktop.

The pace of Silverlight development was unusually fast, from version 1.0 in 2007 to version 4.0 in April 2010, and Microsoft bragged about how many developer requests it satisfied with the latest version.

Silverlight has many strong features, performs well, and to me is the lightweight .NET client Microsoft should have done much earlier. That said, there have always been holes in the Silverlight story. One is Linux support, where Microsoft partnered with Novell’s open source Mono project but without conviction. More important, device support has been lacking. Silverlight never appeared for Windows Mobile; there is a Symbian port that nobody talks about; a version for Intel’s Moblin/Meego was promised but has gone quiet – though it may yet turn up – and there is no sign of a port for Android. Silverlight is no more welcome on Apple’s iOS (iPhone and iPad), of course, than Adobe’s Flash; but whereas Adobe has fought hard to get Flash content onto iOS one way or another, such as through its native code packager, Microsoft has shown no sign of even trying.

In the early days of Silverlight, simply supporting Windows and Mac accounted for most of what people wanted from a cross-platform client. That is no longer the case.

Further, despite a few isolated wins, Silverlight has done nothing to dent the position of Adobe Flash as a cross-platform multimedia and now application runtime. Silverlight has advantages, such as the ability to code in C# rather than ActionScript, but the Flash runtime has the reach and the partners. At the recent MAX conference RIM talked up Flash on the Blackberry tablet, the Playbook, and Google talked up Flash on Google TV. I have not heard similar partner announcements for Silverlight.

Why has not Microsoft done more to support Silverlight? It does look as if reports of internal factions were correct. Why continue the uphill struggle with Silverlight, when a fast HTML 5 browser, in the form of IE9, meets many of the same needs and will work across the Apple and Google platforms without needing a non-standard runtime?

Here at PDC Microsoft has been conspicuously quiet about Silverlight, other than in the context of Windows Phone 7 development. IE9 man Dean Hachamovitch remarked that “accelerating only pieces of the browser holds back the web”, and last night Microsoft watcher Mary-Jo Foley got Server and Tools president Bob Muglia to admit that “our strategy has shifted” away from Silverlight and towards HTML 5 as the cross-platform client runtime, noting that this was a route to running on Apple’s mobile devices.

The Silverlight cross-platform dream is over, it seems, but let me add that Silverlight, like Microsoft itself, is not dead yet. Microsoft is proud of its virtual PDC streaming application, which is built in Silverlight. The new portal for Windows Azure development and management is Silverlight. The forthcoming Visual Studio Lightswitch generates Silverlight apps. And to repeat, Silverlight is the development platform for Windows Phone 7, about which we have heard a lot at PDC.

Let’s not forget that IE9 is still a preview, and HTML 5 is not a realistic cross-platform application runtime yet, if you need broad reach.

Muglia’s remarks, along with others here at PDC, are still significant. They suggest that Microsoft’s investment in Silverlight is now slowing. Further, if Microsoft itself is downplaying Silverlight’s role, it will tend to push developers towards Adobe Flash. Alternatively, if developers do migrate towards HTML 5, they will not necessarily focus on IE9. Browsers like Google Chrome are available now, and will probably stay ahead of IE in respect of HTML 5 support.

I hope these latest reports will trigger further clarification of Microsoft’s plans for Silverlight. I’d also guess that if Windows Phone 7 is a big success, then Silverlight on the Web will also get a boost – though judging from the early days in the UK, the new phone is making a quiet start.

Finally, if Microsoft is really betting on HTML 5, expect news on tools and libraries to support this new enthusiasm – maybe at the Mix conference scheduled for April 2011.

Lessons from Evernote’s flight from .NET

Evernote has released version 4.0 of its excellent note-taking product. Software developers have taken particular interest in the blog post announcing its release, because of what it says about .NET, in this case the Windows Presentation Foundation, versus native code:

Evernote 4 is a major departure from Evernote 3.5 in every way. While 3.5 added tons of great new features, there were some problems we simply couldn’t fix: the blurry fonts, slow startup times, large memory footprint, and poor support for certain graphics cards were all issues that the technology behind 3.5 (Windows .net and WPF) was incapable of resolving. As a result, we ended up chasing down platform bugs rather than adding the great features our users wanted.

So we decided to start over from scratch, with fast, native C++ that we knew we could rely on. As you’ll see, the results are amazing. This new version will set a foundation for rapid improvement.

Evernote 4 is designed to give you a great experience on any computer that you use, whether you’re on a netbook, a five year old Windows XP machine or a super fast top-of-the-line Windows 7 computer.

On our test hardware, Evernote 4 starts five times faster, and uses half the memory of Evernote 3.5.

A bit of background. WPF was introduced in Windows Vista and was originally intended to be the main GUI API for Windows, until the notorious reset midway through the Vista development cycle which marked a retreat from managed code back to native code in the operating system. I’d guess that the issues faced by the Evernote team were not so different from those faced back then by the Windows team at Microsoft.

WPF is not only based on .NET. It also uses DirectX and hardware acceleration under the covers, enabling rich multimedia effects. The layout language of WPF is XAML, giving freedom from scaling issues which cause hassles in the native API.

So what are the lessons here? Is WPF no good?

It is not so simple. WPF is brilliant in many ways, offering the productivity of .NET coding and a powerful layout framework. However it was a technology which Microsoft itself hardly used in its key products, Windows and Office – a warning sign.

When Microsoft built Visual Studio 2010 and .NET 4.0, the development team used WPF for the Visual Studio shell. This move by an internal team to create such a complex product in WPF was good for the framework itself. The font issue was addressed, performance improved. Evernote might not have found all its issues fixed in version 4.0, but it would likely have been better.

After I tweeted about Evernote’s experience, a couple of Microsoft folk contacted me to make this point. The trouble is, even version 3.5 of WPF was not the first version, and it never sounds altogether convincing if, when a customer complains about your product, you tell them everything is fine in the latest and greatest build. Why did Microsoft not get this right before?

That said, I am sure the latest WPF is better than before, though it is still heavyweight relative to native code. Factors that might suggest a WPF solution include:

  • The application only needs to run on Windows
  • There is no need to support older machines
  • The application makes use of data visualisation or other multimedia effects
  • The development team lacks the resources to build equivalent functionality in native code

The last point is important. Maybe a hotshot team of C/C++ developers could make a better job, but if you don’t have such a team or the money to hire it, it is not so relevant.

There is another possible approach, without abandoning .NET. Silverlight has many of the features of WPF, is lightweight, and runs on the Mac as well as Windows.