Win32API(), COM->Objects( ), or Managed.Code() ?

you've decided you need to write some code, this could be for a real project (something that gets you paid at the end of the month) or might just be the equivelant of doodling on the back of a napkin, perhaps just trying something out to see what works or trying out something new that you've been putting off for a while, you obviously have a choice of programming languages ranging from C/C++, Visual Basic, C#, or perhaps even trying out some other language while at the same time drinking a large cup of Java.

When writing code on the Windows desktop, Windows XP Embedded or Windows CE you have a choice of application development frameworks to use, this could be Win32 (the "assembly language" of the o/s), this could be a framework like MFC (a set of wrapper classes that abstracts developers from the underlying Win32 API), this could be COM (object based, versioned components) or Managed Code

You could be writing code that calls on Win32, COM, or Managed assemblies or potentially be writing components (DLL, COM Object, or assembly) for someone else to call.

I'm curious, what's your preference of language and interface (Win32, COM, or Managed Code), and why ?

- Mike

Comments (17)

  1. 5 years ago this would have been a cinch: COM no doubt.  And today I think the answer is just as clear: Managed Code.  As a framework developer for much of my career I just have to say that there is no better environment for publishing reusable components than .NET.  The IDE, the language (C#), the runtime.  It all comes together so easily that development on almost any size project is effotless.  The tools and the framework never get in the way.  With COM or Win32 you are left doing so much on your own.  Developing large frameworks is a nightmare in COM / C++ (I’m sure the mshtml team has some horror stories here).  With unsafe code and P/Invoke I can also make C# do whatever I could do in native code anyway.

  2. Steve says:

    Win32. Without a doubt.

    (But i’m a relic :)).

  3. Kris says:

    Managed code without a doubt (and Java if you need to reach beyond Windows). Productivity is great and the programming model is elegant and simple. I love COM but way too many quirks in my opinion – easy to get lost if you don’t know the underlying COM runtime well enough. And you have got to be a master of advanced C++ (Those templates can be pretty hairy). And I love to doodle in Ruby co’s I like its Meta-Programming capabilities….

  4. Mohammed says:

    Managed Code in C# , I would be happy to use some assembly as well

  5. J.Spraul says:

    For Windows CE web server development, there’s Win32 ISAPI or a neutered version of ASP, so we’re stuck with native C++.

  6. Larry Hull says:

    Native code and C/C++ with some assembly thrown in. But I’m an old school hardware guy writting time critical device drivers.

  7. Glyn DAvies says:

    Depends on what it does, and who its ultimately for.

    most stuff goes in console/ C/c++ apps for testing APIs etc or WTL (never, never MFC) if its graphical.  ATL/COM as/when required.

    c# if there’s any web services or the like – all depends on what APIs I need to access

  8. Nick says:

    I’ve been doing software development for 8+ years now… and have done it all.  I’ve written using Assembly, Win32, then C++ with MFC, ATL and COM, and now C# and VB.NET with Managed Code.

    I’ve always stuck with the latest technology.  The simple fact is, managed code is faster to develop with.  I’m far more efficient with the latest technologies than any of the previous ones.

    Sure, there are a few things that I can’t do with strictly managed code, but because I have such a diverse past, I know exactly how to call into an old COM component, or even do P/Invoke to get at the functionality I need.

  9. Lutz says:

    For my Pocket PCs and WM smartphones I need small programs that run fast and don’t have tons of dependencies. Win32 is the only choice, with a tiny little bit of C++ sprinkled in here and there. I am still baffled by the size of even the smallest .Net program, and by all these confusing versions 1.0, 1.1, 2.0 and what not.

    As long as small and fast is valued (my program won the 2006 PocketPCMag awards) i’ll stick with it.

  10. rjune@ says:

    For low level, Win32

    for GUI, still WTL/ATL

    I’ve been slack about getting my head into the managed space. But for simple apps, or anything dealing with XML/Web services then c#.

  11. tired dev says:

    Depends on what I do.

    * Doodling is mostly getting done in Python, starting to dabble in Ruby.

    * Small internal tools are getting done in whatever – Perl, Python, batch files intermixed with GnuWin32 set invocations, bash (on the Linux boxen, obviously, Cygwin is a dog!).

    * Quick one-off prototyping that needs more serious GUI is C++Builder territory (for historical reasons mostly, but it still beats {whatever}.NET for me).

    * The only serious Win development I still do is for WinCE, and that’s strictly in Win32/C++, no MFC/MSXML or any such … . We tried .NET CF but it was dog slow, ate mem as if there was no tomorrow, was very unpredictable, that is to say – no good for an embedded device.

    * My main day job these days is embedded comms work: MASSIVELY multi-core and multi-CPU, way outside Wintel or WinCE capabilities, done using embedded Linux and C/C++, so… You get the point. 🙂

  12. Mike Dimmick says:

    Managed code for new data-driven projects.

    C++/Win32 (with a little ATL) for new simple GUI programs that have simple tasks to do, particularly if needing APIs that would be a nightmare to try to interface from C#, particularly with CF 1.0’s poor marshalling support.

    MFC for maintaining projects from when we didn’t know better.

    I’ll use COM if there’s some benefit (e.g. inter-process communication) or if it’s forced on me (e.g. Soft Input Panel input methods) but otherwise no. I use it on the desktop as a way of providing plugins to VB6 applications.

  13. The embedded space has always been where old software goes to die.  Today there are embedded systems running DOS and OS-2.  Against this background I have been amazed at the take-up of managed code, even for applications with substantial real-time components.  The prime reason for this seems to be the ability to eliminate memory leaks, counter rollovers and other the bug-bears that make writing 24×365 code difficult.

    One of the comments on this blog suggested the CF overhead was too slow.  Not True!!!   What the fellow probably ran into was a CF implementation with poorly executed wrappers around -platform IO.  The efficiency of these wrappers can vary 100:1 based on nothing but the skill of the programmers who wrote the wrapper. There are some benchmarks on openNetcf to substantiate this, and some test on the applied data site  The CF is big, but MFC’s, COM, or their equivalent in other OS environments etc are not small either.  The new Micro Framework, native or installed over CE, will dramatically reduce the size issue.

    Bottom line, managed code is the clear trend for the future.


  14. I think that the choice of the language/tool depends on the kind of software you’ve to write and of its usage.

    For example a COM based API can be used easily from managed code and also (not so easily, but you can write a wrapper quickly) from C/C++ based applications and could be a good choice if you have to publish an interface that allows applications to access your software features.

    In the embedded world C/C++ is still needed when hardware access is involved or when you have to care about performances or memory size.

    The framework has been greatly improved from version 1.0 to version 2.0 and if the improvement will continue at the same rate I suppose that it will be the best choice for any UI-related development in the future.

    The framework runtime is also a big component and sometimes this could be an issue on some kind of devices where flash and RAM are very small and must be kept small.

  15. Peter says:

    Preferred managed C# where ever possible.

    Sometimes P/Invoke when functionality is missing in CF.

    We are doing a lot of remoting stuff too, DCOM with its event notification mechanism is then the preferred (and only, because .NET remoting or wcf alike functionality is not supported yet on Windows CE) solution.

    When doing real time stuff you are stuck with unmanaged code and C++, (inter-process) COM interop is than the way to talk to your (managed) user interface.

  16. sclzmbie says:

    Whatever languages customs required. But my personal favorite language is Win32/C++, for I can touch the most potential on a system.

  17. Santosh Jha says:

    We make Test and measurement devices with Windows CE. We need lot of hardware interaction in real-time mode and for that reason we use C/C++/Win32 most of the time. For the application development, we use MFC.

Skip to main content