.net - win32 - windows tail command powershell
What does.NET give me, that Win32 does NOT? (10)
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. Win32 vs .Net). But they don't answer this questions.
.NET gives you the ability to write Sql Server stored procedures in real languages. Try to do that in a Win32 DLL.
.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.
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 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#.
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".
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.
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.
Two word summary:
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.
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.