I'm just back from Microsoft's Professional Developers Conference in Los Angeles, where the star of the show was the latest update to the Silverlight browser plug-in that lets you run .NET applications cross-platform and within the browser. The pace of development is remarkable. It is only 9 months ago that we were first shown the beta of Silverlight 3, at the Mix conference in March. Silverlight 3 was fully released in July; and now we have version 4.0 beta, with release promised for the first half of 2010.
It is a big release too. Many of the top Silverlight feature requests are being implemented, including printing, right-click and mouse wheel support, a rich text control with editing, clipboard support (though text-only in the beta), drag-and-drop, interaction with Webcams and microphones, multitouch control, improved just-in-time compilation for faster performance, and improved databinding for business applications.
In addition, the forthcoming Visual Studio 2010 is the first to have the kind of Silverlight development tools you would expect, with a true visual design surface and drag-and-drop data binding. On the server, WCF (Windows Communication Foundation) RIA Services simplify the effort of authentication, talking to data, and integrating with ASP.NET.
Another notable feature is the ability to run a Silverlight application out of the browser, started from a desktop shortcut and displayed in a custom window. New in version 4.0 is an HTML control, which embeds IE on Windows and WebKit (used in Safari) on the Mac. These are desktop/web application hybrids. Silverlight 4 blurs the boundaries, by adding a new trusted mode. Subject to the user passing a security dialog, a trusted out-of-browser application gets local file access to user data, cross-domain network access, and on Windows native code interop through COM automation.
The snag with this last point is that any Silverlight application which uses COM automation will only run on Windows, breaking the cross-platform compatibility which is a key reason to use Silverlight in the first place. Although Microsoft says the feature has been put in simply to meet the requirements of a few Enterprise customers, it seems to me that it goes well beyond that, making Silverlight viable in many scenarios that previously would have required a native solution.
Microsoft's ideal scenario is one where applications run everywhere, but run best on Windows, preserving its desktop lock-in. The company calls this "lighting up the platform"; but Windows is somehow the only platform that gets lit up.
I still think it is time to learn Silverlight. The reason is not only Microsoft's signposting of this as its key technology for future client development, but something else I saw last week: Google's Chrome OS. I'll be writing more about this; but I was impressed by how this forthcoming browser-based operating system promises to solve long-standing problems: cheap, lightweight computers that are secure, that start up instantly, that give us access to all our data, but can be left in the back of a taxi without compromising our secrets.
What if Chrome OS catches on? Does Microsoft become irrelevant? The real world does not move that fast; but considering the continuing popularity of the Mac along with the prospect of Chrome OS, it strikes me as brave to presume a Windows-only client for future development. Silverlight on the other hand should run in Chrome OS, either using Mono's Moonlight, or the Intel port being done for Moblin, or perhaps Microsoft itself will have to dirty its hands with Linux. Google might block Silverlight - it was non-committal on the subject at the Chrome OS press briefing - but I'm guessing that concerns over appearing excessively controlling will trump the desire to shut out a competitor.
The point here is not that Silverlight is the answer for all client development; there are plenty of other strong choices. The point rather is that for Microsoft platform developers Silverlight is the technology that makes it possible to take your C# or VB.Net skills and transition them to a new cross-platform, web-oriented world.
Microsoft's Eric Nelson conducted a poll on how many businesses still use Visual Basic 6. It is hard to make sense of the statistics, since there was a built-in bias:
This survey was sent out to individuals we "suspected" had Visual Basic 6.0 heritage but it was also widely advertised through the MSDN Flash to UK developers.
In other words, only Windows developers were consulted, and those more likely to be using VB 6 were specially targetted. Some results:
See the original post for more detail. I'd like to know more about the wider picture - how many companies overall still use VB 6 - but although these figures are skewed I can well believe that there is a lot of VB 6 out there.
Incidentally, the respondents are correct in believing that the VB 6 IDE is no longer supported. Extended support ended in March 2008. However, note that Visual Basic for Applications, which partly shares the same runtime, remains part of Office and therefore is supported. The VB 6.0 runtime is supported at least until 10 years after the release of Windows Server 2008; see this paper for exactly what is and is not included.
I noticed that msvbvm60.dll, along with other VB 6.0 runtime files, is also in my beta copy of Windows 7. I guess that will nudge the support life for the runtime even further into the future.
The bottom line is that Microsoft would be crazy to release a mainstream version of Windows that could not run VB 6 applications. For the most part, laggard VB 6 developers are safe, though there could be third-party components that stop working. Another point is that VB 6 will always be 32-bit.
All this prompts a few observations.
First, if you have skills in VB 6.0, it looks like you will be in demand for a while.
Second, my own views on VB 6.0 are mixed. I recognize that it was a revolutionary and very capable tool; but if anyone is inclined to wax lyrical about its merits, I point them towards Verity Stob's Thirteen Ways to Loathe VB and Bring your Hatchet by Bruce McKinney. At best, it is a flawed platform.
Third, I do see the sense in leaving well alone in many cases. VB 6.0 is lightweight compared to .NET, and runs on a wider range of hardware. Migrating code is perilous unless you have rigorous unit tests; some quirk in VB may catch you out, so that ported code does not work in quite the same way.
It strikes me that there is little value in migrating from, say, a VB 6.0 client application to a .NET Windows Forms application. My instinct would be either to leave it be, or redesign it as a web application. Otherwise the risk is that your new ported application will be just like the old version, but slower.
Microsoft has a summary of the options here, which seems to promote the idea of hybrid applications, perhaps using the Interop Forms Toolkit to embed .NET controls in VB 6 forms. Maybe, but there is a danger of getting the worst of both worlds. That said, every case is different so there is little value in generalizing. The important thing is to have a technical and business rationale for the path you choose.
