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

• Anonymous
  January 03, 2007
  The comment has been removed

• Anonymous
  January 03, 2007
  Win32. Without a doubt. (But i'm a relic :)).

• Anonymous
  January 03, 2007
  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....

• Anonymous
  January 03, 2007
  Managed Code in C# , I would be happy to use some assembly as well

• Anonymous
  January 04, 2007
  For Windows CE web server development, there's Win32 ISAPI or a neutered version of ASP, so we're stuck with native C++.

• Anonymous
  January 04, 2007
  Native code and C/C++ with some assembly thrown in. But I'm an old school hardware guy writting time critical device drivers.

• Anonymous
  January 04, 2007
  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

• Anonymous
  January 04, 2007
  The comment has been removed

• Anonymous
  January 04, 2007
  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.

• Anonymous
  January 04, 2007
  The comment has been removed

• Anonymous
  January 05, 2007
  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. :)

• Anonymous
  January 05, 2007
  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.

• Anonymous
  January 07, 2007
  The comment has been removed

• Anonymous
  January 07, 2007
  The comment has been removed

• Anonymous
  January 09, 2007
  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.

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

• Anonymous
  February 01, 2007
  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.