Windows CE Kiosk – Part 100


One thing became really clear when working on the Windows CE Kiosk blog postings is that I’ve perhaps been spending too much time being seduced by managed code development – not having to worry about message loops, massive switch statements, and message cracking – having simple classes like String and all the String manipulation functions makes all the difference when hacking away on some application code – ideally, as a programmer you should be spending time focused on building your application, not focusing on the underlying plumbing of the operating system – in many respects Win32 is designed to do this, thinking back even to Windows 1.0 (desktop O/S) the operating system abstracted the user and developer from the underlying hardware, applications didn’t need to be written to only work with one display or printer, the applicaitons were abstracted through device drivers and the Win32 API – the problem though is that the Win32 API is just a huge collection of API’s, some of which take structures, some take a number of parameters, some have COM style return values, others have BOOL, and some return handles, in some cases the developer is responsible for cleaning up resources allocated by the operating system, in other cases the operating system clears up for you – Win32 programming, in some ways feels like programming in assembler when compared against programming in C#/VB using the .NET (Compact) Framework.


Managed application development just feels so much cleaner, having well thought out class structures and abstraction from the underlying O/S, plus the ability to escape the box by calling native Win32 API’s when needed – even something as simple as not having to think about whether strings are UNICODE, ASCII or ANSI, the framework takes care of this for you, and yes, MFC for Windows CE also wraps this for the CString class.


Anyhow, that’s just my passing thought for the day – do you agree ?


– Mike

Comments (2)

  1. Gursharan says:

    Well its true that managed code manages lot of things for you. Programming is literally a play around with managed code but on the other hand, you feel to be spoon fed. With native you gotta cook your own code for everything you want to achieve, be it clean up, launch and what not. So, in a way , native code teaches you how the system works, upto a bit level. So once you call yourself to be a programmer, its your right to switch over to managed code but a good programmer always has native roots. And the .NET framework itself works natively(calling win32 APIs all the time). Am I right?

  2. Lawrence Ricci MVP says:

    IMHO, the most important reason for managed code is usually overlooked. I recommend managed code because someone else cleans up the garbage.

    At the root of it, most code written by most programmers using most development tools leaks. This is the reason most organizations never opened their ‘embedded’ device to 3rd party software. From experience they knew sooner or later, the device would crash. I have seen the ‘later’ side of this interval drift out to multiple weeks of 24×7 always on operation so debug and test is a real bitch.

    This is not just a problem for amateurs. Even the best companies turn out code that leaks. (Yes Mike, even the best 😉

    Java was supposed to solve this problem, but to the Java community “Run Anywhere” meant Solaris Servers, Linux Servers and Intel Servers. Even J2ME never really generalized the environment to the disparate hardware architectures actually used in the embedded space. Now, for the first time with .NET, programmers get a robust, embeddable runtime, defined ‘enterprise’ architecture and a serious Dev tool like Visual Studio.

    Bottom line is the results. I can tabulate the details when I get back to work, but I think there are very few application problems with customers working in the managed code space. They routinely integrate 3rd part code from places like OpenNETCF.org. It works. Further, when we hear about some device that had problems weeks after an exhaustive check was passed, the problem is almost always in some piece of un-managed code.

    So- my recomendation, if you are not writing in assembler, use the tools!!

    Larry ‘I was once a bit twiddeler’ Ricci