A rant from a confused Windows developer

I started developing for Windows with version 1.02 and back then it was easy. Not easy to develop, as it took days just to create a nice looking dialog box, but easy to decide on the approach to take. You bought the Windows SDK with Microsoft’s C compiler and developed in C, as there wasn’t anything else.

C became C++ and that was the obvious path to follow. Visual Basic appeared, and that was better for some kinds of application. It was fairly easy to know when to use one, the other, or both in combination. Java was great, but didn’t work out as a Windows desktop solution because of politics, and then .Net came along which gave us C#, a near-perfect evolution from C++ and Java, as well as a re-crafted Visual Basic with all the shortcomings removed. The choice of language became a ‘lifestyle’ issue as they were interchangeable, and choosing an application approach was easy - Windows Forms for the desktop and ASP.Net for the web.

Then in 2008 we got Windows Presentation Foundation (WPF) which was radically different. Its benefits and evolution were obvious, and although it had a much steeper learning curve than Windows Forms, once I got over that I was an instant addict. The development community were not instantly impressed though, and I found very little appetite for training in it at first - not helped by the fact that the development tools weren’t really ready until the service pack for VS2008 came out. I was once again comfortable that the standard approach for desktop development was clear - WPF together with C# or VB.

Then there was Silverlight. Originally something programmed using JavaScript for the web, it became something you could use with C# ‘out of browser’. I found my customers wondering whether to use WPF or Silverlight for their desktop applications. It should have been very easy - WPF being the whole package, Silverlight a true subset of WPF, but it wasn’t like that. There were coding differences, similar features being added to both which were incompatible with each other, almost as though they were competing products from different companies wishing to outdo each other.

Next there was Windows phone 7. I got myself one of these, which like most things mobile-phone was much more expensive than I had thought (what exactly is a ‘smartphone bolt-on’ anyway?). I could code for it in C# which was nice and use Silverlight, which was fine in theory, except it wasn’t the same Silverlight. And it wasn’t the same framework, with all the things I wanted to use for my first applications being missing (TcpClient comes to mind). Many things were missing because of security and sandboxing, which I could understand to a point, but many were missing because it was a ‘resource limited device’. My phone has 60 times more memory than the first system I used Windows NT on, so not being able to do the things that Windows NT could is silly.

And now there’s Windows 8. It gains a touch screen interface, so that should have been easy - add some new features to .Net and WPF and we can develop WPF applications in the way we know and love and gain touch. But no - it would seem that it has to evolve from Windows Phone, but be different still from that, with features that are just about acceptable when developing for a phone but nonsensical for the desktop. Just like Silverlight, many things seem to be different to ‘classic’ .Net for no good reason. It feels like it was designed to be programmed in HTML and JavaScript, with something similar to .Net tagged on as an afterthought for C# developers. Now I love JavaScript, but only when I’m writing web page code - elsewhere it is just sloppy and error-prone compared to a real language.

The sad thing is that for the first time since my love-at-first-sight relationship with Windows I’m wondering if I can be bothered. The frustrations of hitting things which are different for no good reason mean that I’m starting to look elsewhere. I’ve always developed for Linux as well, but I’m starting to imagine a world where everyone really does start installing Ubuntu for free rather than buying Windows, and someone gets round to finishing Open Office. I’ve started writing for Android - yes the Java environment has been more of a mess than anything in the Windows world but it’s still a nice language.

No doubt I’ll end up loving WinRT in the end, but it feels strange to be considering alternatives to Windows after all these years. One thing is easy - I’m definitely not an Apple fan. Unless of course they decide that C# + WPF + real .Net is their development environment of choice!

Has VB come of age?

When .Net first came out I tended to use C# by choice, having a history of Java and C++, but I still retained an affection for Visual Basic. Most things could be done in VB rather than C#, but VB was always a little more verbose and had annoying features like having to type in space-underscore to carry a statement onto another line. Provided strict type checking was turned on though it gave the same performance as C#, and of course having been a Java enthusiast strict type checking in itself was very important to me.

This week I wanted to begin a project involving various forms of parallel execution. In the past I would have instinctively gone for C#, but having been training in VB for the previous couple of weeks I decided to begin with VB. And I found myself rather liking it, especially now I don’t need the space-underscores any more. I guess the first thing is that being able to do parallel programming naturally in VB was revealing – something that would have been assumed to be C++ territory a decade ago. But I also found that small changes from the last couple of versions appealed.

For example, let’s imagine that you are issuing an ADO.Net command and getting a data reader back. In 'VB6 style' this would be something like:

Dim cmd As New SqlCommand( sql, connection )
Dim rdr As SqlDataReader
rdr = cmd.ExecuteReader()

VB 200x of course allows 1 less line:

Dim cmd As New SqlCommand( sql, connection )
Dim rdr As SqlDataReader = cmd.ExecuteReader()

But the 2^nd line feels a little unnatural to a Java mindset. Type inference allows:

Dim cmd As New SqlCommand( sql, connection )
Dim rdr = cmd.ExecuteReader()

Which is now as concise as it would be in C#. Type inference goes a bit further in VB than C#, for example:

Dim someList As New List(Of SomeClass)
For Each thing in someList
…
Next thing

Where in C# the type of ‘thing’ needs to be given such as:

foreach( SomeClass thing in someList ) { … }

which is not very different but some reason many people find the SomeClass thing confusing in training courses.

As a last example, this is a trivial example of a lambda in C# which shows a message box (for something to do!) from a thread:

Thread t = new Thread( () => MessageBox.Show( "text " ) );
t.Start();

The VB equivalent would be:

Dim t As New Thread(Sub() MessageBox.Show("text"))
t.Start()

I feel this is a case where the VB is more intuitive (and is actually less typing). But that’s just me.

WPF 3D, The Beauty of Mistakes

When I first coded graphical applications for Windows using GDI many years ago, one thing I discovered was that coding mistakes could often produce very attractive results, particularly when using things like bitmaps and ROP modes. Not as exciting as some of my first work controlling industrial machines, when a mistake could cause 3 tonnes of metal cutting equipment to crash into its end-stops at high speed, but pretty nonetheless.

With WPF 3D coding it's even better. When writing code I like to test things out as often as possible, and this is particularly beneficial with 3D work as often when trying to visualize things in 3D space it's just easier to build things up gradually. The sad thing is that the intermediate results often look better than the finished article, even if they are not correct. For example, this is a chart before the size of the radial elements was calculated.

This is an incomplete spherical element.

And this is the same item with a little more coding.

Another example of this is the use of normals to influence lighting and shading. I most often build up the mesh by creating the points and triangle indices first, viewing the results for correct positioning etc. While it's undoubtedly better to think about and hopefully calculate the normals at this time, I tend to do it afterwards. I'm then disappointed because although the appearance is definitely more correct, it's often not as attractive. The simple bar chart example below shows this.

The finished article had much better defined edges and smooth colours, but it definitely didn't look as nice!

Silverlight and WPF

This week I have been doing some work producing charts. Many years ago I sold a product called 'Business Graphics Library' and since then many of my projects have involved special charts written on request for customers. As an experiment I wanted to try porting a chart I called a 'starburst', which had originally been written in Excel VBA, to Silverlight.

The chart had a dynamic layout, so I wrote the new one entirely in C# rather than XAML. As you can imagine it was much more straightforward than the Excel VBA original given the rich graphics supported by SL.

The next step was to use the same code for a WPF desktop application. The Silverlight control included some data structures for passing the information to be plotted, including colours, and my first attempt was to use these, as well as the chart code itself, directly from the library by simply adding a reference to the Silverlight control DLL into the WPF project. This almost worked, but ultimately failed because the Silverlight classes I used were in different .Net assemblies to their WPF equivalents. Even basic types like Color had this problem.

To solve this I added the classes as existing items to the new project, but used the 'Add As Link' option in the dialog (by clicking the arrow on the Add button). I now had common source between the 2 projects, and I could display my chart on a web page using Silverlight or a desktop app using WPF. So far so good.

At this point it was all driven from C#/VB code. The next stage was to be able to use my control entirely from XAML, so some dependency properties were required. Registering these using DependencyProperty.Register worked fine for WPF, which I did first, but I could not get the same code to compile for Silverlight. It turns out that there are different Register methods, and the arguments I had used for WPF (which has 3 overloads) were not compatible with Silverlight (which has only one). Luckily there is a WPF overload which is compatible with the Silverlight implementation so by passing a null for the 4th argument I had compatible code again.

Slightly disappointing to be entering the area of coding around differences. Having a common API between desktop and web applications is a really good idea, and little differences like this seem to be pointless distractions. Of course there are big differences as well. Having used an image projection in SL I was disappointed not to find it in WPF. But my real goal for the Starburst chart is a true 3D version (the subject of another post shortly), but this can only work for WPF as Silverlight does not support true 3D. Given that Silverlight's one major advantage over Flash is the .Net Framework (IMHO) I would hate to seem them diverge.

Performance of C# vs C++

Many people see C# as a fine language for business applications, but feel it lacks the low-level capabilities of C++ for software which is close to the metal.

C# includes many features such as the unsafe keyword that allows you to achieve most of what you could do in C++, but even without the use of unsafe code performance-intensive programming is possible. I was recently involved in a large project where I had the opportunity to compete with a C++ team, by writing an equivalent program from scratch in C#. Without wishing to break my NDA, the application involved much bit-twiddling, video, networking and the like. Originally I kept in an existing C++ library, but ended up using C# exclusively.

The C# code was around 20% of the size of its C++ equivalent, measured using a sophisticated tool that ignored layout, comments etc. Performance ended up being about the same – there were initial performance problems with the C++ version which were fixed by some serious coding work.

Where I expected the C# version to fall down was with load times, due to the just-in-time compilation. In fact this was very noticeably faster in the C# version – I presume that the JIT overhead was compensated for by the smaller code size.

It would be nice to try something similar with Visual Basic one day!

Casting, 'is' and 'as' in C#

I was giving a course for a gaming company who were understandably interested in performance issues. One of the things discussed was the relative performance of traditional casting versus is and as, so I had a play.

The general idea is that you have a reference variable of a base class type, which may be referring to an object of a derived class. This derived class has additional members which you wish to use, so you need to have a reference of the derived class type. For example:
BaseClass b;
...
DerivedClass d = b;
d.AMethodOnlyDerivedClassHas();

And of course the second line above will be thrown out by the compiler as BaseClass is less than DerivedClass in hierarchy terms.

A C-style cast could be used, for example:

DerivedClass d = (DerivedClass)b;

If you definitely know that b refers to a DerivedClass object then this is the fastest technique, about 5% faster that using ‘as’. But if b does not refer to a DerivedClass object (or an object of a class derived from it) then an exception is thrown, which is extremely expensive.
When b may or may not refer to a DerivedClass object, ‘as’ is useful as it gives null when the object is not the expected class, for example:

DerivedClass d = b as DerivedClass;
if ( d != null )
{
d. AMethodOnlyDerivedClassHas();
...

This technique allows us to test and cast simultaneously. Although it is a bit slower if the object is the tested-for type, it is enormously faster (>200 times) than catching the exception that the C-style cast throws.

‘as’ is widely used because it allows us to combine the testing with the assignment to a reference of the correct type. ‘is’ can be used just to perform the test, for example:

if ( b is DerivedClass )
...
And in fact ‘is’ and ‘as’ both use the same CLR code, so cost the same. Don’t do this though:

if ( b is DerivedClass )
{
DerivedClass d = b as DerivedClass;
d. AMethodOnlyDerivedClassHas();

as you end up calling the same CLR support code twice.

An alternative would be to compare types, for example:

if ( b.GetType() == typeof( DerivedClass ) )

This is about 10 times as slow as using ‘as’ or ‘is’, but allows an exact comparison rather than the ‘at least’ comparison used by ‘as’ and just about everything else. In practice this is probably not useful though.

Getting Started

The idea is that this page will contain snippets I've gathered from my training and development work which will hopefully be useful to other developers.