I needed to take my car for a service today (I had some strange knocking noises coming from the engine), while the mechanic was delving around under the hood and making appropriate mechanic sounds (the odd ‘hmm’ here and there – which is always a little disconcerting, do more “hmm’s” translate to more money to fix the vehicle?) I was thinking about the work involved in working on todays cars – just looking into the engine compartment there’s nothing obvious that a typical user would be able to tamper with, beyond topping up the washer fluid bottle. Engines, and engine management systems have become so complex that for the most part maintenance is out of the hands of the general owne. When cars were first introduced every owner needed to know how to fix the vehicle by the side of the road – this is certainly not the case today.

So what about developers, do we see a similar trend here ? – I would suggest that we do…

Remember writing graphics programs for MS-DOS ? You needed to code your application to the specification of the video card you were using, whereas today on Windows (XP, XP Embedded, CE) this is totally abstracted away from you – when writing an application that uses graphics you can query the size the screen, the size of your client area, the supported color depth, and don’t even need to code your own line drawing routines – you just get a device context or graphics surface and rock on…

Which leads nicely onto application development in general, I come from an assembler, C/C++, MFC, C# background, when writing applications for the first versions of Windows the application development tools were somewhat crude – the tools didn’t contain any Wizards to create the skeleton of the application (in fact, I would just clone a copy of the Windows SDK sample “Hello World” and then modify from there), in fact, everything needed to be done ‘by hand’. If we spin forward a few years to the introduction of Visual Basic now everyone can be a programmer, right ? (see my first VB application post) – Writing Visual Basic applications is closer to painting by numbers than actually writing code, let’s create a new instance of a COM object, simple, not a sign of CoInitialize( ), CreateInstance( ), QueryInterface( ) – a couple of lines of code and you’re done – in fact you don’t even need to know anything about COM to start using COM components – Now spin forward another few years to Visual Studio .NET, as a C# or Visual Basic developer calling a SOAP service exposed across the other side of the big white fluffy cloud known as the internet is as simple writing two lines of code, now try doing the same thing in ‘C’.

‘C’ what I mean  – Application development is getting easier, the underlying development frameworks and development tools are doing the heavy lifting for you – heck, you don’t even need to free up objects that you create in managed applications, these are cleaned up for you by the framework.

So, what about Embedded Developers ? – Are you still grubbing around in the guts of an operating system when building your device, or are you spending your time configuring your embedded device and adding value ? sure, writing drivers and building BSP’s is the tough bit, but once you have a running BSP it’s simple from there on in, isn’t it ? – In fact, with Windows XP Embedded you don’t need a BSP since the underlying hardware is going to be built to the PC specification, so it’s just a case of figuring out which drivers are needed and then you’re all set (heck, there’s even a tool for that!) and for Windows CE there are a number of BSP’s that ship with the operating system development tools, and even more 3rd party BSP’s available (of course you may need to create a BSP and drivers if you’re building totally custom hardware for Windows CE).

So, finally onto the question – is embedded development heading the same way as desktop application development ? – operating system development tools are getting smarter, developers don’t need to know so much about the underlying hardware (especially when using Windows XP Embedded), the tools are doing more of the heavy lifting leaving developers free to concentrate on their added value.

Your thoughts ?

– Mike