What does .NET give me, that Win32 does NOT?

views:

771

answers:

+7 Q:

What does .NET give me, that Win32 does NOT?

What would the usage of .NET give me, that i don't have using Win32 - and sometimes maybe googling for some 50-100 Lines of code i can reuse?

I am developing Win32 since it exists (> 15 years). Its straight forward and very robust, although sometimes it needs some more calls than you'd expect, and of course you need to keep track of handles etc. But our (250.000 LOC) application is installed in less then 1 Minute and it very rarely has any compatibility problems.

I have followed several discussions on SO about .NET versus Win32 (i.e. http://stackoverflow.com/questions/1127546/win32-vs-net). But they don't answer this questions.

+3 A:

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

Adrian Grigore 2009-09-04 08:56:59

It is a false belief that memory leaks are a thing of the past in managed languages like C# or Java.It is actually quite easy to create memory leaks in these languages.A garbage collector does not remove the need to check for memory leaks in the application. It just removes certain types of memory leaks.Memory leaks in these languages occur still too often through Static objects holding references, unnecessary references, caching, ...

nkr1pt 2009-09-04 09:09:06

@nkr1pt, however easy it is to have have memory leaks in .Net it's still orders of magnitude easier in C++, and you also have a harder time tracking unmanaged leaks.

Pop Catalin 2009-09-04 09:11:18

@nkr1pt if you have to spend 10% of brain time ensuring that you don't have memory leaks in .net you must spend like 40-50% of brain time in native c++ is just way easier to forget something there than in .net simply because there are alot more things that you absolutely must destroy.

Konstantinos 2009-09-04 09:15:39

I completely agree with nk1pt. Java and :NEt give unexperienced programmers a false security that they had to care about nothing. in fact this is a NULL Pointer: String msString; If you don't assign anything to this it has the value null. The real problem what you mean is casting in C and C++. You can cast everything in everything. And suddenly the ponter "thinks" it is pointing to some other type of object. The .NET runtime has a cleaner way and less possibilities to do such things. In fact tis is a great benefit for the unexperienced programmer.

Thomas Maierhofer 2009-09-04 09:16:56

Programs don't only manage memory. There are other unmanaged resources out there. Are you all shure you can use and implement the IDisposable pattern correct? Do you know what is going on behind the scenes? Do you really know what the GC.SuppressFinalize() Method does and how to use it? Do you know what is happening if you don't use it? In fact unmanaged resources are harder in .NET because the C++ programmer use the same patterns he uses for memory. Unmanaged Resources eats up a lot of the benefits you get with the managed memories. And you have to care about both.

Thomas Maierhofer 2009-09-04 09:24:01

The GC enables a fundamentally cleaner API design by avoiding the need for clear ownership. Unmanaged Resources aren't a big issue - because you almost never need them (and when you do, there's a managed wrapper prepackages to be found somewhere, almost always). It doesn't fix everything, but it's ridiculous to claim it's irrelevant due to "other unmanaged resources".

Eamon Nerbonne 2009-09-04 09:32:09

I agree with those that say that .NET's memory management is better than native memory management.

Vilx- 2009-09-04 09:40:21

Sure, you can still make mistakes in C#. But saying that it's not good because it gives you a false sense of security is like walking barefoot on a heap of glass shards because sneakers might make you forget there are any shards at all, some of which micht actually pierce your shoes.

Adrian Grigore 2009-09-04 11:01:14

First of all, Win32 is written in C, not in C++, even though it can easily be called from C++. There are several quality wrappers above it, one of them being .NET. Second, you can get null reference errors in C# and you can get memory and resource leaks. Third of all, there are MANY more C++ libraries available for C++ than for C#: think about it, a language that's 30 years old vs. one that's 8 years old. And last but not least, you don't get the SAME codebase to run on Mono and .NET, because 1. they are diverging 2. Mono is still encumbered by patent uncertainty and platform immaturity.

rpg 2009-09-04 11:58:31

I don't mind my posting to be downvoted, but I would appreciate if you could give a reason...

Adrian Grigore 2009-09-04 12:46:57

@rpg: Yes, there are lots of libraries out for C++, but most of them are covering functionality that is already included in the .NET runtime. The fact that .NET allows reflection makes it so much easier to write powerful libraries. Some of these could even be written without reflection. For example, can you show me a C++ dependency injection library with a comparable feature set as Ninject?

Adrian Grigore 2009-09-04 12:54:16

The reasons are in my former comment. Points 2,4 and 5 could be clarified or changed because they are either incomplete or incorrect.

rpg 2009-09-04 12:57:37

@Eamon: There's no need to maintain clear ownership in C++ either. Just use std::tr1::shared_ptr<>. It's garbage collection on a local rule (although inherently reference-count, not some variety of mark-and-sweep). In good C++, you manage memory the same way as database connections or the like. In C#, you don't.

David Thornley 2009-09-04 17:40:38

I use share_ptr regularly, and it's emphatically *not* a replacement. First of all, it requires you to control *all* references. if an external component (one of those 100's that make C/C++ attractive in the first place) maintains a pointer, you need to manually count that. Secondly, it can't deal with cycles! Data structures that don't have an inherent hierarchy (a graph, say) are a lot more work to maintain. boost's various pointer wrappers are great - but they're miles away from a real garbage collector.

Eamon Nerbonne 2009-09-05 11:43:47

It can't deal with cycles because it is not intended to deal with cycles. If you are facing this problem, you just using it wrong.

n0rd 2009-09-08 12:00:41

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.

Jon Cage 2009-09-04 09:00:41

I think you mean Mac (as in Macintosh) rather than MAC (Media Access Control)

David Dorward 2009-09-04 09:03:17

you should never rely 100% on mono in a production environment as it is an open source project to port .NET apps to UNIX like systems.However, it is not officially supported by Microsoft, it is sponsored by Novell though, who are working closely with Microsoft these days...

nkr1pt 2009-09-04 09:07:31

Mono is very strong and useful environment, so IMO you can rely on it

abatishchev 2009-09-04 09:14:20

Not relying on mono "because it is an open source project" makes no sense whatsoever.

Eamon Nerbonne 2009-09-04 09:34:46

It would in fact be a lot harder to kill Mono. If you've got a production environment that relies on .Net, and Microsoft kills it, you're hosed. But nobody owns Mono, and certainly nobody can stop you from using Mono. If everything else fails, you can always hire a programmer yourself to support Mono as long as you need it.

MSalters 2009-09-04 09:57:16

@MSalters: do you really believe Mono could be supported by just **one** programmer?

MarkJ 2009-09-04 16:04:17

The problem with proprietary, closed-source apps is that they can get shut down when they turn unprofitable, or the company can go out of business, and you have no recourse. With an open source project, there's usually something of a user community, which can get together and do something if all the maintainers lose interest. There's commercial apps I wouldn't trust to be around next year, and open source apps that will be around for a long time.

David Thornley 2009-09-04 18:44:50

@MarkJ: yeah, it's unreasonable to assume that one guy could "support" mono. Of course, if "support" is defined to just be "keep running for one app on the limited set of configurations we actually use" - i.e. no new functionality, and no OS upgrades or whatnot - then it may be eminently feasible, if only because such support will only very rarely be needed at all. And I've seen enough bugs in .NET (presuming mono's no better in this regard) that could have trivially been fixed to my satisfaction for my project by just me - if I had the code.

Eamon Nerbonne 2009-09-05 11:38:56

+17 A:

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.

Thomas Maierhofer 2009-09-04 09:03:23

"That's why .NET can be implemented on other operating systems." -> how do you spell "mono" ?

elcuco 2009-09-04 09:16:36

Ok: IS implemented on other operating systems like linux (mono)

Thomas Maierhofer 2009-09-04 09:26:14

Note the new GC will solve the realtime problems partially.

Dykam 2009-09-04 09:33:03

Win32 is implemented on other operating systems too: see Wine (www.winehq.org)

Chris Smith 2009-09-04 14:01:23

wine...that's the not-emulator whose test suite only runs on 2 computers 100% successful, and nobody knows why, wasn't it?

flq 2009-09-04 21:30:06

+1 A:

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.

Pop Catalin 2009-09-04 09:09:18

Some advantages:

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.

smok1 2009-09-04 09:10:13

Point 3 is of dubious value. Windows has a vast codebase that has been perfected in decades of debugging and compatibility patching. Rewriting it all in .NET would be an enormous task with little added value. Also if it ever would happen, the version of .NET used would be way different than what we use now, so writing programs in .NET because of this reason is a bit silly.

Vilx- 2009-09-04 09:35:55

Win32 is already a layer on top of the NT kernel. It's quite possible that Microsoft eliminates a layer by putting Win32 side by side with .NET.

MSalters 2009-09-04 09:54:09

@Vilx – point 3 is a hypothesis. In addition, this cannot be taken as a sole reason for writing your applications in.NET exclusively while points 1 and 2 can (this answer has been downvoted, so at least there are some people who do not think COM is a sucking technology). When talking about Microsoft – they had actually done throwaway of their code at least once – when they had abandoned Win9x line after Windows Me.

smok1 2009-09-04 13:33:38

@MSalters - it would be nice if that was true, but .NET in all its current implementations is built on Win32, with lots of ugly ridiculous things leaking through, e.g. MAX_PATH which is an artifact of CreateFile but not the underlying NT syscall NtCreateFile. http://blogs.msdn.com/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx

Chris Smith 2009-09-04 14:07:34

Although point 3 sounds crazy - mono is already such an alternative implementation to some extent (Not that this is an actual advantage IMHO - who here expects win32 to die anytime soon?). Yes, you'll break .NET apps that rely on these leaky abstractions - but it's a lot easier to work around just those issues than to port a complex app to an entirely new and different framework. So, point 3 is quite realistic, if you have realistic expectations (namely that the "new" version will not run old code entirely unmodified in almost all cases).

Eamon Nerbonne 2009-09-05 11:38:12

+10 A:

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

MarkJ 2009-09-04 09:10:40

Believe me - there is very little of these 250.000 LOC that deals with the Windows API. Some 1000 Lines, maybe 10% - but not more.

RED SOFT ADAIR 2009-09-04 09:27:23

I think the won't learn .NET faster than Win32, but the will be more productive. .NET isn't that easy to learn. And C# is a complex language which is harder to understand than C++ especially since Version 3.0 (lambda expressions, LINQ ...). But if you know this, you can write code that can't be written in C++ in that elegant and direct way.

Thomas Maierhofer 2009-09-04 09:32:20

"no need to manage your own memory or handles". Incorrect, you still have to manage resources (sockets, db connections, etc need timely disposal) and you can still get memory leaks: http://www.codeproject.com/KB/showcase/IfOnlyWedUsedANTSProfiler.aspx

rpg 2009-09-04 12:00:57

@rpg - thanks, I will edit my answer. @Thomas - I would question whether LINQ is harder to learn than multiple inheritance or serious pointer work. And, as you've hinted, you don't have to learn LINQ or lambda expressions to work with NET, it just makes you more productive. There's lots of complexity to learn in Win32 before you can say "hello world".

MarkJ 2009-09-04 12:27:44

@StefanWoe: wouldn't things like LINQ for objects and lack of pointer problems increase productivity even in your 200,000 lines of non-Win32 API code?

MarkJ 2009-09-04 12:31:48

@MarkJ: Perhaps not as much as you'd think. Many LINQ tricks can be done with the STL in C++, and in some cases it even offers more flexibility. As for pointers, they can almost often be avoided. References, smart pointers and STL containers mean that you don't often *need* pointers.But it's still a valid point. One of the big benefits of .NET is little to do with Win32. It is the languages and *general* library classes you get access to for the *rest* of your application.

jalf 2009-09-04 12:47:05

I don't think C# is harder then C++. Think about function pointers, pointers to pointers, and other C++ language features which aren't easy to get your head around.

Jason Evans 2009-09-04 12:49:48

`#include <windows.h> \n int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int) { MessageBox(NULL, "Hello, world!", "Hi", MB_OK); return 0; }` It's a little more verbose than your usual Hello, world, but not by that much.

Adam Rosenfield 2009-09-04 17:18:08

@Adam Rosenfield: I meant something like the Old New Thing scratch program (as I suspect you know). Don't make me post it with a C# translation. http://blogs.msdn.com/oldnewthing/archive/2003/07/23/54576.aspx

MarkJ 2009-09-05 08:48:17

Smart pointers help a lot, but my understanding is that you can still go wrong. For instance here http://blogs.msdn.com/oldnewthing/archive/2009/11/19/9924950.aspx

MarkJ 2009-11-19 17:54:17

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

Vilx- 2009-09-04 09:28:50

There are many things that you can't do with vanilla .NET that you have to resort to PInvoke to do.

Charlie Somerville 2009-09-04 12:39:03

That's true, but most of them are pretty rarely used. And making a few PInvoke signatures isn't difficult either.

Vilx- 2009-09-04 14:46:59

+3 A:

Dependent on your region, of course, better career opportunities.

Developer Art 2009-09-04 09:29:57

Think about how much money MS has been spending on .net, u will get the answers :)

Zhongmin 2009-09-04 09:36:00

WTF?

Vilx- 2009-09-04 09:37:05

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.

Workshop Alex 2009-09-04 09:43:01

+1 A:

.NET gives you the ability to write Sql Server stored procedures in real languages. Try to do that in a Win32 DLL.

MSalters 2009-09-04 09:59:16

And why would someone ever want to do such a thing? (There could be a valid reason for this but I don't know any...)

Workshop Alex 2009-09-04 10:43:42

Hey, don't ask me why you'd want SPs in the first place. They're a pain with source versioning. At least a .Net SP has a sane syntax without 20-30 parameters, and a decent debugging environment.

MSalters 2009-09-04 11:18:24

Lol. Good answer! :-) I'm not too fond of SP's because it adds business logic to data layers. That just feels wrong. :-)

Workshop Alex 2009-09-04 11:43:35

When you need to validate several million records do you really want to round trip them to your app server? There is a time and place for everything.

Matthew Whited 2009-09-04 13:10:39

I once had to validate 50.000 records which needed to be inserted. I was working together with a DBA to solve this. In Delphi, I could do about 80% of all validations within two minutes. Then the data was sent to a stored procedure in SQL and it took over an hour to validate on the last 20% of the data. So, yes, sometimes I would want to do this in the application. (Although a million records would be a bit much.)

Workshop Alex 2009-09-04 15:30:52

+2 A:

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:

http://msdn.microsoft.com/en-us/library/ms679351%28VS.85%29.aspx

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.

jalf 2009-09-04 12:32:18

Heck, I remember the time I set out to print something in landscape mode instead of portrait. That was a learning experience in perversity. (The last guy had just printed things sideways to avoid this, but that didn't quite work when we localized to Japanese.)

David Thornley 2009-09-04 18:41:46

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.

Nemanja Trifunovic 2009-09-04 13:00:12

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

2009-09-04 21:17:51

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.

Zan Lynx 2009-09-05 05:18:45

+2 A:

Two word summary:

Garbage collection.

Doug McClean 2009-09-05 05:35:55

... if you find it useful, which I never have.

Nemanja Trifunovic 2009-09-05 15:26:44

garbage collection saves a lot of time programming a water tight memory management. And it ease the writing of exception safe code. But an experienced C++ programmer can deal with this. It is not that big thing everybody tells. Nearly nobody of these .NET programmers know what is going on behind the curtain. As mentioned in other posts programs have do deal with other resources than memory. On so called "unmanaged resources" garbage collection won't help you. It makes the life even harder. Do you know how to implement the IDisposable interface correct? Do you know what supress finalize means?

Thomas Maierhofer 2009-09-12 09:21:28

ansaurus

tags:

views:

answers:

What does .NET give me, that Win32 does NOT?

related questions