It's true that assembly language can be useful. It can make certain operations faster, through the use of optimization techniques. It can make your code smaller and faster, but the disadvantages of using assembly often outweigh the merits.

Assembly is good for two things. The first is for when you need to access hardware. Writing routines to interact with the hardware can be easier and cleaner than the equivalent operation in C. It is not difficult to export the assembly routines to make them callable from C or some other language, so you can get the advantage of having precise control over the hardware without having to write your entire program in assembly.

The other thing assembly is good for is optimizing certain parts of a program. If you have an extremely time critical routine that is called a lot, then it makes sense to go through it with a fine toothed comb and choke every possible cycle out of it. You have to look at the speed gain and compare it to the time you spent optimizing the code. If you spent three hours optimizing a routine, and you only get a 2 microsecond speed gain, then you have to call that routine billions of times to make it worthwhile. In most cases, its simply not worth the effort. Embedded applications and DSP are areas where hand optimization might make a significant difference, but unless you doing some extreme number crunching on a PC, its probably not worth it.

Assembly is hard. You can't glance at the code and know what its doing. It's not at all self documenting, its not portable, and its difficult to maintain. Its also easier to make mistakes in assembly, and harder to fix them. I'm willing to bet that the time spent writing a routine in assembly will be much greater than the time spent writing the equivalent in C.

I was going to argue about the ugliness of the x86 memory models, but Whizkid points out that code for Windows 95 can run in protected mode, so the memory model is flat and writing assembly becomes not much worse than writing for a RISC machine. The instruction set is just more complicated.

Whizkid seems to suggest writing entire programs in assembly, and complains about the bloated slowness of Windows libraries. It's true that any Visual Basic program has a load of runtime stuff following it around, including the OLE libraries. A C++ program will usually use MFC, which is difficult to use and has its own bloated runtime libraries pulling things to a crawl. A C program will use the Win32 API directly, but so will any assembly program that doesn't want to draw it's own interface. So either way you go, you only gain from using assembly in hard core number crunching routines that get used a lot. Even in assembly, you have to rely on the API to provide an interface, unless you want to write you own interface library in assembly. If the only thing your doing is calling the API, you don't get the advantages of using assembly, but you get all of the disadvantages. When you write something in assembly that just calls a lot of API functions, you get to waste your time setting up the stack. So instead of one line of C code, you write 10 lines of assembly, just to call a function. That's just silly.

Bloat doesn't have to come from libraries either. You can just as easily write big, slow, inelegant code in assembly as you can in C or any other language. Part of writing good code is knowing how to use your tools and libraries correctly, and in the application of good, solid design. Sitting down and coding with a vague goal in mind but no solid design will give you slow and ugly code, no matter what language you're using.

It comes down to having the right tool for the job. If you can hand optimize a routine better than a modern C or C++ compiler can, then use assembly and build a library that can be called from another program. If you want to write a device driver, use assembly if you want, but C is about as good and easier to maintain. If you're writing GUI that relies on a library like GTK+ or the Windows API, then your better off in C or C++ or whatever your favorite language is. It just doesn't make sense to do everything in assembly. If I write a binary tree library in assembly on an x86, but then I go and buy a Sun or something, I have to waste enormous amounts of time converting it. I could write it in C or C++ and just recompile.

Whizkid says he just wants to see information about how to do it from companies like Microsoft. Well, if you have the C prototypes for a library, you can figure out what you need to put on the stack to call it from assembly. It doesn't make sense for Microsoft to put any effort into releasing assembly specific information. They have development customers who are usually companies who don't have time to use assembly. They want fast development time, not fast code, so that's what Microsoft tries to give them. Corporations using Microsoft tools like Visual Basic are usually writing business applications for in house use that basically consist of storing things in a database and then generating reports on them. So that's the customer that Microsoft caters to, resulting in things like ADO. Hard core computer science where assembly might be used comes into play in other problems, and the people solving those problems look to academia for information, not to Microsoft.

I think part of Whizkid's argument for assembly rests on the "coolness" factor. Doing something just to see if it can be done. That sort of thing. Sure, I do things like that too, but it won't fly in industry.

Back in the day, a programmer knew everything he needed to know. Now, there's so much information that you have to keep refering to your reference manuals just to get through a simple project. Maybe so, but the libaries and OS's of today give the programmer so much more. You can accomplish a lot more by making a few libary or system calls now than you could then. You don't have to write your own routines to handle input and output any more. Instead of wasting time with that, you can solve the problem you want to solve. Time spent looking up a library call is nothing compared to writing the function yourself.

Give me assembly or give me death? No, give me the right tool to get the job done.