Windows Phone 7 may not be available yet, but it is a great talking point. Following the collapsing market share of Window Mobile and the Kin debacle, will Microsoft be able to claw its way back into the SmartPhone market? With mobile apps increasingly important in both the consumer and business world, what would be the consequences of failure?

The strategic importance of the platform makes it interesting even if you think that there is little room for Microsoft's phone in a market dominated at the high end by the two As: Apple and Android.

There is even fierce competition among the also-rans, with Nokia pitching Symbian 3 and Maemo/Meego, and HP presumably about to do something with Palm WebOS. And what about Samsung's bada? There will be blood on the carpet; not all these operating systems will survive - and while that will be a shame from the point of view of diversity, it will be a relief to developers attempting to support the broadest number of devices.

So why even bother with Windows Phone 7? Well, there are a couple of obvious reasons. One is the possibility that Microsoft will deliver an excellent and delightful device. Likely? Past form says no; but the company knows what it is up against so you never know; early reviews of preview devices have been generally favourable.

The second reason is less speculative, which is the way Windows Phone 7 fits in with the rest of Microsoft's platform. If you are used to coding in Visual Studio with C#, then creating apps for Microsoft's new phone will be less challenging than doing so for iPhone or Android. A Windows Phone 7 app is essentially a .NET and Silverlight app, or for games XNA, and from what I have seen so far Microsoft has done a good job with the emulator and developer tools.

The disconnect here is that Microsoft's primary target for Windows Phone 7 is the consumer, whereas those armies of Visual Studio developers are largely building corporate apps. Some of them are also annoyed that Microsoft is not providing compatibility with existing Windows Mobile applications.

There are also significant limitations in Windows Phone 7 in its first release. There's no multi-tasking, which means you have to write code to handle your application being shut down and re-activated while giving the appearance of resuming where the user left off. There's no native code, which runs contrary to the instinct of experienced mobile developers, some of whome tried and failed to wrest acceptable performance from the Compact Framework, the mobile .NET Framework from pre-Silverlight days. There's no copy and paste - which does not seem a big deal to me, but some people seem to care a lot about this. Another annoyance is that all apps must be deployed throught Microsoft's Apple-style Marketplace, though I hope and expect that Microsoft will come up with a way round this for corporate roll-outs.

Future iterations of Windows Phone could remove these limitations, but in this instance Microsoft does not have time to release something not very good and get it right three versions later.

I'm keen to hear from developers who have tried the preview devices or the SDK. Like what you see? Intend to support it? I look forward to comments, because the success or failure of this product is going to be significant.

I've written positively about Microsoft's forthcoming Visual Studio 2010, both here and more recently in a review on The Register. I was interested to see a kind-of follow up from Jeff Vroom, making the case for doing without an IDE at all, at least some of the time:

Emacs, Vim, and other editors have basic syntax highlighting and code navigation for an even broader set of formats despite the fact that they lag behind IDEs in features. Though IDEs offer impressive plug-in capabilities, traditional script and config files seem easier to learn and use and ultimately more flexible.

Command line workflows offer a more flexible, less integrated and less guided approach to development. You learn how to use them one tool at a time. Development and adoption of new tools is usually easier as you are not tightly coupling tools into one complex user interface. Admins, analysts, and designers use command line tools, making it easier for them to work with developers when the IDE is not front and center.

I don't see a lot of designers using command-line tools; but even so I agree that there is a case for a programmer's editor with command-line compilation, rather than a huge IDE. The two things I like most about the bare metal approach are speed and transparency. Speed, because a little editor like Notepad++ starts in a blink, handles large files with ease, and does not get in your way. It is odd that performance still matters so much in an era of multi-processor machines with each core running at more then 2 GHz; but it does. Sometimes I am caught out when a monster like Adobe Dreamweaver grabs a file association for something like HTML or PHP. I double-click a document, and wait impatiently while it loads all sorts of stuff that I do not need, when I only want to make a small text edit to the code.

Transparency is an even bigger issue. If you work with simple editors and build from the command line, you are forced to be aware of what files are in your project, what tools you are using for the build, and what arguments you are passing to them. If something goes wrong, you know where to look. By contrast, IDEs hide things from you, supposedly for ease of use. In the worst case, something like a Visual Studio solution can get corrupted and leave you not knowing how to fix it, other than to create a new one and add back the files as best you can.

A similar problem comes with wizards that generate code. It is lovely to have the IDE generate all that boring data-binding code for your forms, until there is some weird bug, the results are not as expected, and you end up tracing the SQL and puzzling over why it is wrong.

Valid points; but I am still going to come down mostly on the side of the IDE. It is simple: there are so many genuinely useful tools in something like Visual Studio that productivity is better. Things I don't want to do without include IntelliSense and code completion, debugging tools with things like mouse-hover variable values and watch windows, visual design tools that generate a ton of code I don't have to write, various refactoring utilities, and build tools that save having to think about make or Ant. Visual Studio takes ages to load, but once it is up and running you can always press Shift-Alt-Enter and pretend it is a text editor.

I am still wary of wizards though; and I value knowing how to do without the IDE, even if most of the time I end up using it. As one of the comments to Vroom's piece notes, if it gets to the point where your programming skills are really IDE skills, you should worry about being so deeply tied to a single platform and way of working.

 

So you need a new Windows application. You fire up Visual Studio, but which project type do you select? Windows Forms application, or WPF application?

Windows Presentation Foundation was introduced at the same time as Windows Vista, with final code released in November 2006 as part of .NET Framework 3.0. It was designed to replace existing Windows graphics APIs such as GDI and GDI+ with a more powerful, flexible and scaleable framework for buiding a graphical user interface, taking advantage of DirectX hardware acceleration and rich graphical effects. If Vista had proceeeded as originally planned, it would probably have been deeply baked into Windows itself, but in the end took a lesser role, presumably for performance reasons. Microsoft also added Windows XP support to make WPF more attractive to developers.

Another goal was to improve designer/developer workflow. WPF uses XAML, a declarative XML language, and is amenable to manipulation through a visual design tool. Microsoft released Expression Blend and Expression Design, which export XAML, as well as supporting WPF in Visual Studio.

Developing a Windows GUI can be frustrating. If you have ever wrestled with dialog units or the impact of "small" vs "large" fonts, you will know how badly scaling is handled. WPF is a huge improvement, with sensible layout management as well as great support for multimedia and effects.

Nevertheless, WPF was slow to take off. Issues included the large memory footprint of a WPF application, deployment of the latest .NET runtime, and lack of pre-built components; in fact, for a long time Microsoft itself advised against using WPF for line of business applications.

There was another factor too. Long-term Microsoft platform users have learned to be cautious about any technology that is not much used within Microsoft itself. WPF was a great example, with little obvious use beyond the Expression tools themselves. In this context, it was fascinating the hear the talk from Principal Software Engineer Paul Harrington at PDC in November, about how Visual Studio 2010 has been rebuilt with WPF. Harrington's team has an advantage over most of us, in that they can press the WPF team to fix bugs and make changes, and that is exactly what happened. Visual Studio needed to use invisible windows for some operations; WPF did not support that, but now now in version 4.0 it does. The text rendering in the new editor was making some developers feel physically ill, apparently, because of its blurry appearance on some systems, so a new text stack was built, enabled by turning off ClearType. The Visual Studio team ran into problems with focus and activation, and new modes have now been added to WPF to fix them.

My guess is that the stress-testing of the Visual Studio team combined with other improvements in WPF, such as new business-oriented components, will make it the sensible choice for a Windows GUI application, other things being equal (which they never are), once Visual Studio 2010 is released.

The big caveat is that developing new applications using a Windows-only API does not look like a smart choice in many scenarios, though it could still make sense within some organisations, or if your application is strongly hooked into Windows anyway. WPF has good support for new Windows 7 features, for example. But Microsoft is also releasing Silverlight 4.0, which has considerable compatibility with WPF but runs on the Mac as well as on Windows, is easier to deploy, and which fits with the web model for data handling. Silverlight 4.0 now has COM support on Windows, when run out of the browser, which means you can add native code if you really need to, and integrate with other applications such as Microsoft Office.

In some curious way then, WPF is maturing to become an excellent development framework at just the wrong moment. Nevertheless, I'd now think twice before hitting the Windows Forms option on a new application.

I've been trying out JavaScript mapping APIs from Google and Microsoft, which prompted me to revisit the question of JavaScript IDEs and debuggers. My first stop was Visual Studio, since I use it anyway for Windows and ASP.NET development, and I was impressed by how well it works even for projects that do not use Microsoft technology. Take Google Maps, for example. Fire up Visual Studio 2008 (earlier versions are less good for this) and start a new project using the Empty Web Site template. Right-click the solution, Add new item, and choose HTML page. I always name these with an .html extension, not the default .htm which exists solely because DOS could not cope with four-letter file extensions, but it is a matter of taste. You now have an empty web page. Click Debug, and let Visual Studio add a web.config with debugging enabled even though you will not be using this for deployment. You will also be prompted to turn on debugging in Internet Explorer, if you have not already - yes, you have to uncheck disable:

If you then try to debug, Visual Studio fires up its internal web server and opens the blank page in Internet Explorer. So far, so good. Next, I added the code to display a Google map - it's only a few lines of JavaScript. Visual Studio does a good job with syntax highlighting and code completion, for types that it knows about. I found that I could easily set breakpoints and inspect variables; everything worked smoothly: 

You can even debug into the incomprehensible Google library code if you feel so inclined - just press F11 to step into the code. You also get windows for autos, locals, watched variables and call stack; and there is an immediate window.

There are a couple of snags with this. One is that browsing the web with debugging fully enabled in IE is painful, either because the web is littered with broken JavaScript, or because IE breaks easily; I guess both of these are true, and you will see constant debug dialogs. A solution is to use a different browser for everyday use. The good news is that this is said to be fixed in IE8; Visual Studio will turn on debugging in IE8 on demand, though I have yet to try this.

The other unfortunate aspect is that attempting to debug with other browsers does not work in the same way. You could edit in Visual Studio and debug with something like Firebug; but you lose the smooth integration. IE8 mitigates this a little, because it is more standards-compliant so its JavaScript engine and DOM is closer to that in FireFox and Safari, but there is still no substitute for debugging in all the browsers that matter. Of course we will also have to cope with IE7 for the forseeable future.

Still, if you are a Windows developer casting about for a JavaScript IDE, don't forget the one you most likely already have installed.

 

Concurrent programming was a major theme at Microsoft's recent Professional Developers Conference. We all know the reasoning: processors are no longer getting faster, but multiple processors are now commonplace. Even my desktop PC is a quad-core. However, having multiple processors is no guarantee that applications will run faster. For that to happen, the application has to be coded with concurrency in mind. Therefore, if we want to write fast applications, we have to learn concurrent programming.

Unfortunately concurrent programming is hard. Think deadlocks, synchronisation, non-determinant, race conditions, and so on. Fortunately, Microsoft is good at making hard things easy. The original Visual Basic transformed the coding of a graphical user interface from something intricate done in C or C++, to something anyone could do with a few clicks of the mouse.

Now Microsoft aims to do something similar for concurrency. The .NET Framework 4.0 incorporates the Parallel FX Library, which does a great job of simplifying multi-threaded development. The new Task Parallel Library is smart about how many processors it finds at runtime, and spins the right number of threads to take advantage of them. PLINQ lets you easily apply parallelism to LINQ queries. Daniel Moth does a great job of demonstrating the benefits in his session at PDC, which you can watch online; and if you work with .NET I highly recommend it.

The worrying aspect is that while Microsoft is making concurrency easy, it is not making it safe. When I was playing around with Visual Studio 2010 and .NET Framework 4.0, one of the first things I did was to look at my code for counting primes and to see how I could optimize it. I found I could do so easily by changing a For loop to use Parallel.For instead, one of the features of the new library. I got a nice speed boost on a two-core machine, not quite double, but nearly so. One snag: the result changed every time I ran it.

I soon figured out what was wrong. My code declares a numprimes variable, then increments it within the loop. Everything is fine when single-threaded, but if you have two threads running the loop in parallel, they might both increment the variable at nearly the same time. That means reading the value, incrementing it, and writing it back. Occasionally this happens:

1. Thread one reads value
2. Thread two reads value
3. Thread one increments value, writes it back
4. Thread two increments value, overwrites it

Result: the value is one less than it should be. The fix is to lock the value first, or to find a better approach; this exact problem is discussed here (scroll down to Aggregation).

Bugs are nothing new in programming, but concurrency bugs are particularly tiresome. The code may work fine on some machines; in my example, the bug would not occur on a single-core PC. If your loop is a little less tight than a prime number calculator, it might be that the odds of the bug occurring at all are rather small. It could even pass all your unit tests. Deploy the application though, and you can bet that wrong results will soon crop up with the usual potential for calamity.

Haven't we already had, and survived, this problem with previous abstractions like BackgroundWorker, a class in .NET Framework 2.0 that makes it easy to push some code into a background thread? True to some extent, but BackgroundWorker is less dangerous because it is typically used more for keeping an application responsive, than to increase performance with parallel threads on a multi-core system.

The bottom line is that while I am full of admiration for the work Microsoft has done with the Parallel FX, I have a nagging worry that as more and less skilled programmers are encouraged to do this, we may be introducing a new wave of buggy code, as argued in detail by Edward Lee in his paper The Problem with Threads [PDF]. The hardware trend is real though, so I suspect greater concurrency in everyday business applications is coming whether we like it or not.

The other conclusion is that before using something even as apparently simple as Parallel.For, developers have a responsibility to learn about the pitfalls as well as the benefits.

The world's biggest software company is gearing up to tell you how its new modelling platform will transform developer productivity. Modelling is meant to make programming easier, by expressing the design of an application in easily understood diagrams rather than in a bunch of complicated C++, C# or Java files.

The snag is that while models are a great way to design, describe and communicate how an application works, in the end someone still has to write the code. Smart people have made immense efforts over the years to fix this by integrating the code with the model: generating code from models, generating models from code, or even devising ways to execute the model itself.

While these efforts have not failed completely, model-driven development has never taken off in a big way. Developers figure that they have enough trouble writing and debugging code, without taking on the burden of keeping a complex model in synch, or learning the mysteries of Model-Driven Architecture (MDA), with its PIM, PSM, MOF, OCL, ODM, SPEM and so on - have a look at the Object Management Group (OMG) if you want to know more.

Now Microsoft is having another go. Code-named "Oslo", the project includes a store, a language and various tools; and it's going to figure in a big way at the company's Professional Developer Conference next month. Some details are already trickling out. Posts from Don Box and Doug Purdy explain it in simple terms, and this eWeek article has a bit more. The modelling language is code-named D, and I suspect it is another role for XAML - see my post on 10 things you might not have known about XAML if you thought it was just for building GUIs and Silverlight applications.

It would make sense for Microsoft to use XAML, since it is a flexible textual language that is designed to play nicely with visual tools. I'm guessing that you will be able to create the model visually and then run it, just as MDA promises. In a video, Senior Vice President Bob Muglia says:

When a model is created, it's possible for the business process to run directly with very minimal procedures being created around that. The model is the centre of the universe.

There are also hints that Oslo will tie in with Microsoft's cloud computing initiatives - maybe Live Mesh or some more business-focused variant.

Will it work? Microsoft is certainly serious about it. It has even joined the OMG, despite years of antipathy, though I hope this does not mean Oslo will be as complex and unsatisfactory as MDA. I see it as model believers getting together, and a way for Microsoft to get more academic and enterprise credibility for its initiative.

There are however plenty of reasons to be sceptical. Microsoft has had numerous modelling initiatives over the years. In Visual Studio 2003 it was Visio and UML. In Visual Studio 2005 it was class diagrams, Domain Specific Languages (DSL) and Design for Deployment, a way of taking deployment constraints into account before and during development. This article explains the strategy, and enthuses about software factories as the way forward. Now there is Oslo, which looks like a brand new approach. Why think this will succeed any better than what has gone before? Why think that Microsoft will achieve what the fine minds at the OMG and its industry partners have failed to do?

There is also little evidence that this is driven by customer demand. When I talk to Microsoft developers, I don't hear many asking for better modelling tools; and if the subject does come up, it is usually a request for more standards-compliant and up-to-date UML diagramming, not full-on model-driven development. This is a top-down initiative.

Count me a sceptic then; but I also want to give Oslo a fair assessment when it is unveiled next month. It is quite simple. If Microsoft can deliver a modelling platform that really does simplify rather than complicate software development, and one that does not impose a heavy performance burden, then developers will love it. The big question: what is the chance of that?