WinFX: An All-Managed API
Subject:   .NET, Windows API and C
Date:   2004-03-24 09:57:04
From:   anatolk
Response to: .NET, Windows API and C

Well, despite the popular belief there is no such a comparison between assembly language, C and C# for example. The assembly language is a mnemonic language of the machine, it provides you with the capabilities of the machine, it was never aimed to programming applications or building OS-es. C is already a high level language that gives all you need to program any type of application on it and that's why it is used for more than 30 years, and that's why it was chosen when Apple started writing their first graphical OS and later chosen also by Microsoft to build Windows. And then fully object oriented languages already existed, but it was considered not practical to use them and this was NOT a matter of slow hardware (please, first read what the people who worked on the first graphical OS-es tell us).
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. Not to mention other problems like finding obscure bugs. My company was using VB for a long time, now it migrated to .NET, there was a strange bug in the application and it took 3 weeks to find, scratching deeply in the application code and framework internals, i would find that bug in less than a day given that the application was written using the raw API.
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". Don't you feel the M$ outrage on their developers?
About the faster machines - on my P4 2.4 Ghz Java runs just as slow as on my P2 300 Celeron, that's all marketing tricks but is seems you and many other people just don't get it.
The reason because serious development was done in C for such a long time is not the slow hardware (what is now the popular belief), it's because it is simple to write and understand. You can do sloppy programming on any language, that's the human factor here, not the technology factor. I've seen a very complex but briliantly written programs on plain C. One example is the Mosaic code. And i've seen a really sloppy programs written in C++, Java and C#, when you read the code you feel the autor just doesn't get it right about programming. So technology can't prevent you from doing silly things.
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.
A question: Is it normal for a program consisting of a simple form with a few controls on it and doing nothing more than sitting idle to eat more than 100 MB of memory?
My C program frees memory just when it should and doesn't consume a bunch of system resources and when there is a memory leak i always find it. 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? They both have their way of automatic "garbage collection".
I was really amazed when a simple .NET program reserved 400 MB of my 512 MB of memory, got 4000 system brushes, Windows started to scream that it will increase the virtual memory, and all the system was so slowed down that it was impossible to work with any other program than the current "managable .NET application". That's what i call it a shame!
And finally what is the benefit for you as a proffesional programmer in making all programming a toy - you will be underpayed in the long run as the statistics show. You and many people seem not to know the Sergei Bubka's rule.