Win32 vs .Net [closed]

Answer 1

.NET in your question implies C# or C++/CLI? .NET with C++/CLI is something unnatural. With the other hand using C# with .NET is more comfortable than with Win32.

Answer 2

These are all from my POV. Your mileage may vary.

Advantages of .NET:

• Cross platform capability (via Mono and .Net Core)
• Good selection of framework classes typically means less code.
• Easy integration of components, regardless of the language the component was coded in. (You like F#, or IronPython, great! Code your assemblies in whichever language is most appropriate.)

Disadvantages of .NET:

• .NET means different things to different people. (For example where does WPF come into the equation?)
• Sometimes DLLImport and/or PInvoke is the only way to get to the functionality you need, which means you lose the cross-platform capability.

Advantages of WIN32:

• If you know what you are doing, you can construct great applications with minimal dependencies.
• More suitable for "low level" operations than a .NET based solution.

Disadvantages of WIN32:

• If you don't know what you're doing, you can easily shoot yourself in the foot in a more application or system fatal manner.
• You frequently have to write code that you would get "for free" using .NET.

Both have their place, and will probably continue to exist until a true replacement OS (Midori? Some form of web-based OS?) comes online and gains widespread acceptance.

Answer 3

for HW accessing WIN API is best choice. its faster because it talks to low level devices directly but no free lunch; Your code will be more complex and it does not forgive for bad coding.

Answer 4

It is not a fair comparison, there is no better between the two, it all depends on what you are trying to accomplish. For most development tasks, .Net is very sophisticated and may even have better performance than Win32. On the other hand, .Net can run even outside windows, just look at Mono. Now, for developing drivers and low level stuff you're better served with Win32.

Answer 5

.Net is not replacing Win32. Win32 is the OS level interface, and you can think of .Net as a little sub-OS environment or virtual machine that sits on top of Win32. .Net provides hardware architecture neutrality (it doesn't matter if your client is running on a Pentium IV, Core 2 Duo, Itanium, 32 bit, 64 bit, or whatever.) .Net offers an optimized installer that understands these environments, so that if an instruction says 'move a million bytes' it'll use the "most optimized" move instruction available on the platform.

.Net makes some things easier for the developer: built-in garbage collection prevents a very common error, that of forgetting to release memory. The Visual Studio IDE integration offers arguably the best development environment of any language, ever. It's certainly fast to prototype screens and code. (Of course Visual Studio offers many of the same advantages to the C/C++ coder writing to the Win32 API as well.)

But .Net achieves these things at a performance price. Code must be "just-in-time" compiled (JITted) at the end-user's machine before it can be run. The .Net framework takes anywhere from 5-15 megabytes of RAM just to load up enough code to execute "Hello World". The .Net framework won't perform well on a machine slower than 400MHz or with less than 512 MB of RAM (you can run it on a smaller, slower box but its performance will have to be evaluated on an application-by-application basis.)

Answer 6

.Net (or the WinForms parts, anyway) sits on top of Win32. Or, put another way, Win32 was used to build .Net forms components. So in that sense you can think of .Net as a set of pre-built win32 widgets. You can also think of .Net as the logical successor to MFC.

.Net also has the ability to call into the Win32 API directly when necessary, gives you garbage collection, a very nice class library in the BCL, and a lot of nice language features over C/C++ in C# and VB.Net.

What you lose to get all these things is a certain amount of independence. .Net is an add-on framework that is not shipped with all versions of windows by default, and therefore you have extra dependencies to worry about at deployment. You also have performance considerations to think about when using any high-level garbage collected language, where seemingly simple code might be doing a lot more than you expect behind the scenes. This is especially true for some of the winforms components.