WinFX: An All-Managed API
Subject:   .NET, Windows API and C
Date:   2004-03-24 02:51:31
From:   igriffiths
Response to: .NET, Windows API and C


I've been working with Win32 for about 10 years now, first using C and then C++. It is, as you rightly point out, a powerful API, but I think you also nailed it when you said "for those who strain their brains to understand it"

Is it really the sign of a good API that you have to strain your brain to understand it? Is my time as a developer better spent dealing with complexity in the API, or improving the functionality of my applications?

You say that you've "never seen something that can't be done with it" but then isn't that true of assembly language? Why are you writing in C when you could be writing assembly language - after all there's nothing that can't be done in assembler, and C adds overhead. (Overhead is one of the complaints you say you have about the .NET framework. So if overhead is that much of a problem to you, you really shouldn't be using high level languages at all, since you can only truly minimize your overheads by writing in assembly language.)

Of course the reason we use higher level technologies is that we get an improvement in productivity in exchange for the increase in runtime overheads. You have clearly already bought into this to some extent because you use C. So why do you reject the exact same tradeoff when looking at .NET?

You also say something which is, quite frankly, beyond belief: "all i find is an unnecessary complexity, obscurity"

If you really think that using .NET is more complex and obscure than Win32 then I find it very hard to believe that you've really used both. (It doesn't sound like you've even tried to 'strain your brain to understand it' even though you were happy enough to put that effort in for Win32.)

Would I be right in thinking that you've never been through a complete product development cycle in .NET? Your reaction is typical of someone who is familiar and happy with Win32 and who hasn't tried .NET in earnest yet, and has merely played with it a little and decided that it is not to their taste.

I've been using .NET for years now. (I started back in the beta days.) I still do C++ development in Win32 reasonably frequently though - sometimes my customers need code to run on non-.NET systems. And every time I have to go back to Win32, I am amazed by how much more effort it is. Everything takes about three times longer than it would have done in .NET.

(To give you a few specific examples I came across in a recent project: making an outbound HTTP request and parsing the text that came back; extracting a list of cookies from an incoming HTTP request; getting a piece of work called on a thread pool thread. All of these things are substantially more complex and more error prone in the Win32 world than in .NET. Of course you can do all these things in Win32 (or IIS) but it just takes a whole lot longer.)

And I'm not the only one who finds this - I know lots of people who work with both technologies and they have all found the same thing. .NET is simply way more productive than Win32 was. The only people I know who prefer Win32 are people who've never written a real product in .NET.

(And by the way, Win32 isn't going away. It'll be there for ever even though it will cease to be the primary API. It's just that new OS functionality will be targetted primarily at .NET applications. Win32 applications will still be able to use new features, they'll just be required to go through an interop layer to use them. But because C and Win32 have much higher development costs than .NET coding, they will become increasingly marginalized. Just like assembly language, they will still have their place, but it will be an ever smaller niche - as machines get faster, the performance benefits offered by these low-level technologies cease to justify the increased development costs.)

Full Threads Oldest First

Showing messages 1 through 1 of 1.

  • .NET, Windows API and C
    2004-03-24 09:57:04  anatolk [View]

    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.