Win32 vs .Net

Question

Is .NET better than Win32 or the othe way around? Which would be the pros \ cons of both, in what situations one would be better than the other. Has Microsoft released .Net as a replacement for Win32?

I am not asking about the amount of projects needed to be maintained, but about new projects being developed, and which would be better for what. Do you think .Net lacks important stuff from win32 (without using dllImport )? And do you think Win32 will be replaced by .Net

I am asking this, because i am having an argument with a friend of mine, and as we both agree both must be studied in depth My friend argues that .Net is incomplete, and i say that it can manage almost any task non-driver related. Where does .Net fail?

Solution 1

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.

Solution 2

.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.

Solution 3

You already seem to be aware of the short answer, but I'll reiterate it here for clarity:

Win32: Powerful and complete. Any documented behavior on the windows platform can be composed via Win32, but with power comes responsibility and difficulty. There's a pretty significant amount of subtlety and difficulty in creating rich Win32 experiences.

.Net: Powerful, but a subset of Win32. .Net provides more than enough capability for the vast majority of line-of-business apps and more, but rich UI and specific, specialized situations simply don't exist within it because the BCL, for whatever reason, doesn't believe it makes sense to support it. The most common example that I've run across is UI capabilities in newer versions of Windows, though there are other areas where PInvoke is useful. .Net is a much simpler model to grasp and work within, however, and (in my experience) the subtlety of .net is much less likely to shoot me in the foot than Win32 is.

If you include dllimport and PInvoke, then I'd guess that .Net is a reasonable alternative that's capable of performing suitably well in 90+% of tasks, and WPF brings a whole different level of rich UI to the managed world.

Solution 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.

Solution 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.)

View more solutions

Comments

[Stephen Ostermiller]

Do you have references or anecdotes from your own experience to back your statements up? Providing your undocumented opinions is not helpful.

[HKTonyLee]

Please give a more detailed answer, e.g. comparison table or so.

[Admin]

So does the CLR source code literally call Win32 functions (stuff like CreateWindow, etc.)?

[Joel Coehoorn]

@loop123123 Yes, that is what happens.