Is there any reason to use Win32 API (in C or C++) over .NET?

Question

I'm finishing my summer job where I write graphical software for our baggage scanners. Everything is done in .NET or MFC, with plain C++ for hardware communication (I don't do any of the hardware stuff). I sometimes resorted to Win32 API calls such as SendMessage to improve performance of a form or control. I've had only a year's worth of CS courses (all in C), but I am fascinated by the Win32 API--it is much larger and more powerful than I thought.

Does .NET simply hide all of the "tedious" or ground level work of the Win32 API? Does the final software consume more system resources or perform slower in .NET?

Answer 1

The appeal of .NET is that it is a more productive development platform. Many parts of the .NET framework do provide a partial wrapper of Win32 API's. Although the framework does, indeed, abstract away a lot of "tedious" Win32 API calls, that doesn't stop me from needing a little PInvoke every now and then.

You will find that the .NET framework does involve a little overhead and is not strictly as efficient as C or C++ is capable of being; however, often the tradeoff is between productivity and efficiency. The requirements of the individual application will determine which is more important. In a lot of software, the requirements are to be "efficient enough", and may be entirely suited to .NET development.

Answer 2

The simple answer to your questions, are "no", "yes", and "not necessarily", in that order. That is to say, .NET does much more than "hide" the Win32 API, it wraps it in some cases, expands upon it in others, and completely ignores it in still other cases.

Software developed with the .NET framework will often consume more resources than the lean-and-mean hand-coded assembly that could (theoretically) be produced by an expert, but in many cases, the C or C++ developer will use frameworks and toolkits that are just as heavy as the .NET framework, and the difference will be a wash. The other thing to consider is that it usually doesn't matter if a program consumes a few extra kb of memory these days. Noone notices. If the benefits of developing in .NET (or any other technology) outweigh the risks, then it's a better choice. Only you can tell that for your particular situation.

As for "performance", that's an awful big category, but since .NET code is compiled to machine language (it's not interpreted), generally there is little difference. Again, the hard-code assembly programmer will likely beat it, but apply your cost-benefit analysis to determine if it's worth it to you.

Answer 3

All that you mentioned is "layered" on top of Win32, yes. Win32 is one of the lowest levels you can programmatically work in with Windows. In my opinion, it is tremendously beneficial to learn Win32.

Pretty much everything is based on it. (That and COM.) It's just like learning how registers work on a CPU, instead of it being a black-box.

All the really good (professional) Windows programmers I know, know it and know it well.

Programming Windows by Charles Petzold is pretty much the bible for Win32 and IMO, is well-written and executed.

Btw, I think anyone who is an “engineer in their heart” as much as in their head always needs to know how things work. I think it’s a Good Thing.

Answer 4

Does .NET simply hide all of the "tedious" or ground level work of the Win32 API? Does the final software consume more system resources or perform slower in .NET?

Yes, it tries to hide all the tedious details. And yes, a .NET application will generally be slower and is likely to consume more resources than a similar application written in C and Win32.

But the sacrifice in performance is usually a negligible price to pay for the gains in productivity and ease of maintainability.

I understand that the l33t-ness factor of programming so close to the bare metal using simple C and pure win32 might look very tempting, but I find it hard to justify when it would be many times easier and faster to use .NET.

Answer 5

.NET is intended to hide the tedious details of the Win32 API. It succeeds at that in some respects, but fails in others. If most of what you write fits well with what MS tries to support, it can succeed quite well. If you depart into "virgin territory", you can lose the advantage entirely, and even cause a great deal of extra work compared to native code using Win32 directly.

The resulting software (essentially always) consumes more resources than native code. The only real question is how much more memory it uses, how much slower it runs, etc.

These, unfortunately, are hard to answer. Speed can be anywhere from essentially identical to 8x slower or so. Memory usage is consistently quite a bit higher (e.g., at least 2x, often 3-5x. One interesting point is that garbage collection gives a trade-off between speed and memory consumption (running the GC more often reduces memory usage at the expense of using more CPU time). As such, execution time will depend as much on memory availability as CPU speed.

Interestingly, one of the first things I personally did with .NET was porting a C++ program that I knew had a memory leak (I even knew were it was and roughly how to fix it, but actually doing so would have been a lot of work). Porting to .NET didn't take very long (it wasn't a lot of code). The good news was the the memory leak was gone. The bad news was that as closely as I could figure, the leaky C++ code would have had to run continuously for over a year to use as much memory as the .NET version required just to start up.

Answer 6

.Net generally makes development eaiser. It does this by providing a system which makes the common activities take less effort from the developer.

I love working in .NET. Before it became available, I worked primarily on a GUI written in C++ using MFC and Win32. When I switched to .NET, I had to totally revise my estimates because I could get stuff done faster!

To answer your actual questions: There are less-common development scenarios where .NET does not help (and some might say it gets in the way). Those generally involve low-level use of hardware communication or finely-tuned COM programming.

Note that you can do develop in C++ for .NET, allowing you to cross between Win32 and .NET with little to no effort. (It isn't standard C++ when you develop to the CLR, but it isn't tough to pick up the differences, either.)

Don't consider performance without an actual scenario that you can actually test. For an interesting performance comparison of .NET and C++ on the same task, check out the blog entry (and links!) here: http://blogs.msdn.com/b/ricom/archive/2005/05/10/416151.aspx

Answer 7

I base my answer on one thing: C++ is an iso standard. C# is a proprietry Microsoft language.

If you ever want to extend your skills past Windows, iso C & C++ will see you much further.

.NET has a has a large framework - but if you know where to look there is a HUGE body of lgpl and (if youre compatible with it) gpl open source software written for C & C++. boost is becoming a massive library that has most of the (non GUI) functionality offered by .NET, but in a cross platform standard.

That said, if you don't mind selling your soul and comitting your career to the ongoing success of a single Company... C# / .NET has two big bonuses that the Win32 API doesn't offer:

• Its hard to write c++ code that does not leak. For all that I hate the idea of garbage collection, it is effective.
• WPF is where Microsoft have put the pretty things for UI development since XP. they look just like the normal windows controls: buttons, text boxes, listviews, that native Win32 apps get, but under the cover they support flicker free painting, are alpha aware, and can be animated and skinned.