Benefits the Win32 API has over .NET [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion开发者_运维百科. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

This is a rephrase of an earlier question, which got chopped down badly by the community. Fair enough, it might have been too argumentative.

Since I'm really interested in what people here think about this, hopefully this more specific question will be accepted.

• Name a benefit which the Win32 API will still have over .NET in 3-5 years.

---

Win32 - you can create native code tiny executables that just link to what you want.

---

Most agree there are lots of disadvantages in Win32. Here are a few advantages that, in my opinion, do not outweigh the disadvantages:

Win32 provides access to some Windows functions not readily accessible in .net.

Win32 is compatible with earlier versions of Windows.

Win32 provides access to low-level Windows messaging.

---

There will always be a set of Win32 API's that have no direct equivalent in managed code. Calling these APIs from managed code is possible but requires writing a wrapper layer (PInvoke) on top of them. No such wrapper will be needed for native code.

---

I am not sure there really are many benefits. The Win32 API is kind of fundamental to how Windows is currently and has been designed. There is a tremendous installed base of applications that were written years (or even decades) ago in C using Win API, that are still currently maintained, which may need to utilize new features of modern (and future) versions of Windows. It is easier and cheaper to update those applications by staying within the original platform than to either rewrite them in .NET, or hack up some kind of interop between the legacy and the new.

Backwards compatibility is a key facet of the Windows OS platform, and I think it is easier to achieve that by building from the ground up rather than the clouds down. I don't think writing very low level code using the Win32 API has any major benefit over using the much simpler and more friendly .NET framework (and its wrappers around lower-level API's). Perhapse, in the rare cases, where insane performance is a key requirement...but I would opt for Managed C++ before I took the C & Win32 API route. I think the API's are simply there to provide that legacy support, and packaging those low-level API's with managed wrappers for .NET is an easier way to provide modern support than doing the inverse.

---

.Net still doesn't give you direct access to the native kernal API functions and probably never will, as one of its intents is to abstract you away from the OS, to make your code more platform independant.

---

Have you ever seen a MFC application? How about win32 in straight C? Pure pain and heartache. .NET make coding fun and easy.