"When Apple released their completely rewritten new os MacOS X, they provided new API's like Cocoa but they retained the old Carbon C flat API and not only for compatibility but it can access all the new funccionality of the OS and it is not considered an "old fashioned, outmoded, arcane" API but is considered a valuable API with a future. Now existing C programmers can apply their existing knowledge and simply expand it with the new OS features, making them even more productive. I didn't see such a choice in the future of Windows." --> You didn't commented this.
"You get improvement of productivity not because of the language you use, but because of the prewritten functionality that is already provided for you. No matter the language or the platform, when someone has written the complex funccionality for you, your life gets easy and you are happy. The same applies to the development environment. A good develompnet environment will speed up the development process in any language, any platform. Visual Studio is just not a good development environment for C WinAPI programs. It accented on C++, and now on .NET. Give me an environment aimed only to C WinAPI programming and my development cycle would speed up enormously. On the other side if you need to develop something from the scratch with .NET you write more code than i would write using the simple Win32 API, that's a fact i've already seen" --> You didn't commented this.
"Win32 is just a very low level API implemented, i can say that it is the lowest level user API compared to other commercial operating systems. That's why it is sometimes hard to use and slows the development, but that applies to all - you can build a house yourself and you can let other people build it for you and you just painting the walls. So there is nothing wrong with the flat C Windows API, like many people now are trying to make us think. And companies like Apple show just that - it can be used for building and using a very advanced funccionality and has a bright future, they don't force their developers to learn every few years the basic things in a "new way"." --> You didn't commented this.
"I don't claim that the classical Windows API is perfect, it is not fully consistent for example, some parts of it could be implemented in a simpler and more readable way, but that's not because the language or the architecture is bad, but because of bad practices in Microsoft and something called backward compatibility, which is a very serious issue for Microsoft. My own opinion is that the basic modules kernel, user and gdi are an example of a good (commercial) OS implementation. As you can see the kernel of NT systems is excellent and that's because it's written consistently and with a smallest amount of backward compatibility, that's why Microsoft will build even their new Longhorn system on that kernel" --> You didn't commented this.
"But why many simple programs written in MFC and in .NET reserve A LOT of system resources and don't free them until the end of the program when Windows walks their heaps and frees it? " --> You didn't commented this. And that's a (strange)fact i observed for a long time.
About the .NET program -> it's certainly a shame to take 14MB of memory doing nothing more than trivial things, it would take a 1 to 2 MB of memory in Win32.
The question - why .NET programs still run too slow on my 2.4 Ghz machine and reserve too many system resources like gdi resources for just a simple operation? It's not acceptable since system resources are limited even on modern OS-es.
I just can't imagine myself doing my work if all my programs were written in .NET. It would ovewhelm any machine at this time.
M$ is promising a real improvement of .NET over Longhorn, but we didn't seen that yet. My current Longhorn version performs just really bad on my powerfull machine (given that currently it is not based entirely on .NET and not all (even user)code is managed).
Finally, there are good arguments on both sides i think, i don't want to dispute them infinitely. I think some people feel comfortable with one thing and other people - with another, that's a kind of own choice, philosophy, name it whatever you want. I think there are '+' and '-' in both worlds, i just don't accept the notion of "perfect-ness". Well, M$ is a commercial organization after all, it should advertise it's products as good products. And it should supply new products, there isn't another way to survive on the market. I don't accept the notion of "last-ness" also, that is flying on the air with every new product or platform. We've seen that most of technologies didn't last for a very long time. An example - when COM came out like a primary way of building components and ActiveX loomed into sight, it was announced by Microsoft as "that's the way to go" (did i heard it recently somewhere?), "in the future all Windows funccionality will be provided via COM" - well, they implemented a little high level funccionality of Windows via COM and it was complex and confusing, so there were smarter teams in Microsoft that continued to provide new funccionality via flat API's and they are far easier to use, look at some excellent API's in Windows like the Fax API, that's what i call a human factor, not a technology factor.
Now COM and ActiveX are evil, .NET is "the way to go", i don't want to dispute it, we'll see the future of .NET philosophy, let's hope it is the best platform to solve all programming problems.
It's a little suspicious to mention only the good sides of a thing and never mention a bad side and that's what i see in disputs on .NET, they are just not disputs after all. I know many bad nuances and there are many critiques of the classic WinAPI, but i can't find a critique on .NET, is it perfect? Perhaps as time goes by critiques on .NET will raise also. There is a cycle in life and we will be reinventing the wheel again and again.