Tuesday, 18 March, 2003

Windows Assembly Language Programming

I've heard it said that assembly language programming for Windows "isn't really assembly language programming."  The people putting forth this claim usually point out that when you write assembly language programs for Windows, a very large part of your code is just building stack frames and calling Windows functions.  This is somehow "less worthy," I guess, than how you do things in DOS or Linux.  That is, pack things in registers and invoke an interrupt.  (Although in Linux you also have access to glibc, which you would access by building a stack frame and calling a named function.  In fact, invoking the interrupt functions in Linux is highly discouraged because in theory functions change from version to version.  In practice, functions are added in successive versions, but there are very few, if any, changes to existing functions.)

Extremists will point out that the existence of any operating system makes what you're doing something less than "real" assembly language programming.  If you're not talking directly to the hardware, they say, then it's not really ASM.  Oddly, BIOS routines seem to be included in most definitions of "the hardware."  I suspect because most of these uninformed extremists would find it rather inconvenient to write their own IDE interface software, or decode keyboard characters.   

What a load of bull.  Unless you're doing embedded systems work, you will have to interface with an operating system.  So some operating systems let you refer to functions by name rather than cryptic interrupt function numbers.  Big deal!   One way you pass parameters on the stack, and the other you stuff registers.  What's the difference?  If you want to show somebody how to stuff registers, build your own internal functions and call them!  And, really, from the user program's point of view, there's no essential difference between invoking a software interrupt and calling a function.  Besides, interfacing with the operating system is such a small part of assembly language programming as to make the particular method almost insignificant.

The important lessons in assembly language programming have to do with the processor—and you use the same instructions there regardless of how the operating system provides its services.