Runtimes, Frameworks and Fragmentation

With all the buzz about Web runtimes, the new Sybase runtime, AOL open platform and Nokia/Trolltech/Qt it’s easy to assume that runtimes and frameworks reduce development fragmentation. However, if you look at history, it’s possible to see that runtimes can actually make the situation worse.

Take a few examples involving Windows Mobile and Nokia S60.

Windows Mobile. If you program for Windows Mobile you will know that both MFC (a programming library) and .NET framework have evolved over time and it’s not possible to rely on a person having a particular version of these on their device. At one time Microsoft recommended you link dynamically with MFC so as to have small executables (and downloads) and prevent bloating each exe with what would be the same code. Now, with the variety of MFC versions (and I suppose greater memory on devices), the accepted technique is to link statically and include all the code in every application.

It’s a similar situation with .NET compact framework. A method of working is to code against one version of the framework and rely on end users possibly having to download that particular version of the framework in addition to your application – which can run into megabytes of download and is a complicated extra step the user the user really shouldn’t have to concern themselves about. Alternatively, you can write different versions of the application for each framework version.

For many serious applications, .NET compact framework excludes many things and the extra effort of interfacing with base Win32 c code sometimes makes it a better choice to use Win32 for everything – with no dependencies on MFC and .NET compact framework and hence maximum compatibility across Windows Mobile devices.

Nokia S60. If you work with the Nokia WebKit runtime, SVG, Flash Lite or even once used Appforge you will know that again, it’s not possible to rely on a person having a particular version on their phone. With Webkit it depends not only on the phone OS version but also possibly the firmware version as only newer firmware includes it.

Despite SVG on over 100 million phones and 100 different handsets most contain SVG-T 1.1. This is basically a rendering engine. Version 1.2 is the version required for interactivity and improved user experience.

The fundamental problem is that runtimes/frameworks themselves have different versions with different capabilities and different bugs. The versions also tend to be out of step with underlying OS versions which complicates compatibility.

I suppose frameworks will always evolve and fragment capability. In this post I have spoken of mostly frameworks within an OS. Maybe if frameworks eventually significantly cover multiple operating systems, the advantages of cross platform support will outweigh the disadvantages.

Also, the examples I have been talking about assume you want to distribute an application to arbitrary people. If you have a controlled device, for example in a corporate or industrial environment then you can nearly always ensure the runtime or framework is already available.