.NET vs. Windows API programming

Does anybody of you .NET guys ever explored the Windows API?
You can't say "NET is great" without knowing everything about the underlying princliples of the OS, i.e, the Windows API. I'm programming using only the Windows API and ANSI C for a long time and i can say that it is a great OS architecture, easy, expandable and powerfull. Most of the things i write using the Windows API are quite more complicated and far from what is really going using the .NET. It isn't true that .NET makes things easier - it makes things more complicated. On the API level things are very generalized, the programmer doesn't need to remember a myriad of different classes with different methods. Windows itself is object oriented. You manipulate everything using handles that the API gives you, handles are just private Windows structures and represent objects. So, when you write an API program using ANSI C, you actually write an object oriented program. Windows API is for experienced C programmers who understand the internal workings and architecture of the OS, that's the reason many people don't like it, because they lack a knowledge about C and how Windows works internally. Yes, it seems difficult at first sight - all those large functions, large structures, pointers, pointers to functions, switch cases, Hungarian notation, etc. But once you understand the principles everything clears up and you discover the amazing, elegant, clear and simple architecture of Windows.
Actually .NET is build straight to the API. That' s why you see things like "WndProc()"," intPtr", etc in its debugger.
Have you ever seen a Windows 1.0 application built in 1985 running on .NET Server 2003. Me, yes.
This fact demonstrates the stability of the Windows API through the years.
It isn't true that a .NET application is fast, it is actually very slow. It has to link to more than 25 dlls and you can see that using a program that shows you how many dll's an application is using (don't use Depends, it only shows you that your app is linked to the core .NET dll). .NET apps are slow because of dll layering, there are too many layers on top of the native Windows API that should be called. So even it is compiled to native machine code it still has to go through all those layers on every function call.
Well, if you have an Intel P4 2.4 Ghz with 512 RAM it should seem reasonably fast, but try it with an Intel Celeron 300Mhz and 128 or even 256 RAM. Even on today's fast processors it ends up slow if you do something more than the conventional things. I've seen a .NET app with 20 controls on a form that extract their content from a database that loads very slowly and even hardly paints on a P4 1.8 Ghz with 512 RAM. It is a shame for Microsoft!
But, yes the .NET IDE is great, Microsoft always built great IDE's, despite tha fact that they could incorporate more facilities for API programmers into it.
As i see, currently Microsoft are not very excited about .NET, as they were at the beginning.
They've done just the same with COM, OLE, ActiveX, VB, MFC, etc. They were very excited at first, saying that these technologies would be the future of Windows and when they saw that competitors attract developers with easy-to-use tools they abandon these technologies and "invent a new paradigm".
Microsoft is a commercial organization and they need to ship more and more new products to the market to survive as a competitor, despite of the fact that current tools are actually enough both for developers and for users.
So, my point here is - if you are not familiar with Windows history, Windows architecture, Windows internals and ask questions like "what is COM?" or "what is Win32API?", or didn't program for a long time using the raw API, try to familiarize yourself with those concepts and then make your conclusion.

Don't you maybe belong over in the C/C++ forum? In truth, all of us over there are aware of these limitations. Over here, we're probably looking to take advantage of the interoperability of the .NET toys.

For instance, just yesterday emladris and I took advantage of the interoperability features to publish a web serverice in C running on an OpenBSD machine, and consume it with .NET on a windows machine. That's huge, and something that wasn't easy to do before .NET.

So before you get too down on .NET, remember that it does serve a purpose.

anatol, you really moved me with your encouraging speech and you may have apoint but the one thing you remembered me about is the way core assembler programmers were pushed away by the windows programming. Isn't it true that ASM programming had the fastest execution time ever... but at some point it isn't just about execution speed as much as it is about meeting code delivery deadlines and beeing able to use new technologies fast and withoud to much overhead... I'm not saying that you don't have a point. But try to beyond your frustrations a little bit. Good luck ...

hi mikanu.

Well, that's another side of the story, there is a need for fast development and it's hard to do it in assembler. But actually my point here is not about fast execution. My point here is about how Windows was written and what is the proper programmer interface and application architecture for writing programs for that OS. I've used the core API and VB, Java, Delphi and .NET and my conclusion is that is much more simplistic to do most of the task in Windows using the core API than any of it's wrappers. The simplicity with wrappers comes from the enormous code that's written by Microsoft that capsulates the API. If there was a true IDE for API programmers and libraries that capsulate the very low level API code that is taking too much time to write, i'm sure that development time of API programs would be as short as with .NET, development would be simpler and most of the misunderstandings about how your program works and what it actually does would be cleared in favour of debugging.
And about speed - I understand that Java and .NET programs are slow on my old 300Mhz machine with 256 RAM, but i'm really disappointed that it is performing slow on my Intel P4 1.8Mhz with 512 DDR 400 RAM and Asus mainboard.
And i've seen more Java and .NET programs crashing with errors or exceptions than API programs.
I've actually never seen a Java program that doesn't crash at some point.
There are a miriad of technologies now and many development tools and every programmer and organization is free to choose whatever it wants and i'm not writing this article to impose some specific way of doing things. Just read documentation thoroughly, write code and experiment, programmers should know what is actually going on under the hood, if not, try to become a financial manager...

I've done C and Windows API programming 12+ years ago. Then VB came along and things really changed. I've worked in VB, Visual C++ and Visual J++. And now more recently C#.

Is the API more powerfull....No doubt about it. Is it easier to write code....NO WAY NO HOW. Is it easier to learn....NOT EVEN CLOSE.

I see no need for writing C Windows API unless you find something that .NET or one of the other development environments doesn't give you.

It may be great for you, BUT not for most. Especially when you have a team of 30 engineers with different skill sets all working a common project. Instead of taking us 1 year to finish the project using C#, I expect more like 2 or 3 years using C and Windows API. The IDE makes it that much easier.

So what you say? The IDE makes it easier to write. And i say if it was an IDE for API programming equitvalent to the IDE for .NET programming it will be equivalent easy to write an app.(not to say easier). And what does VB made easy? Programming simple forms? Yes and no, this is equivalent simple with the resource scripts. But most applications need more than putting some controls on a form and setting some event handlers. And when an applications needed more than this a VB programmer should declare API functions, API constants, API structs and the API code with VB became a terrible thing, larger than the C code and absolutely inadequate to the environment. Not to say that VB was again just a wrapper to the API and when there was a way to implement some complex thing in C with some simple pointer arithmetic, VB programmers should do complex gymnastcis to do the same thing without pointers since the VB runtime couldn't give a VB programmer all the functionality needed. Yes, programming ActiveX with VB was a snap, but behind all the runtime there was a complex C COM code and the VB programmer had no idea what is IUnknown or IDispatch and having no idea what you are doing is no good, soon or later it will come to you.
Now the same with .NET - the next wrapper around the API. And things are going more and more complex with the advent of the next API wrapper. More and more objects and the poor programmer has to learn the enourmous object model and now just the IDE is what makes programming easier, not the .NET. If there was no intelisense in the IDE how could you remember the object model with all the obejcts, properties, member functions, adapters, constants, etc.
And the API programming is simple and consistent. From the drivers and base Windows services to user interface and multimedia services. When i have to create a new thread i just call CreateThread with a pointer to the callback function that represents the thread and that's all. And in .NET i have to set up some OBJECTS first. If i want to use the standard windows controls i just use the predefined classes, if not, i can subclass a control, superclass it or develop a new control from the scratch, just respond to messages and isn't it OOP, It is OOP. Every object is represented internally by a structure and giving a client a handle which is just a void pointer to the structure, then any public operation on that object is done via functions that take a handle to the object as first argument. That's why Windows is called an object oriented system. Everything from drivers to user interface is represented by handles which are just void pointers to internal structures. And they are "internal structures" because Windows is a commercial product and Microsoft has to protect his property, which is right.
And don't you thing that if you hire 30 API programmers with a good IDE you will work it out faster than hiring people coming from different programming environments with different skills to collaborate. I've already seen this.
But people with poor skills and poor knowledge are cheaper. And knowledgeble programmers with long experience are expensive. And nowadays ignorance and lack of knowledge reigns.
So what are we talking about here, not about programming...