Beautiful Code [20]
The BitBlt function actually contained a mini compiler of sorts. Based on the raster operation (as well as the graphics format, the number of bits per pixel, and the size of the area), the BitBlt function assembled 8086 machine code instructions on the stack in the form of a subroutine and then executed it. This makeshift machine code routine looped through all the pixels and performed the requested raster operation.
It was the perfect solution to implementing BitBlt and its 256 raster operations. Although this mini compiler required a bit of overhead to put the machine code together on the stack, the per-pixel processing was as fast as possible, and that's what is most important when working with bitmaps. Moreover, the BitBlt code in Windows was probably much shorter than it would have been had it contained explicit code for all 256 raster operations.
It was even possible to get a little glimpse into the workings of this BitBlt mini compiler by examining the documentation of the ternary raster operations. For example, the raster operation identified by the number 0x60 implements a Boolean operation of PDSxa. When calling BitBlt, you actually supply a 32-bit raster operation code, which is documented as 0x00600365 for this operation. Notice the 0x60 byte embedded in that number, but also take note that the bottom two bytes form the number 0x0365.
The raster operation with the result of 11110110 or 0xF6 has the Boolean operation PDSxo, which is very similar to PDSxa except that it performs an OR operation rather than AND. The complete 32-bit raster operation code passed to the BitBlt function is 0x00F70265. The bottom two bytes form the number 0x0265, which is very close to the 0x0365 of PDSxa. If you examine more of these 32-bit raster operation codes, it becomes very obvious that the raster operation code itself serves as a template of sorts for the BitBlt mini compiler to assemble the proper machine code. That technique saves BitBlt both the memory and time required to use a lookup table.
Of course, Windows 1.0 was created over 20 years ago. We have all moved on, and so has Windows itself. These days my preferred programming language is neither assembly language nor C, but C#. I usually write what's called managed code that runs under the Microsoft .NET Framework. The C# compiler turns my source code into processor-independent Intermediate Language (often referred to as Microsoft Intermediate Language, or MSIL). Only later, when the program is run, does the .NET Common Language Run-time use a just-in-time compiler to convert that Intermediate Language into machine code appropriate for the runtime processor.
And yet digital image processing of all sorts still cries out for unusual approaches to coding. When working with millions of pixels, the per-pixel processing has to be fast, fast, fast. For commercial products, you will probably want to hire an assembly language programmer or someone who knows how to target the Graphics Processing Unit (GPU) found on video boards. Even for casual or noncommercial software, you will probably want something faster than the normal high-level language loop.
I was recently reminded of the on-the-fly code generation of the original Windows BitBlt function while experimenting with some C# code to implement digital image filters, also called image filters or digital filters. Raster operations such as those implemented in the Windows BitBlt and StretchBlt functions apply only to corresponding pixels of a source, destination, and pattern. Digital filters take surrounding pixels into account. You apply a particular digital filter to a bitmap to change it in some way, perhaps to sharpen the edges or even blur the overall image. A blur filter, for example, averages a group of surrounding pixels to calculate a destination pixel.