The answer is quite simple: A higher level of abstraction and decoupling from the "real" things behind the scenes. That's why .NET can be implemented on other operating systems.
In fact this is all possible without .NET but it isn't practicable. Short Example: The WCF in .NET gives you a first class IPC and SOA Framework that everybody can use. It is built in functionality. In win32 you get the same self coding, with third party libraries or whatever. The user base is small, you don't have that big community supporting you with your issues, and it is hard to implement at all. The .NET Framework gives you these things out of the box.
For a vast amount of applications .NET will speed the develop time and make the development just cheaper.
For special kind of applications the opposite is true. E.G. it is (nearly) impossible to develop real time applications with .NET because GC on Level 2 freezes all your threads.
The .NET framework 4.5 includes a augmented garbage collector. It enables a multithreaded background garbage collection for the server garbage collector ( enabled with the <gcServer> element in app.config) which doesn't freeze the application threads.
Unfortunately the Mono garbage collector is not nearly that advanced, so the basic statement is still true for Mono.
IMHO only someone who's been developing Win32 for more than 15 years could call it straightforward and robust. And if you're willing to write the whole 250,000 lines yourself rather than use components, then sure, your application will install easily. I'm not sure the tradeoff is necessarily worth it.
What .NET gives you is faster development, for all sorts of reasons. Higher abstractions, great components to drop in, no pointer problems, less need to manage your own memory or handles. If you've been developing Win32 for 15 years, maybe you won't need any of that. Do you ever hire new junior programmers though? I'm sure they'd learn .NET faster than Win32. There's so much to learn in Win32 before you can even say "Hello world".
Ease of use. And easy interoperability with the rest of the .NET framework (the non-Win32-related parts).
There's nothing magical about .NET, it's just a huge number of predefined classes for doing common tasks easily. And many of those tasks are stuff like "create a window" or other Win32 functionality.
As for Win32 being "straightforward and robust", I don't think so.
Here's a wonderful example: One of the most fundamental pieces of functionality a programmer is going to need: That of retrieving the error message associated with the error that just occurred:
- 7 parameters
- Two tables to read to understand the parameters
- Security remarks to take into account
- Special, specific functions (LocalFree) that must be called to release the system-allocated buffer.
Just to achieve this simple piece of functionality? And this is "straightforward"?
The Win32 API is one of the worst-designed, most convoluted and hard-to-use (correctly, at least) API's in existence. The only thing it manages to do consistently is to make the easy, intuitive usage wrong, and require a lot of footwork to achieve correctness.
But of course, anyone who's spent a decade working with the API has already faced these issues and are used to them. For you it may be no problem. And even better, since you already have your application, you might as well stick with it. There's no reason to throw it out and start over in .NET
But if you were starting a project from scratch today, then
- The learning curve would be a lot friendlier in .NET (but again, if you're already past the learning curve, that's less important)
- The scope for error would be reduced in .NET (it's much harder to call functions in the "wrong" way, and even if you do, fewer bad things can happen)
- It'd be easier to find new programmers to join your team
- Most people are far more productive in a language like C# than C or C++. One of the major things .NET offers is the ability to use .NET languages. Compared to that, the class library could be considered the icing on the cake.
I've developed games in C++ for about 8 years before switching to web development on ASP.NET / ASP.NET MVC. From my point of view these are the most important advantages when using .NET instead of native C++ code:
- Very good IDE tools. Resharper can do so much more than VisualAssist
- No more invalid /null pointer errors or leaked memory problems
- A solid runtime with a much nicer API than Win32
- Lots of great open-source .NET libraries, more than I could find for C++ (even though there is no C# Boost)
- Thanks to Mono, porting your software to another plattform is easier than with C++
Two word summary:
WinAPI is for interacting with Windows at the lowest level, and covers every feature the Windows OS provides to the consumers.
.Net is a framework, a runtime and a big collection of libraries which serve different purposes and abstract the Windows API. It basically provides OO abstractions that hide the windows API.
If you use .Net you still use WinAPI transparently and can use it directly if you chose to by PInvoking into the native API.
Whether to chose .Net over WinAPI depends on the type of application you want to build. If it's a heavily shell integrated application then use WinAPI, if it's not, but you need to use powerfull XML, connectivity (WCF), graphical (WPF) or data access (ADO.Net, Linq) libraries and need the productivity boost .Net offers and trading a over some flexibility (you need to make sure .Net runs on target computer, which isn't a big deal anymore) is not and issue, then chose .Net.
.NET itself actually wraps around Win32 API, so there is in principle nothing that you can do with .NET that you could not do with Win32 API. The advantage of .NET is the ease of development - which also means faster deliveries and less bugs. The debugging capabilities are also much better in .NET.
The speed of installation and runtime of .NET is not much an issue. You can write crappy software in any language, just as you can write good software in any language. There are different tips and tricks in .NET than there are in C++ (so that's definately a learning curve there) but in the end both are equally good.
I've even heard a rumour that a well written C# program can actually be faster than an equivalent C++ program because the JIT compiler can optimize the assembly for the specific CPU while the C++ optimizer can only make generic optimizations. I don't know if this is true however.
Compatibility of .NET software is also similar to C++. On one hand it requires the .NET framework to be installed, but on the other hand - no more DLL hell because of strong names and GAC. And a lot of stuff is already in the default installation for which you would normally require 3rd party libraries in C++ (like XML parsing, DB connectivity, SOAP web serivices, RPC, etc.) It balances out I think, and the smaller size of .NET executables is definately a bonus.
It is hard to answer this one without knowing more about the nature of your application. If it is a typical internal business application with lots of db access and report generating, I would say that .NET brings a lot to the table. If it is i.e. a game, or image processing, or in general something you are selling to a wide range of customers, I would stick to Win32.
.NET gives you the ability to write Sql Server stored procedures in real languages. Try to do that in a Win32 DLL.
Multi-language support. It is easy now to write application In Delphi and use this application’s logic In code written In VB. No more COM, no more exotic calling techniques – just “Add reference” and it simply works. Mostly, because as always some problems arise, but .NET problems are almost nonexistent when compared to COM.
Easy usage. In Win32 API every single call should have a lot of initialization code. After initialization, you usually had to call API method with some flags to know what to expect and how to allocate buffers for this call, and then call this API method again, with other parameters to actually do the job. After all, there was some cleaning up code. In .NET you usually just call some method, since all messy stuff has been hidden inside.
.NET is way above WinAPI. So, now Framework is written using WinAPI, but in few years (say Windows 9?) it will be .NET Framework what will be exposed by kernel. Legacy applications will use some legacy translator – WinAPI written in .NET Framework.
When I was developing MS-DOS applications, I also wondered something similar about Windows development. Windows was interesting but I felt DOS was more practical. That is, until I started to write Windows applications and noticed that the Windows API was quite useful. The RAD environment that I used for Windows (Delphi) made it very easy for me to develop a nice GUI for my application. With Borland Pascal, this was a bit more complex although Turbo Vision did provide a very useful environment for DOS.
When .NET was introduced, about 8 years ago, I just considered it to be a big runtime library for Windows applications, just like Windows itself was a cool graphical library for MS-DOS. It's not a Silver Bullet or Golden Hammer to smite your problems towards solutions. It's just something that makes development easier.
Still, when I compare my Windows applications with MS-DOS, I still feel that DOS was even more robust. But Windows makes much, much more possible for me to do with a lot of ease. The same applies when you compare .NET with WIN32. Things just become easier to develop.
Aside from the points you've already made..
- .NET is less platform dependant (under mono it will run on Windows, Linux, OS X, BSD etc.)
- You can write .NET code in VB, C#, C++ etc. and have modules written in the different languages all working happily together without too much pain.
Actually I think you'll find .NET wraps a lot of win32 functionality.
I have found that form editor in Visual Studio Express 8 consistently crashes the entire IDE when I'm coding C++ with .NET. This does not happen when I do C++ with plain Win32. This does not happen when I am coding forms with .NET and C#, so I have been forced to never use .NET again except with C#.
Virtual machines like .NET uses are very good for crossplatform coding. If you don't make any unmanaged calls out to functions outside of .NET then it can run anywhere .NET is supported.
Like the X-Box 360. Or Windows CE/Mobile/Whatever.
It's going to be a good thing for Microsoft and Windows developers because low power devices will be more efficient with a CPU like ARM. An ARM is not going to run your IA32 Windows app, but it would run your .NET app after MS gets through building .NET for ARM WinCE.
Java does this too of course, and its better and more mature in its cross-platform support if that is what you're going for.