Doo doo doo Doooooo, Doo doo doo Doooooo, Doo doo doo Dooo doo doo doo Dooo doo doo doo Doooooo *beat*
Doo doo doo Dooo doo doo doo Dooo doo Doo doo Dooooo.

Castle Adventure, written in 1984, is one of the first computer games I ever played. It had an impact. Written in BASIC and rendered in 40 by 25 characters of IBM text, Castle is one of the earliest DOS graphic adventure games and a precursor to all the great Sierra games I later loved. With 83 rooms, real-time monster fights, sound, two-word text commands and a simple goal of escape, it was intense. As a six year old I had the motor skills to move from room to room with the arrow keys, the street smarts to flee the approaching smiley faces and the pattern recognition to match the words “a” and “the” to my Berenstain Bears book, but the illiteracy to keep me from understanding any of the rest. I couldn’t read a single sentence or type a single command. The room descriptions were as much a mystery as where the game even came from. That last one is still a mystery; I’m imagining a single floppy disk with GAMES scrawled on it, passed around and copied into oblivion by America’s engineers with their home computers, forming a national sneaker-net whose demise Lyndon LaRouche still rails about.

Sadly, Castle hasn’t aged well. It’s not just because it’s a DOS game, or that it has no colors, or that its liberal spelling of RUBYS might lose you a dispute with your mom (it did), or even that it was written in BASIC. Castle was doomed from the start! The game’s timing is tethered to the CPU speed, so if your computer is too fast, which it has been since 1986, then the monsters are too fast and the game becomes unplayable. Even if you avoid monstrous conflicts, things aren’t the same. While amazingly even the latest 32-bit Windows can run the original game, Castle’s access to the internal PC speaker has been revoked, so you won’t be hearing sounds and music out of that device you forgot you don’t even have anymore. Even the graphics are off as the Windows command prompt fonts are only approximations of the original glyphs burned into video BIOS chips. Finally, as the command prompt has lost full screen ability, so too has Castle.

The standard solution to all of these problems nowadays is DOSBox, the most Heroic software project ever undertaken by humans. DOSBox plays Castle beautifully, emulates the environment perfectly and runs on all operating systems. BUT… there are some barriers to entry. First you have to know about DOSBox, then you have to configure DOSBox, which means you have to know how to do that, then you have to find the original Castle, then once you get DOSBox running and Castle loaded you have to know that it’s still too fast and that you need to crank down the emulation speed to a crawl, and so you need to know how to do that… all of which is fine for us faithful nerds but it’s a lot more complicated than when I was six.

There’s also an issue that emulation doesn’t address: exactly what is the correct speed to run Castle? I love this question because there’s only one man who knows the answer, and that’s the game’s author, Kevin Bales! There is only one machine that runs Castle at the correct speed, and that’s the machine Kevin Bales wrote it on. Since that machine’s identity is unknown, so is the correctness. But since it’s my childhood I have a pretty good notion as to what it should be, but that’s all it is, a notion locked in the brain.

So the problem of preserving Castle for the ages has been solved… but it’s not a one-click shiny-button affair. And it involves some subjective technical issues intertwined with some serious childhood nostalgia. And hey you know what, those SAVE and LOAD commands in the game never worked! Also… I can program computers. Uh-oh.

So I rebuilt Castle from scratch as a native Windows program! There, I’ve admitted it. Actually, I did this two years ago. I think it might have been a cry for help, but if that’s true then I didn’t do a very good job because I forgot to tell people. Have I learned nothing from Dr. Strangelove?

Castle Adventure is a standalone application that looks, acts, sounds and feels exactly like the original within a tolerance of 1 Benshoof. It’s written to be immediately playable, portable and run on all Windows machines until the end of all humans. The game contains an image of the original IBM PC font for consistent display, the game speed is fixed instead of machine-dependent and the internal PC speaker sounds have been converted to WAV format so that they play as standard audio. I’ve also embedded the original data file, castle.ran, and use it for drawing the rooms and their descriptions so I can promise brick-by-brick and typo-by-typo accuracy. (Try not to challenge your mom on how to spell COORIDOR.)

As the source code to Castle has never been released, I had to reverse engineer all of the text commands and general behavior. I took everything I knew about the game and worked from there. I inspected all of the raw text embedded in the original program file for things I didn’t know, which I found, and I snooped through the source of an Allegro graphical remake to see if there were any rules I didn’t know, which there were. With all of that and a couple DOSBox windows open for quick testing, I believe I have every command handled identically to the original, but since it was just me giving it my best shot I can’t guarantee it. Try to find a mistake! In a few rare instances I exercised editorial privilege, but only where I believed there to be an unintentional oversight that detracted from the original’s spirit. These were extreme edge cases that not even diehards should notice, though I’d really be thrilled if anyone did.

Finally… fighting. There was some serious reverse engineering in the beginning to lay the groundwork… but then I just made up the rest until it was close enough. I found some surprising things about the original implementation, including what I consider a game changer, but the short version is that fighting is a very subjective experience in the original game. There are almost no visible indicators as to how a fight is going or how anyone is doing and it’s all tied up in how fast your CPU is and how a DOS program handles keyboard input and timing events. All of that was already completely different in my Windows version but even if it wasn’t it wouldn’t matter because a good deal of the fight logic is random anyway. So I just made some stuff up, and since no one knows how it really works, and it only “worked” on one machine ever, I think we’re good. It feels about right.

So please enjoy Castle Adventure, now for Microsoft Windows! You can toggle the display through three timely colors of Gray, Green and Amber because back then our monitor had a switch on the front that let me do exactly that. I figure it was for spicing up monochrome programs, and consarn it that’s exactly what I did when I got bored with Gray walls. There’s also a Full Screen mode which I recommend using on the largest TV you can find, preferably if said TV is mounted in a major American airport. Anything to stop the CNN. And please please enjoy the SAVE and LOAD commands, because they’ve waited 26 years to work.

If you do enjoy this, and at this point even if you don’t, I’d like to hear about it. I’m especially interested in any discrepancies you can find between this and the original. Unintentional ones will be quickly exterminated and credited. Oh, and I’m especially especially interested in hearing from you if you are Kevin Bales! Though I may need to verify your identity with a question that only you would know, such as “What room is the lamp in?”

PS: Macintosh friends, theoretical Linux acquaintances, let me tell you how Castle runs on WINE: LIKE A WOLVERINE, and I’ve seen a wolverine so I know what I’m talking about.

Castle.exe

The box boasted brightly colored plastic Pac-Men, ghosts, marbles and “as much fun as the action-packed arcade game of the same name”. I played this game once in 4th grade. It sucked. I didn’t use language like that back then but I’m pretty sure I said “Wow, this sucks”. The game was too confusing to play and the pieces were too crummy to play with. I’m not saying my childhood ended there, but between that and the Transformers movie it was a tough time to be a kid.

Two years ago I crossed paths with a copy of the game in a cabin on the Taku River. Letting down my guard for the first time in almost two decades I gave it another shot. It… still kinda sucked, but by this time I’d developed a sense of irony about the surprising complexity of the rules and the questionable optimism of dice-based arcade action. It turns out that it’s pretty fun to decipher and debate the ambiguous and occasionally contradictory rules of an ancient children’s game, especially when it involves carefully quoting the aged inside of a cardboard lid like a constitutional scholar. I wondered how a child of the 80s was ever supposed to play this, what the rules would look like if they were written clearly, how many of them would be left once those that were non-applicable and canceled each other out were removed, how many would have to be inferred to fill in the gaps, and then what the first if statement might look like… at which point I knew I was doomed.

So I took the board game and made a video game version! In the spirit of translating a book from English to Japanese and then back to English, I present Pac-Man The Video Game Of The Board Game Of The Video Game! Is it as much fun as the board game of the arcade game of the same name? I can’t promise that, don’t hold me to that.

Wait, It gets worse! It’s… um… a Windows program. Spider Solitaire, Minesweeper, I’m gunning for you! It’s got sound, music, computer players, instructions, and a full screen mode that screams “this is a poor use of a large screen”. The game is a standalone program that due to its low-tech nature runs on Windows 95, Windows 7, and everything in between. There’s nothing to install, it’s just a small executable. If your computer can play MIDI files then you’ll hear music, otherwise not so much.

Pac-Man is a two-to-four player game that can be played by humans and/or computer. Unlike the board game you can jump right into this version without knowing the rules. If you can make a move, it’s legal. This tautology cuts through a lot of the confusion. The game can be played with either a mouse or keyboard (and just between you and me, a Windows Media Center remote control) and if I’ve done my job then you should be able to quickly figure the controls on your own, though all of the details can be found in the Help menu under Instructions. It was so hard to condense all the rules into terse bullet points with consistent tense that I saved it for last, which was fitting since this was basically the challenge that led to this whole project. Sirs Milton & Bradley: take look and take note!

To build this I’ve had to make some tough calls on the rules. Some of these were a result of interpretation, others were driven by implementation. If Pac-Man was the centerpiece of your family’s game night then you’re bound to find something to take issue with, but that’s okay because I don’t think that any two families have ever played this game by the same rules, and that’s not just because I don’t think that any more than two families have ever played this game, and that is indeed something I do very much think. Two families tops, maybe a broken home as well. I tried to balance original intent and probable typos against tradition and the inherent pursuit of fun in a game. The results are what I’d expect from an Antonin Scalia that cared that we’re trying to have a society here.

Pac-Man – The Video Game of the Board Game of the Video Game was written by me, though it clearly makes use of things I did not make and do not own. The Pac-Man and Ghost graphics were taken from the original Pac-Man game by Namco (1980), while the sound effects came from the 1982 Nintendo version. The music is from the secret Pac-Man level in Wolfenstein 3D by id Software (1992), but I don’t know who made the MIDI version that I used. Hopefully I’ll figure out where it came from so I can update this to give proper credit. I’m under the impression that translating id’s custom music format to MIDI is even harder than it sounds. Most importantly, I credit the inspiration to my recurring disappointment in Milton Bradley’s Pac-Man board game. I morbidly wondered what a video game of it would look like, and now I know.

So please enjoy Pac-Man – The Video Game of the Board Game of the Video Game. I’ve been slowly sowing the seeds of interest across the continent for two years now in anticipation of today’s big pay-off, and I’m feeling pretty good about it. So if you’re one of the many people who I’ve sat next to on an airplane while playing this on my laptop in the hopes that you’d ask me what the deal is, I really wish you’d have asked me what the deal is, and then told your friends upon landing, because both you and your friends would be way more excited about and aware of this release than you probably are now.

The best part about making a video game, as far as I can tell, is that it immediately gives you the audacity to act as an authority on all aspects of game design and construction as if you invented Doom. I intend to cash in on this, so brace yourself for an upcoming audaciously authoritative multi-part series on the making of Pac-Man TVGOTBGOTVG that will span the next twenty eight years. Or less, if we get more rainy Sundays.

PacMan.exe

Earlier I mentioned that one of the first momentous tasks I assigned my Panic Button was to play random songs. To do that I wrote a tiny program called RandomMP3. You give it a directory as a command line parameter and it scans for a random mp3 to launch with your system’s music player. For me that’s Winamp, for you it’s probably something else. There’s no user interface, no options, just fire and Fogerty.

You heard what I said.

The program is pretty simple, it recursively scans the target directory to build a list of all the filenames ending in .mp3 and then picks a random one from the list. The track gets played by calling ShellExecute() so whatever program shows up when you double click an mp3 is who’s going to show up to play this one. Oh, you think I’m foolin’?

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
    // get an argc / argv to play with. if there are no command line parameters, quit.
    int argc;
    WCHAR **argv = CommandLineToArgvW(GetCommandLine(), &argc);
    if (argc == 1) return 0;

    // build a space delimited string from the command line parameters which will be
    //  the directory to search. the only reason for this step is to be forgiving if
    //  an unquoted path with spaces was given, in which case it's just rebuilding
    //  the original. this altruism won't catch everything but will catch most.
    //  if the caller was of good breeding and quoted the path then there's no issue.
    CString directory;
    for (int i = 1; i < argc; i++)
    {
        if (i > 1) directory += _T(" ");
        directory += argv[i];
    }

    // build a list of mp3 files in the directory
    CAtlArray<CString> files;
    BuildMP3FileList(directory, files);
    if (files.GetCount() == 0) return 0;

    // select a random mp3 from the list
    srand(GetTickCount());
    size_t randomNumber = ((size_t)rand()) % files.GetCount();

    // open the selected mp3 with whatever program the system is set to use.
    ShellExecute(NULL, _T("open"), files[randomNumber], NULL, NULL, SW_SHOWNORMAL);
    return 0;
}

Now who’s the fool? Well, probably me since this whole mess is likely a one-liner in a modern scripting language, and that’s including the other half:

void BuildMP3FileList(CString directory, CAtlArray<CString>& files)
{
    // ensure that the directory ends in a separator
    if (directory[directory.GetLength() - 1] != _T('\\'))
    {
        directory += _T("\\");
    }

    // kick off a listing of everything in the directory
    WIN32_FIND_DATA findData;
    HANDLE hFind = FindFirstFile(directory + _T("*"), &findData);
    if (hFind == INVALID_HANDLE_VALUE) return;

    // loop through each file and directory
    do
    {
        // skip the results "." and ".."
        CString file = findData.cFileName;
        if (file == _T(".") || file == _T("..")) continue;

        // make a full path to the file
        file = directory + file;

        // if the file in question is a directory then recurse
        if ((findData.dwFileAttributes | FILE_ATTRIBUTE_DIRECTORY) == findData.dwFileAttributes)
        {
            BuildMP3FileList(file, files);
        }
        else
        {
            // if the file is an mp3, add it to the list
            CString extension = file.Right(4).MakeLower();
            if (extension == _T(".mp3"))
            {
                files.Add(file);
            }
        }
    } while (FindNextFile(hFind, &findData));
    FindClose(hFind);
}

Like I said in the beginning, it’s comic relief for everyone else. But if you are actually still into this clunky compiling thing then you’ve at least got a good example of a small statically linked program (8.5KB) that’s set up to use Minicrt and ATL classes (CString, CAtlArray) harmoniously.

So enjoy the unpredictable outcomes of RandomMP3. I have no fucking idea what it will do. Incidentally, a slightly modified version of this program was responsible for generating all of the text in this article, including this statistically challenging explanation, but I’m sure you figured that out long ago. KILL ALL HUMANS.

Next time I’ll drop a bomb that will launch me into immortality, civil litigation, and time permitting, your heart.

	RandomMP3.exe
	RandomMP3.zip (source code)

Get it? Because Moonlighting also took a long time between new episodes due to blossoming movie careers and sexual tension? Oh, I think you know what I’m talking about.

Extremely previously I made a veiled threat to talk about the Panic Button Control Panel user interface. Today I make good on those careless whispers by taking a tour through what it takes to give the Panic Button UI its look, pausing along the way to refrain from drawing tenuously bleak conclusions about Windows programming which would betray my otherwise upbeat tone.

The Panic Button UI is a single window and that window is a just regular ol’ Windows dialog that’s been gussied up a bit. Below is the naked dialog in the Visual Studio designer alongside the run-time result. Everything in between is code and it’s that code we’ll be looking at. It was a lot of work but what’s the alternative, to skimp on the Gussie? I Fink-Nottle.

Most of the effect above comes from the background, so I’ll begin there. The entire background, including the white space, is just an image. This image is displayed with what the designer calls a Picture control but is really the all-purpose Static control with the SS_BITMAP style. I call it the cactus on the left. This is the simplest way to get a bitmap onto a dialog and normally wouldn’t be worth mentioning but there’s something here that breaks the textbook example: the image is really a GIF! There’s not a lot of programming environments left where using a GIF warrants an exclamation point, but there you go. Here’s the code that sets up the background, it’s called along with the rest of the program initialization upon receiving the WM_INITDIALOG message:

static void SetBackground(HWND hwnd)
{
    HWND hwndBackground = GetDlgItem(hwnd, IDC_BACKGROUND);
    RECT rectClient;
    GetClientRect(hwnd, &rectClient);
    MoveWindow(hwndBackground, 0, 0, rectClient.right, rectClient.bottom, FALSE);

    HBITMAP hBackgroundBitmap = CreateBitmapFromPicture(IDP_BACKGROUND, _T("GIF"));
    SendDlgItemMessage(hwnd, IDC_BACKGROUND, STM_SETIMAGE, IMAGE_BITMAP, (LPARAM)hBackgroundBitmap);
}

First the background control is moved to the upper left corner and expanded to cover the entire dialog. This might seem like it should have been done in the designer, but it’s necessary to set the size at run-time because the image is set at run-time. Oh, and also Visual Studio will slit your throat if you try otherwise. The designer doesn’t allow you to set the size of Picture controls without images, which is inconvenient if you belong to the rare breed of ambitious that sets their sights beyond 22×21 pixeled cacti. So, that’s too bad, but the designer does relent if you set the control’s SS_CENTERIMAGE style, in which case you’re free to resize at will. That sounds okay in this case since centering an image within a control whose dimensions match is a no op, and though I’m not crazy about setting unnecessary properties for their unintuitive side effects, I’ve certainly done worse.

Here’s where that aforementioned throat puncturing comes in. Overlapping dialog controls render the designer unusable. Yikes. Mouse clicks cause the bottommost control to be selected, and since the background control is below every other control it would be impossible to select anything in the designer other than the background… which kinda defeats the purpose of a designer. This bug is the arch nemesis of Avery Lee, the Hero to millions who authored VirtualDub and the original bug report that Microsoft closed as Won’t Fix. As it still exists in Visual Studio 2010, someone has a 10 year birthday coming up…

So instead of dealing with all that I just size and position the background control at run-time with MoveWindow(). That way it doesn’t matter where I plant that stupid cactus as it ends up in the right place. The last detail to take care of is making sure that the background control is indeed the bottommost control on the dialog. The controls’ z-order is determined by the order they appear in the dialog resource, so all it takes is stepping out of the designer and directly editing the resource script file to place the background control first in the list.

Once the background control is in position and sized correctly it’s time to set the image. This is done with the STM_SETIMAGE message which requires a bitmap, but cantankerous old man that I am, I’ve shown up instead with a GIF embedded in the program’s resource section. Unsurprising to anyone unfortunate enough to have endured through Small Programs, I’ve done this for the typical old man reason of reducing program size. The raw bitmap of the background is 184KB versus the 38KB compressed GIF, and seems kinda silly to plunge into the madness of maintaining my own runtime library while letting a single image quadruple the program’s size. But bitmaps are the currency Windows deals in, so something is needed to bridge the gap. If I may be so bold as to direct your attention to CreateBitmapFromPicture():

HBITMAP CreateBitmapFromPicture(UINT resourceID, LPCTSTR type)
{
    // load picture
    IPicture *picture = LoadPicture(resourceID, type);
    if (picture == NULL) return NULL;

    // get bitmap handle
    HBITMAP hPicture = NULL;
    picture->get_Handle((OLE_HANDLE *)&hPicture);

    // copy picture to new bitmap
    HBITMAP hNewBitmap = (HBITMAP)CopyImage(hPicture, IMAGE_BITMAP, 0, 0, LR_COPYRETURNORG);

    // destroy picture
    picture->Release();

    // return new bitmap (must be destroyed by caller)
    return hNewBitmap;
}

No flash photography please. Despite the high comment-to-code ratio this function just raises more questions. I’ve got a GIF, I need a bitmap, now where in the wide wide world of gator can I find myself an LZW decompressorator? According to the pioneer spirit of Windows programming I’d need to find or build a compatible image library and compile it in with my program. On the other hand, according to Oregon Trail most pioneers were just meandering bankers that died of dysentery. Like… all of them. So it’s a little surprising that Windows itself has been providing programs with the ability to read GIFs and JPEGs as far back as Windows 95! These formats can be loaded into the IPicture interface through the very handy OleLoadPicture() and you get a drawable bitmap to go to town with. I suppose that’s surprising because decoding compressed image formats invented elsewhere is a fairly high-level operation for the low-level API landscape. Also, let’s face it, it’s a pretty damn useful feature. Or… OR…… maybe the real reason it’s so surprising is that nowhere in the IPicture or OleLoadPicture() documentation did anyone include the words “GIF” or “JPEG”. Ha! Why would they?

Armed with the understated IPicture it’s easy to see how CreateBitmapFromPicture() gets its bitmap. The GIF gets loaded into an IPicture which provides a bitmap handle to its fancy innards, but since I don’t want lug around an IPicture I just use that handle to copy the image to a regular bitmap which I return after killing off the IPicture. This function and the rest in Picture.cpp are all about simplifying and encapsulating IPicture so that I can easily use compressed images in the Bitmap Belt that is Windows. I find IPicture awkward to draw with directly, and loading an image into it is… well, judge for yourself. That first line of CreateBitmapFromPicture() hides a lot of work. Here’s LoadPicture(), the dude that slurps the GIF out of the resource section and into an IPicture:

IPicture * LoadPicture(UINT resourceID, LPCTSTR type)
{
    // get pointer to resource data
    HINSTANCE hInstance = GetModuleHandle(NULL);
    HRSRC hResource = FindResource(hInstance, MAKEINTRESOURCE(resourceID), type);
    DWORD resourceSize = SizeofResource(hInstance, hResource);
    void *resourceData = LockResource(LoadResource(hInstance, hResource));
    if (resourceSize == 0 || resourceData == NULL) return NULL;

    // copy resource data to memory that has a handle
    HGLOBAL hGlobal = GlobalAlloc(GMEM_MOVEABLE, resourceSize);
    if (hGlobal == NULL) return NULL;
    void *globalBuffer = GlobalLock(hGlobal);
    if (globalBuffer == NULL)
    {
        GlobalFree(hGlobal);
        return NULL;
    }
    CopyMemory(globalBuffer, resourceData, resourceSize);
    GlobalUnlock(hGlobal);

    // create stream from copied resource data, then load picture from stream
    IStream *stream = NULL;
    IPicture *picture = NULL;
    if (CreateStreamOnHGlobal(hGlobal, FALSE, &stream) == S_OK)
    {
        OleLoadPicture(stream, 0, FALSE, IID_IPicture, (void **)&picture);
        stream->Release();
    }

    // cleanup
    GlobalFree(hGlobal);
    return picture;
}

Try not to stare directly at it. There’s really a lot less going on than the number of functions involved would suggest, it’s just that there are a lot of rules regarding how to get between these particular points A and B. The resource we’re loading, in this case a GIF, is already sitting in memory and the goal is to get that memory to OleLoadPicture() so that it can create an IPicture out of it. Seems simple enough but first we have to get a pointer to that GIF memory, which for resources requires the Find/Size/Lock/Load dance that makes up the first code block. Now we have the memory address but it turns out that OleLoadPicture() doesn’t want a raw memory address, it wants memory packaged as an IStream. Fine. IStreams can be created from existing memory by CreateStreamOnHGlobal()… which also doesn’t want a raw memory address. Instead, as the name says, it wants an HGLOBAL handle to a block of memory. Oh, what’s one more layer? So… we allocate a chunk of movable memory with GlobalAlloc() to get our HGLOBAL, copy the GIF from its original address to the movable memory address retrieved by GlobalLock(), use the HGLOBAL to wrap the movable memory in an IStream interface, and finally hand that off to OleLoadPicture(). Like I said, just try not to stare directly at it. Utility functions that hide the paperwork like this are great… until you foolishly return years later to write about them.

Now that the background is taken care of it’s time to get the text looking propah. In picture-talk, me want this:

Seems like a reasonable request. I want to color the status text in the corner and make the background of the labels and the checkbox transparent so that the background image shows through instead of the dialog color. All of this can be done by handling the WM_CTLCOLORSTATIC message:

static HBRUSH OnCtlColorStatic(HWND hwnd, HDC hdc, HWND hwndChild, int type)
{
    // initialize the HDC to the control's defaults
    FORWARD_WM_CTLCOLORSTATIC(hwnd, hdc, hwndChild, DefWindowProc);

    switch (GetDlgCtrlID(hwndChild))
    {
        // if XP theming is on then the transparent trick doesn't work for
        //  checkboxes, they turn out solid black instead. nothing is easy.
        //  since the checkbox happens to be on a solid white background
        //  i can just take the easy way out and set its background to white.
        case IDC_STARTUP:
            SetBkColor(hdc, RGB(255, 255, 255));
            return GetStockBrush(WHITE_BRUSH);

        // set the appropriate text color for the button status
        case IDC_BUTTONSTATUS:
            COLORREF textColor = (_hPanicButton == NULL) ?
                                  RGB(255, 0, 0) :
                                  _isButtonPushed ? RGB(255, 128, 0) : RGB(0, 128, 0);

            SetTextColor(hdc, textColor);
            break;
    }

    // make the static controls have transparent backgrounds by
    //  not painting the text background or the control background.
    SetBkMode(hdc, TRANSPARENT);
    return GetStockBrush(NULL_BRUSH);
}

The WM_CTLCOLORSTATIC message is sent to the dialog when Windows needs to draw one of its static controls or the checkbox, and the dialog’s response determines the colors that get used. This has always been a confusing area for me. First, I have to keep reminding myself that a control’s color isn’t a property of the control, but rather the answer to a question occasionally asked of its owner. It’s not the hardest concept in the world, but it’s unintuitive and whenever I have to remake its acquaintance my face does some contorting as I slowly re-accept the fact. Second, there’s the issue of just how many colors we’re dealing with here. I’m simple folk, so when I want to set the colors of a simple control I only care about two things: the text color and the background color. Being simple folk, as I purnt near is, I don’t even consider a nuance such as the background color of the text on the control vs the background color of the entire control. I went a very long time before connecting those dots, so I’m going to take a quick detour into a sample that might help clear this up:

This is a blue window containing a single static control. The static’s background color is green, its text background color is red, and its text color is yellow. Here’s the WM_CTLCOLORSTATIC handler that produced this:

static HBRUSH greenBrush = CreateSolidBrush(RGB(0, 255, 0));

static HBRUSH OnCtlColorStatic(HWND hwnd, HDC hdc, HWND hwndChild, int type)
{
    SetTextColor(hdc, RGB(255, 255, 0));  // Yellow text
    SetBkColor(hdc, RGB(255, 0, 0));      // Red text background
    return greenBrush;                    // Green control background
}

Now that it’s clear how many colors are involved and how to set them, the Panic Button code starts to make sense. Setting the status text color is as simple as, well, setting its text color, and giving everybody a transparent background just means abstaining from drawing either of the background colors. The TRANSPARENT background mode eliminates the text background color, and the NULL_BRUSH takes care of the control background color. This works great for static controls and used to work for checkboxes and radio buttons… but the Visual Styles introduced in Windows XP broke that behavior, much to my sadness. When Visual Styles are enabled, checkboxes and radio buttons treat responses to WM_CTLCONTROLSTATIC a lot differently. As far as I can tell these exact differences aren’t documented but it doesn’t matter because the short version is that none of them are helpful. In this case, returning the NULL_BRUSH causes this:

Blerg. At this point the right move is to just give up and acknowledge that the checkbox happens to be placed over a patch of solid white and simply set the checkbox’s background to white. As you can see in the above code, that’s exactly what I did. Giving up sucks, but I have no idea how to get a transparent background on a modern checkbox anymore without building my own from the ground up. Oh wait, yes I do, by writing web applications instead. Dammit.

You may have noticed that the whole transparency issue could have been sidestepped by moving the “Run When Pushed:” text a few pixels to the left, giving this entire discussion an undercurrent of lunacy. You’re right! My original design for the dialog depended a lot more on transparency, and it was only after writing the code for it that the final design rolled around and made it unnecessary. Since I’d already taken the time to get transparency working I made sure there was still a tiny amount of overlap to show it off, even if it didn’t really matter. Oh what, like you’re so rational?

Irrationality is the perfect segway into the final piece of Panic Button UI hackery, a maddeningly tiny visual effect that was the hardest part of the whole damn program. So difficult, in fact, that it wasn’t until a year after the program was written that I got it added in. See for yourself:

And yes, segway. As you can see, or at least as I sure hope you can see, the browse button on the left doesn’t look like the rest of the buttons. They’re rocking the new Visual Style theme and it’s going for the old Windows 95 look. It turns out that giving a button an image immediately disqualifies it from being drawn with Visual Styles. Blerg I say, I added that image to make things look better, not worse.

This is about the time when Windows programmers chime in and suggest creating an owner drawn control, which is a polite way of telling you to Get Stuffed. I’ll save going into owner drawn buttons for another day, but if the goal is to make a control’s look and feel exactly match what Windows does elsewhere, then doing everything yourself is the least likely way to get there. The Panic Button program went a year with an ugly button because faced with the option of owner drawn I simply backed down. Also, at that point I was successfully using the Panic Button to rock out to Table Dance every five minutes so my plate was pretty full.

Fortunately, a Hero named Stephen C. Steel (awesome name, he should front a detective agency) solved this exact problem and just as fortuitously, I read about it. Stemmington (that’s his detective name now) pieced together that a compromise existed between living with ugly image buttons and going full pull with owner drawn buttons. If a button only has an image and no text then by cleverly handling NM_CUSTOMDRAW notifications sent through WM_NOTIFY you can have an image button with the fancy style! It’s a great compromise because the image drawing code is minimal and straight forward, you’re not on the hook for the responsibilities that owner drawing incurs, and when Visual Styles aren’t around the button gets drawn by Windows normally so it’s compatible with earlier versions. Man, Stephanie Zimbalist is going to have her hands full with this dude…

The only issue for me was that Steel’s code was caught up in the Microsoft Foundation Classes lifestyle, so I ported it into a set of simple Win32 functions and along the way fixed a minor bug or two. I packaged all of this up in ImageButtonXP.h/cpp and I think the only thing to show is how easy it is to drop in and use. Here’s the code that sets the button’s image and handles the NM_CUSTOMDRAW notifications:

static BOOL OnInitDialog(HWND hwnd, HWND hwndFocus, LPARAM lParam)
{
    ...
    // set browse button's icon
    HICON hBrowseIcon = (HICON)LoadImage(GetModuleHandle(NULL), MAKEINTRESOURCE(IDI_BROWSE),
                                         IMAGE_ICON, 0, 0, LR_SHARED);
    SetButtonIcon(hwnd, IDC_BROWSEBUTTON, hBrowseIcon);
    ...
}

// handles WM_NOTIFYs of NM_CUSTOMDRAW so that my stupid little browse button
//  can have its stupid little image *and* be themed.
// handling WM_NOTIFY from within a dialog is a little goofy. normally this
//  function would return an LRESULT, but since this is a dialog the return
//  value is whether or not the message was handled. if it was, then the
//  LRESULT needs to be set with SetWindowLong(DWL_MSGRESULT).
static BOOL OnNotify(HWND hwnd, int idCtrl, LPNMHDR pnmh)
{
    if (pnmh->code == NM_CUSTOMDRAW && idCtrl == IDC_BROWSEBUTTON)
    {
        HWND hwndButton = GetDlgItem(hwnd, idCtrl);
        LONG result = HandleCustomDrawNotification(hwndButton, (LPNMCUSTOMDRAW)pnmh);
        SetWindowLong(hwnd, DWL_MSGRESULT, result);
        return TRUE; // message was handled
    }

    return FALSE; // message wasn't handled
}

Once you get past the WM_NOTIFY cruft you can see that all we’re doing is handing off NM_CUSTOMDRAW messages to HandleCustomDrawNotification(), where the ImageButtonXP magic happens, and returning the result. Purdy simple, and now when you see a themed image button you’ll know the score. Someone either did a ton of work or they borrowed a ton from someone else. Or they used .NET and moved on with their life.

So now you know what it takes to polish a desktop application to the level that can achieve a confirmed userbase of two. I wrote out “two” because it looks bigger than “2″, and this article is all about appearances.

This is the end of the tour. I hope it didn’t come off as a laundry list of birthing pains, the idea really is to be helpful. And the intent isn’t to complain, it’s to show the amount of effort and code involved in creating a laughably simple dialog box that has some color. I mean that literally, like colors other than gray.

I promised at the start to stay away from drawing conclusions from this walkabout, and I’ll try to stick to that. I will say that when I see a Windows program with dialog boxes that use images, colors, or basically anything that strikes me as interesting, intuitive or unique, I check out the language it’s written in and nine times out of ten Delphi is involved. I don’t know what that means, I’m not dealing with a particularly large sample, but it seems weird that you can so often guess a program’s language by how friendly or boring its interface is. I don’t know anything about Delphi or VCL, but if I had to guess I’d say they must be pretty easy to experiment with. My basic UI took work that couldn’t have been justified on a project with economic constraints. Admittedly, Panic Button is sitting pretty low on the abstraction pole. I was programming directly against the Windows API without third party libraries so things could only have gone up from there, but with the goals of low level device communication and lightweight portability there was really nowhere else to go. (56.5KB, if anyone was counting!)

I guess I do have a wild baseless conclusion, but I’ll keep it meek: Most Windows programs look boring because it takes a lot of code to try to look interesting with the Windows API, which means it takes a ton of code to succeed.

That’s the last we’ll hear about Panic Button. Oh wait, that’s not true, next time we’ll see a program you can run with it, but don’t worry because it will suck and there won’t be any pictures. I suppose if I have to stand trial in Hong Kong for product defamation you’d hear about that, or if I were to receive a windfall when Asia realizes that my program has been driving worldwide button sales since March, but these things could take a while. Until then, hold tight.

	PanicButton.exe
	PanicButton.zip (source code)

The first thing that strikes me when looking at the source code is that a surprising amount of it is dedicated to the seemingly simple user interface. Maybe that’s not so surprising to a jaded Windows programmer, but there’s so much material there that I’m just going to postpone discussing it until next time.

My second reaction is to the code that communicates with the Panic Button: it’s complicated! So complicated that it deserves an entire article defending my actions to the world. Let’s commence opening statements with how the Panic Button actually works.

The Panic Button is a USB keyboard. Yeah, I didn’t see that coming either! It’s just a keyboard! A fairly crappy keyboard, what with the one button and all, but still, it’s just a keyboard! Turns out it’s no big deal to have two keyboards plugged into your computer. Who knew? Pushing the button causes the device to generate the following keyboard sequence:

It’s kinda anticlimactic, but there’s a subtle engineering genius to this. I’ve never seen the real Panic Button software but my guess is that it simply registers the system-wide hotkey SHIFT + ALT + P with Windows to receive notifications when the button is pushed. No need for drivers, no need for USB programming, no need to invent a message protocol, no need to detect device connection and removal, it could just call RegisterHotKey(), wait for WM_HOTKEY messages, and let Windows handle the rest. I imagine the operation that produced the Panic Button to be on the cheaper end of things so avoiding all that complexity, and let’s face it, responsibility, is a wise move on its part. It would probably also simplify the hardware if an existing keyboard component could be used. I’m just guessing though, I haven’t taken mine apart.

When I figured this out I was disappointed. I was hoping to reverse engineer a tiny protocol and do a little USB programming, not call RegisterHotKey() and take a nap. So I looked for shortcomings to this approach, something that would justify a bit more work. All I could come up with was that the hotkey method isn’t enough to determine if the Panic Button was plugged in or not, and that it can’t discern between a legitimate Panic Button press and simply pressing SHIFT + ALT + P on the keyboard. The first issue is important to me because hardware programs should be able to tell you if the hardware they know so bloomin’ much about is even plugged in. Plus, that part is fun to write. The second issue is just a matter of principle. Being able to Panic Button without a Panic Button is lame, and it cheapens something that’s already dangerously cheap as it is. With those minor grievances in mind…

The Panic Button program works by using the Raw Input API introduced in Windows XP to detect when the Panic Button has been pushed. It does this by calling RegisterRawInputDevices() in order to be notified about all keyboard input system-wide. Windows in turn sends a WM_INPUT message for every keyboard event that occurs and the program inspects each message to see if the event is the ‘P’ in the Panic Button key sequence. What makes WM_INPUT king is that it includes a field indicating the device that caused the event, and so the program only acts upon genuine Panic Button presses.

Registering for raw input notifications from all keyboards goes a little something exactly like this:

BOOL RegisterForRawInputFromKeyboards(HWND hwnd)
{
    RAWINPUTDEVICE rid;
    rid.usUsagePage = 0x01;     // Magic values for
    rid.usUsage     = 0x06;     //  HID Keyboards.
    rid.dwFlags     = RIDEV_INPUTSINK;
    rid.hwndTarget  = hwnd;

    return RegisterRawInputDevices(&rid, 1, sizeof(rid));
}

The Raw Input API can be used for any input device, but we only care about keyboards and indicate that through the usage values. The RIDEV_INPUTSINK flag causes the program to receive notifications even when it’s not in the foreground, which is perfect since it’s going to spend most of its life minimized in the system tray. This code and the rest that deals directly with the button lives in PanicButton.cpp, encapsulated in wordy functions with simple interfaces. Case in point, the following is called in response to WM_INPUT:

BOOL IsPanicButtonPushed(HANDLE hPanicButton, HRAWINPUT hRawInput)
{
    // get size of input data
    UINT bufferSize = 0;
    if (GetRawInputData(hRawInput, RID_INPUT, NULL, &bufferSize, sizeof(RAWINPUTHEADER)) != 0)
        return FALSE;

    // allocate buffer for input data
    PRAWINPUT rawInput = (PRAWINPUT)malloc(bufferSize);

    // get input data and see if it's a panic button push
    BOOL isPushed = FALSE;
    if (GetRawInputData(hRawInput, RID_INPUT, rawInput, &bufferSize, sizeof(RAWINPUTHEADER)) == bufferSize)
    {
        // is this keyboard input from the panic button?
        if (rawInput->header.hDevice == hPanicButton && rawInput->header.dwType == RIM_TYPEKEYBOARD)
        {
            // is this a WM_SYSKEYUP of the P key?
            //  that's the message from the panic button
            //  that's only sent once per push.
            UINT message = rawInput->data.keyboard.Message;
            USHORT vkey = rawInput->data.keyboard.VKey;
            isPushed = (message == WM_SYSKEYUP && vkey == 'P');
        }
    }

    free(rawInput);
    return isPushed;
}

There’s a lot of API noise in there but the goal of IsPanicButtonPushed() is simple; it answers the question “Was this WM_INPUT caused by the Panic Button releasing the P key?” Most of the noise is due to a fundamental difference between WM_INPUT and traditional window messages. Rather than directly include an address to the message’s data structure with the message, WM_INPUT instead provides a numeric handle which the message recipient can use to retrieve the RAWINPUTHEADER structure through GetRawInputData(). This means that allocating memory for the structure and determining the necessary size is the responsibility of the recipient, and it’s that paperwork that balloons this otherwise simple test of the structure’s contents. The first part of said test is to compare the source device handle to the Panic Button’s device handle to see if they match, which would be straightforward except that I haven’t shown where that handle comes from yet. So instead let’s look at the second part, the WM_SYSKEYUP / P test. The comment claims that this is a good event to test for because it only occurs once per Panic Button push. That may be true, but this was written in 2008 and frankly I claimed a lot of things in 2008 so we better investigate further.

Here’s the full list of window messages generated by a Panic Button press:

First some mild deciphering: VK_MENU is Windows-speak for the ALT key, and the WM_SYS* versions of keyboard messages are only sent when the ALT key is down. Once that’s understood it all makes symmetric sense: a rapid build-up of conditions causing the character message followed by an immediate and equal tear-down. I begrudgingly admit that the WM_SYSKEYUP / P combination is only sent once per button press, but that looks to be the case for each message. They’re all unique! There’s nothing at all special about WM_SYSKEYUP / P; testing for any step in the sequence would work just as well. I seem to recall choosing WM_SYSKEYUP / P out of paranoia just in case some kind of defect or interfering auto-repeat rate caused multiple keydown and character messages to be sent, whereas a keyup message could only be sent once by definition. (Exercise for home: hold down a key and try to release it twice.) Unlikely, I know, maybe even impossible, but everything else being equal that’s the pony I bet on. If you’d like to learn more about Windows keyboard messages you can visit here, but Google and I recommend here.

That covers detecting button presses, which leaves detecting button presence. The Raw Input API has us covered there too:

HANDLE GetPanicButtonInputHandle()
{
    // get device count
    UINT deviceCount = 0;
    if (GetRawInputDeviceList(NULL, &deviceCount, sizeof(RAWINPUTDEVICELIST)) == -1)
        return NULL;

    // allocate buffer for device list
    UINT bufferSize = sizeof(RAWINPUTDEVICELIST) * deviceCount;
    PRAWINPUTDEVICELIST buffer = (PRAWINPUTDEVICELIST)malloc(bufferSize);

    // get device list
    HANDLE hPanicButton = NULL;
    if (GetRawInputDeviceList(buffer, &deviceCount, sizeof(RAWINPUTDEVICELIST)) != -1)
    {
        // loop through devices
        for (UINT i=0; i < deviceCount; i++)
        {
            // get device name and check against panic button name using a substring comparison
            TCHAR deviceName[256];
            bufferSize = sizeof(deviceName);
            if (GetRawInputDeviceInfo(buffer[i].hDevice, RIDI_DEVICENAME, deviceName, &bufferSize) != -1)
            {
                TCHAR panicButtonMagicString[] = _T("vid_04f3&pid_04a0");
                CharLowerBuff(deviceName, lstrlen(deviceName));
                if (_tcsstr(deviceName, panicButtonMagicString) != NULL)
                {
                    hPanicButton = buffer[i].hDevice;
                    break;
                }
            }
        }
    }

    free(buffer);
    return hPanicButton;
}

GetPanicButtonInputHandle() simply walks the list of connected input devices looking for a device whose name contains the Panic Button’s unique signature. This signature, “vid_04f3&pid_04a0″, is made up of the Panic Button’s USB Vendor ID and Product ID, 04F3 and 04A0 respectively. USB requires these values to be unique to a device, and so this otherwise shady substring comparison can be forgiven. GetPanicButtonInputHandle() not only tells us if the button is connected (no handle means no button), but its result can be used to identify the source of WM_INPUT messages. This explains the hPanicButton parameter we saw in IsPanicButtonPushed() earlier. The program calls GetPanicButtonInputHandle() upon loading and stores the result for future input testing via IsPanicButtonPushed(). Actually, if the stored handle is NULL then the program doesn’t even bother calling IsPanicButtonPushed() since it already knows that there’s no button attached, but you get the idea. Or not. At this point I’m way too invested in this explanation to start over with a clearer one so here’s hoping.

The last piece to Panic Button communication is keeping track of device connections and disconnections as they happen. That’s not only necessary for displaying the button’s status, but also for keeping the stored Panic Button handle up to date. So… I apologize, but here’s where it starts getting weird. If you peruse the Raw Input API reference you’ll come across WM_INPUT_DEVICE_CHANGE, a message which you can arrange to have sent every time an input device is attached or removed from the system. That sounds perfect, but if you check the fine-print you’ll see that this message wasn’t added to Windows until Vista, disqualifying its use if the Panic Button program is to work on Windows XP, which as an XP user I’d prefer that it does.

With WM_INPUT_DEVICE_CHANGE off the table the next candidate is the original WM_DEVICECHANGE message which has been around forever. Well, “forever” if you consider the mid-nineties to be the beginning of time, which with attention spans these days you just might. WM_DEVICECHANGE and WM_INPUT_DEVICE_CHANGE share the same model, you register for notifications and you receive them whenever a device gets attached or removed. As the name suggests, WM_DEVICECHANGE is more general and is used for all devices, not just inputs. The other difference is that registering for notifications is a bit more complicated:

HDEVNOTIFY RegisterForHumanInterfaceDeviceNotifications(HWND hwnd)
{
    // this is the last hid.dll dependancy in the app.
    //  to remove the dependency on the Windows DDK, remove
    //  the call to HidD_GetHidGuid() and use the flag
    //  DEVICE_NOTIFY_ALL_INTERFACE_CLASSES which will cause
    //  notificationFilter.dbcc_classguid to be ignored.
    //  the only consequence will be that more WM_DEVICECHANGE
    //  messages will be sent by Windows.
    GUID hid;
    HidD_GetHidGuid(&hid);

    DEV_BROADCAST_DEVICEINTERFACE notificationFilter;
    ZeroMemory(&notificationFilter, sizeof(notificationFilter));
    notificationFilter.dbcc_size = sizeof(notificationFilter);
    notificationFilter.dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE;
    notificationFilter.dbcc_classguid = hid;

    return RegisterDeviceNotification(
        hwnd,                         // events recipient
        &notificationFilter,          // type of device
        DEVICE_NOTIFY_WINDOW_HANDLE   // type of recipient handle
        );
}

Way to spoil the punchline, well-commented code! Registering for device notifications about keyboards isn’t complicated because of the code, it’s complicated because of the dependency incurred by calling HidD_GetHidGuid(). HidD_GetHidGuid() isn’t defined in the Platform SDK headers and libraries, it’s instead found in the Driver Development Kit. Normally that would mean that to compile this silly program you’d have to download a 600MB CD-ROM image, install 1.4GB of components, and then void your citizenship and be labeled an enemy combatant by configuring Visual Studio to compile against the DDK. Yeah… I’m not liking the sound of that either, especially since as the comment says, HidD_GetHidGuid() is the only thing keeping the DDK in the picture and it’s optional! HidD_GetHidGuid() gives us the Globally Unique Identifier for Human Interface Devices, and we use that identifier to tell RegisterDeviceNotification() that we’re only interested in that type of device, but we could also simply skip the filter by asking for notifications for all devices. That would eliminate the need for HidD_GetHidGuid(), but it would also make the Panic Button program a pretty bad Windows citizen.

The way a program detects if its device is connected is by waiting for a WM_DEVICECHANGE message from Windows and then scanning the list of connected devices to see if its guy is there. Now, the message doesn’t specifically say “Your device is connected!”, it just says “Something happened somewhere to someone!” and you’re on your own to investigate. Imagine that you’ve got multiple programs running in the background, each dealing with a different piece of hardware. (If you’re on a laptop you don’t have to imagine at all, I’ll just tell you: you have eighteen.) Now imagine that you plug in a mouse. Every one of those programs could potentially be sent a WM_DEVICECHANGE message and they’re all going to immediately do the same thing: scan Windows to see if their device is connected or disconnected… at the same time. It’s in everyone’s best interest to keep that burst of processing to a minimum, and if you experience a sudden halt when you plug in or unplug your USB gizmos then you recognize the truths I be spittin’. With that in mind, I’d like to help curb the tragedy of the commons and ensure that the Panic Button program receives a minimum number of WM_DEVICECHANGE messages so it looks like HidD_GetHidGuid() is here to stay.

Wait, let’s take a step back for a moment. Something bothers me about a function named “HidD_GetHidGuid”, and not just its unpronounceability. Get me the Globally Unique Identifier?

Here, I’ll save us both some time: it’s {4D1E55B2-F16F-11CF-88CB-001111000030}!

Now the DDK dependency is starting to look a little ridiculous; is all this complexity really because we’re intent on calling a function in the same vein as GetTheNumberFive()? Hard-coding the GUID into the Panic Button program eliminates the HidD_GetHidGuid() call and the DDK dependency and it absolutely works… but man it feels sleazy. I really just wanted to explore my options. This is a terrible solution, even though it would work… for now. There must be a reason that the HID GUID wasn’t defined as a constant and that this layer of indirection exists. The only reason could be that on some systems, either now or in the future, the HID GUID is different. Fair enough, but that kinda defeats the point of using a Globally Unique Identifier in the first place. So no, we won’t be hard-coding the result. It’s the high road for us.

Well, maybe not that high. What I ended up doing was ripping the few relavant files out of the DDK and packaging them with my program’s source code. That’s what’s up with the “DDK” subdirectory. This way I can share the code in a self-contained way that doesn’t force others to jump through unnecessary hoops in order to compile. These files are from the old Windows 2003 DDK (3790.1830) which is what I originally developed the program against. This was the last version to be called DDK, afterwards software schizophrenia set in and it was rebranded as the Windows Driver Kit. The Panic Button program compiles just fine against the latest WDK but its header files are less portable so I included the older ones. If it were any harder than this I would have just cheated and used GetProcAddress() to avoid linking to the DDK at all. This is just a guess, but I wouldn’t be surprised if this exact headache was one of the motivations behind the creation of WM_INPUT_DEVICE_CHANGE.

It was a lot of work, but by using the Raw Input API and flirting with the DDK the Panic Button program was able to avoid using hotkeys. Except that it wasn’t:

static BOOL OnInitDialog(HWND hwnd, HWND hwndFocus, LPARAM lParam)
{
    ...

    // Register the Panic Button sequence of Shift + Alt + P.
    //  The only reason I do this is to prevent the P from reaching
    //  the active window. The app doesn't use WM_HOTKEY to be notified
    //  of a Panic Button push, it uses WM_INPUT from the Raw Input API.
    RegisterHotKey(hwnd, HotKeyID, MOD_SHIFT | MOD_ALT, 'P');

    ...
}

Oh, Come On! After all that it was still necessary to register the hotkey! The Raw Input API is great for notifying about keyboard events but it doesn’t let you filter them out. The SHIFT + ALT + P key sequence still gets sent to the active window, which depending on the window could mean menus popping up, buttons being pushed, who knows? Hotkeys, on the other hand, are filtered by Windows and don’t reach their normal targets. That’s the behavior I was looking for, and so the program registers the hotkey solely for that purpose.

Sweet sassy molassy, are we ever in need of a recap. The Panic Button program works by…

• Registering for WM_DEVICECHANGE messages for Human Interface Devices.
• Registering for WM_INPUT messages for HID keyboards.
• Registering the SHIFT + ALT + P hotkey to prevent it from reaching applications.
• Scanning connected input devices for the Panic Button and storing the resulting handle.
• Re-scanning when receiving WM_DEVICECHANGE and updating the stored handle.
• Testing each WM_INPUT to see if it’s a WM_SYSKEYUP / P whose source matches the stored handle.

Curse you bullet points, always belittling my work. The end result is that the program displays whether or not the button is connected, only responds to legitimate button presses, and prevents menus that start with ‘P’ from awkwardly springing up. What can I say, buttons that play Table Dance don’t program themselves.

That’s it for today’s episode of Clarissa Explains It All. Next time Sam and I will talk about Pearl Jam, parents, and stupid user interface tricks. Until then, enjoy the source code to the Panic Button program. The project/solution files are for Visual Studio 2005 but they’ll also load just fine in 2008. And… is that Minicrt in there too?

Na Na na-na-na….

	PanicButton.exe
	PanicButton.zip (source code)

Years passed. Then in 2008 I finally tossed “usb button” at Google Images. And lo, for I found the Panic Button.

Let’s tally: it’s a big button, it plugs into a computer’s USB port, and it’s programmable… in that it can play one of three homely screen savers. Close enough! So I bought a couple for $17 each, threw away the software unopened, and wrote PanicButton.exe. I could explain the program further but as the old saying goes, “Why go ahead and say what you could say in literally hundreds of individual utterances when in fact time has shown that a single image, carefully chosen within the confines of the correct context, might very well end up equivalent to eloquence due to the potential efficiency with which an idea (and/or ideas) can be communicated visually versus the various verbosities inherent in any language languishing in the larynx.”

Zounds, that is an effective screenshot! And yet I chose to continue. The Panic Button Control Panel accepts a single command which it runs when the button is pushed. It lives in the system tray and can be set to automatically start with Windows. The command can be a file to open or another program to run. The Control Panel is a standalone program; there’s nothing to install and no drivers are required for the button. The system requirements are:

• Windows XP or newer
• A Panic Button (or, alternatively, an unfathomably tragic and thorough imagination)

Full disclosure time: The Panic Buttons sent to me from Honk Kong say STRESS and not PANIC, but since the device identifies itself to computers as “Panic Button”, that’s what I’m going with. Either way it’s cheesy, but my project to sand off the white paint never took flight.

Full disclosure overtime: Behold the flailing desperation of synergy as it’s also a Hulk Smash Button, an Ironman Power Up Button, and a Spiderman Sense Button. I can’t speak to whether or not my program works with these variants, but it probably does. Frankly though, I’d prefer that it doesn’t.

I’ll excuse the painfully banal “USB toy” crowd that Panic Button runs with because this is a good product. True to its image, it is a big honkin’ button that was meant to be slammed by a clenched fist. It’s spring loaded, and has like the most satisfying force constant you can imagine. It even makes a little click when fully depressed, like a little tip o’ the hat. And it only fires once per push, so when you find that you’ve pounded it way WAY too hard for professional surroundings you can just leave your fist there, eyes closed, as you exhale deeply until all the steam lifts and those around you eventually allow their fear to subside.

Actually, there are far better things to use a big red button for than dousing in rageahol. Music is a good candidate. Dave Hamp had his button play the Benny Hill Theme. Shouldn’t everything you press play that? For a while I had mine play a random mp3. There’s something about leaning over every three minutes to manually advance a playlist you have no control over… it’s like listening to the radio but harder. Nowadays, the two buttons have settled into more permanent and prominent roles. One is an integral component to the digital infrastructure of the Alaska Department of Commerce in Juneau. The other is installed at an Anchorage firm’s front desk and plays Table Dance. If there’s a story in the Bible about two brothers doing the same thing but then later doing different things, that would make for a good analogy.

And so I present the Panic Button Control Panel. If you happen to have a Panic Button then I dare say you’ll love it. The only subtlety I can think of is that you can drag and drop a file onto it to automatically fill in the Command field. Also, the program knows when a Panic Button is connected and displays its status in the lower left. That status will also let you know when it detects a button push. If all of this is swaying you towards a purchase, it looks like the button is only $10 at welovepolice.com. Hmmm… you’d better click that link, I can’t tell if I’m joking either.

Next time we’ll begin looking at the program’s internals and I’ll make its source code available. Until that day.

PanicButton.exe

Hero The First is Matt Pietrick, author of Libctiny. Matt wrote about large executable size back in 1996 and again in 2001 in which he fingered Visual Studio’s CRT as the cause and offered up Libctiny as the solution. As a drop-in CRT replacement to effortlessly reduce program size, the library worked great and even included source code. One of its premises was that a number of standard C functions could be implemented as thin wrappers over existing Windows API calls, keeping the real work out of the executable by offloading it onto the operating system. For example, printf(), traditionally a meaty CRT function, is implemented in Libctiny simply by calling wsvprintf() to build the output string and WriteFile() to spit that to the standard output stream, and all in about fifteen lines of code! Hero.

Unfortunately, the years weren’t kind to Libctiny users. Written in Visual C++ 6.0′s heyday, Libctiny became increasingly incompatible with each subsequent version of Visual Studio. Trivial Hello World apps would still compile, but as soon as a program did anything interesting it would run afoul linker errors resulting from incompatibilities with the default libraries. Those could be turned off with the /NODEFAULTLIB linker switch, but that would leave no standard C functions except the poultry few in Libctiny. Even tiny programs need to do something. Sadness ensued. (And yes, poultry.)

Enter Hero The Secondest: Google. Dot com. Look ‘em up. Those magnificent bastards went and wrote a software installer named Omaha for Chrome and Google Earth, open sourced the client, and then in order to shave 40kb off of their installer stub not only used Libctiny but dragged it kicking and screaming into the modern world, re-branding it as Minicrt. Minicrt is chock full of standard C functions (making /NODEFAULTLIB less painful), compatible with Visual Studio 2005 and 2008 (as that’s what Google uses to build Omaha), and used in a nontrivial program that shows how Minicrt can co-exist with high level ATL classes like CString and CSimpleArray. I don’t know the Google programmer responsible for this but I do know his name: Hero.

Thriceroy Of Heroes: Lee Packham. From his UK domain name I’m assuming that he’s British. (Look, this is Alaska yo, deal with it.) Lee packaged Minicrt for Visual Studio 2008 to make it compilable by mortals. Google doesn’t have Visual Studio project files for Omaha, only build scripts written in Python. Typical. Lee created Visual Studio 2008 project/solution files and also silenced some errors by adding a couple casts and #pragmas to the Minicrt code. Most importantly, as far this text is concerned, it was through his blog post that I learned about Omaha’s rebirthening of Libctiny, setting off the chain of events that led to making small programs again, writing this article, and bestowing upon Lee the oft-coveted title: Hero.co.uk.

Now I’m hesitant to call myself a Hero, but if you were to throw a heavily catered banquet in my honor with sufficient austerity and appropriate attendance then I would be honored to appear. It’s called Class. Look ‘er up. I’ve taken Lee’s Minicrt, made a few light touch-ups for myself, and am making it available here. These are the changes I’ve made:

• Added more of the standard C functions. Each was added on an as-needed basis and as a new source file.
• Added back printf(), which was in the original Libctiny but removed from Google’s Minicrt.
• Added Visual Studio 2005 project/solution files, equivalent to the 2008 ones (which are also included).
• Set Release Mode to compile the library without debug information and to optimize for size. This makes for a smaller minicrt.lib file.
• Removed unused source files, including the redundant string.cc which Google’s build script doesn’t even include.
• Renamed Minicrt to Libctiny II: Electric Boogaloo, then immediately backpedaled on the decision in an act of equally epic wisdom and cowardice.

So there’s the odyssey. Matt Pietrick’s Libctiny lives on nearly fifteen years later as Minicrt, which you can compile and use with Visual Studio 2005 and 2008 to drop a simple windowed program to 2.0kb with no dependencies outside of the operating system. Of course, we’re talking computers here, so it’s not always that simple. As advanced C++ language features and libraries get used, friction occurs in the form of frightening linker errors when you don’t have the real CRT in the mix. Several of these are easily remedied by flipping the right switches while other problems require more… extreme measures. I’ll go through each of the errors I’ve encountered and what can be done about them through compiler settings and code. The astute will recall that previously I swore a sacred oath to God to not mention any more compiler settings. Whoops!

Unresolved external symbol const type_info::’vftable’ …

C++ exceptions and/or RTTI are the cause of this. Both language features are out of Minicrt’s league and both can be disabled. This really should go without saying, but if your program depends on either of these then that kinda disqualifies it from the Minicrt fun.

Configuration Properties \ C/C++ \ Code Generation \ Enable C++ Exceptions
	Yes (/EHsc) => No

Configuration Properties \ C/C++ \ Language \ Enable Run-Time Type Info
	Yes => No (/GR-)

Unresolved external symbol __security_cookie

This error and variants on it are a result of the compiler’s buffer security check, which is expecting to find the corresponding Visual Studio 2005 CRT code. Turn it off.

Configuration Properties \ C/C++ \ Code Generation \ Buffer Security Check
	Yes => No (/GS-)

Unresolved external symbol __load_config_used

This is related to structured exception handling, though it is usually prevented simply by turning off C++ exceptions as described above. If that doesn’t do it, disabling the safe exception handler table will.

Configuration Properties \ Linker \ Command Line \ Additional Options
	/SAFESEH:NO

Unresolved external symbol ___CxxFrameHandler3

Who even uses exception handling in C++? Once again, turn off C++ exceptions as described above.

Unresolved external symbol __ftol2_sse

Hoo boy. When a floating point number is converted to a long, or really any integer type, Visual Studio 2005 builds applications that call the CRT helper function _ftol2_sse to do the work. In the previous version of Visual Studio this function was named _ftol2, which is a problem for Minicrt because it’s built with ftol2.obj from the 2003 CRT and only contains the function _ftol2. From the names involved in this conflict you’d think that you’d just need to disable SSE in the project setting to persuade Visual Studio to use the older function, but that’s not the case. _ftol2_sse isn’t just an alternate version; it wraps both by first checking for SSE availability and then only calling _ftol2 if SSE is not there. That means that either way, Visual Studio 2005 links programs against _ftol2_sse. It’s position on this is intractable and adamantine. That leaves us with only one move to make, but it’s drastic: using a depreciated compiler switch to decline calling any ftol conversion functions!

Configuration Properties \ C/C++ \ Command Line \ Additional Options
	/QIfist

This should get you compiling, but there are consequences to this switch. The first is cosmetic and annoying: Visual Studio will always generate a warning about using a depreciated compiler switch, a warning that can’t be disabled. The second is serious. ftol is responsible for setting the Floating Point Unit control flag to the correct state before and after each conversion, and it’s the FPU control flag that determines how rounding should occur. The ANSI C behavior is to round towards zero (truncate mode) when converting, but now that ftol has gone awol (see what I did there?), who knows what mode the FPU is in? Mine defaults to rounding towards nearest, so this switch potentially changes the result of every floating point conversion or calculation application-wide. That’s terrible. Now there’s a way out of this… but it involves assembly. Yeah, I know, I wanted this to be an easy one too. But it’s the other way.

// set rounding mode to truncate
//  from http://www.musicdsp.org/showone.php?id=246
static short control_word;
static short control_word2;

inline void SetFloatingPointRoundingToTruncate()
{
    __asm
    {
        fstcw   control_word                // store fpu control word
        mov     dx, word ptr [control_word]
        or      dx, 0x0C00                  // rounding: truncate
        mov     control_word2, dx
        fldcw   control_word2               // load modfied control word
    }
}

Calling this at the start of your program will set the rounding mode to truncate and keep it there for the duration (unless you manually change it again), which makes float conversions behave the way they would have before /QIfst. Any other floating point routines that require a different mode are going to require that manual change or their results will be off. As you can see, heavy use of floating point math can also be a Minicrt disqualifier. On the other hand, if you can test your results and they come out okay then there’s really no problem. In fact, this method of disabling ftol and manually initializing the rounding mode is an established optimization used by speed freaks because conversions go faster without the overhead of setting and re-setting the control state each time.

Unresolved external symbol __purecall

This shows up when you start using virtual functions. _purecall is a placeholder function that lives in the CRT so that a class with a pure virtual function can have its vtable entry pointed to something instead of nothing, which would be illegal. It’s a function that doesn’t do anything, and it’s an error for it to ever be called, so all you need to do is create your own do-nothing _purecall. The only difference between this and the CRT’s version (defined in purevirt.c) is that the real one throws an error and aborts the program.

extern "C" int __cdecl _purecall(void) { return 0; }

Unresolved external symbol class ATL::CAtlBaseModule… and everything else ATL related.

The Active Template Library works great with Minicrt, it just takes a few macro definitions to disable ATL’s dependencies on newer CRT functions… and a few more to silence all the depreciation warnings. Finally, the linker needs to be reminded about the ATL libary file since /NODEFAULTLIB excludes it from being automatically included in the list. I’ve taken all of these settings from Omaha’s build script, and it’s thanks to them that I’ve been able to use CString and collections like CAtlArray and CAtlMap.

Configuration Properties \ C/C++ \ Preprocessor \ Preprocessor Definitions
	_ATL_MIN_CRT
	_ATL_SECURE_NO_DEPRECATE
	_CRT_SECURE_NO_WARNINGS
	_SECURE_SCL=0
	_SECURE_ATL=0

Configuration Properties \ Linker \ Input \ Additional Dependencies
	atls.lib

Unresolved external symbol [ insert CRT function here ]

Eventually you’ll want to use a CRT function that simply isn’t in Minicrt. Yet. The beauty of being able to build Minicrt yourself with Visual Studio is that it’s easy to add functions to it. When I said that I added functions on an “as-needed basis”, that’s what I meant. It wasn’t for fun, each one was done because I had a program that depended on it. Thankfully, you only need to add a function once. It’s not as daunting as it sounds. Most of the time you can just find an existing implementation and paste it in with little or no modifications. The first place to look is the source for Visual Studio’s CRT, which comes with Visual Studio (located in %VSINSTALLDIR%\vc\crt\src). That’s where I got the code for strrchr().

//==========================================
// minicrt - Chris Benshoof 2009
// strrchr from MSVCRT
//==========================================
#include "libctiny.h"
#include <stdlib.h>

extern "C" char * __cdecl strrchr (const char * string, int ch)
{
    char *start = (char *)string;

    while (*string++)                       /* find end of string */
        ;
    /* search towards front */
    while (--string != start && *string != (char)ch)
        ;

    if (*string == (char)ch)                /* char found ? */
        return( (char *)string );

    return(NULL);
}

In the case of string functions, the next place to look is Minicrt’s very own string.c. There are a number of string functions in there that aren’t exported but are used by ones that are. When needed, I’ve copied these functions into new source files made them exportable, that way I don’t make any changes to string.c and it’s clear what my rookie additions are. By not touching the original files it’s easy for me to periodically diff my evolving Minicrt with the one in Google’s Omaha repository so that I can easily merge in their updates. I pulled tolower() from string.c into tolower.cc.

//==========================================
// minicrt - Chris Benshoof 2009
// tolower from string.c (__ascii_tolower)
//==========================================
#include "libctiny.h"

extern "C" int __cdecl tolower(int c)
{
    if (c >= 'A' && c <= 'Z') return (c + ('a' - 'A'));
    return c;
}

The final place to look, of course, is ye olde abandoned Internet. A lot of people have had to implement the C Run Time library over the years, so there’s a lot of implementations laying around. That’s how I avoided writing my own atoi().

//==========================================
// minicrt - Chris Benshoof 2009
// atoi(), modified from 
// http://research.microsoft.com/en-us/um/redmond/projects/invisible/src/crt/atoi.c.htm
//==========================================
#include "libctiny.h"

extern "C" int __cdecl atoi(const char *String)
{
    int Value = 0, Digit;
    int c;

    while ((c = *String++) != '\0') {

        if (c >= '0' && c <= '9')
            Digit = (c - '0');
        else
            break;

        Value = (Value * 10) + Digit;
    }

    return Value;
}

If all else fails, you can always write the function yer own damn self. I cobbled together sprintf() from Minicrt’s printf() code. It’s kinda fun (perversely) to be in charge of your own little run time as long as you know the limitations. For example, the printf() implementation uses a 1024 byte buffer from the stack to build the output string, as that’s the largest buffer wvsprintf() will accept. If you call printf() to build a string longer than that… uh-oh. Just something to keep in mind.

Thus concludes my panoptica on Minicrt and making small programs. From here on out I can go into pornographic detail about actual programs instead of coming off as an obsessive compulsive over trivial technical attributes… though I have a feeling I’ll be doing both. In my defense, many of the programs I’ll be examining make use of Minicrt so this topic seems a necessary prerequisite. On the other hand, all you have to do is look at the lengths of the two articles to see that there really is no defense.

Well, what’s done is done. Enjoy the source code to Minicrt. As I update my copy I’ll update the copy here too. If that happens enough, I may even concoct something fancy like a text file of release notes. In any case, I’ll keep this article updated if I survive any more linker issues.

Next time, I’ll prove that I’ve actually written a program before. Though wouldn’t it be great if I hadn’t?

	minicrt.lib (library)
	minicrt.zip (source code)

Let’s start with our friend from last time, HideAutoUpdate, and see what it takes to coerce Visual Studio 2005 into spitting out a 1.5kb exe. HideAutoUpdate makes for a good initial test case as it’s barely more than a Hello World app, yet does something allegedly useful. As a refresher, here’s its source code:

// HideAutoUpdate by Chris Benshoof
//  the best flipping thing i'll ever write
#include <windows.h>
#include <tchar.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
    HWND dialog = FindWindow(WC_DIALOG, _T("Automatic Updates"));
    if (IsWindowVisible(dialog))
    {
        ShowWindow(dialog, SW_HIDE);
    }
    return 0;
}

That’ll do, Pig. We’re going to take this code and walk through each step to reduce the file size without sacrificing functionality or compatibility. In fact, just between you and me, we’re going to accidentally increase the latter.

First we need a baseline. Create a new Visual C++ Win32 Project in Visual Studio, make sure to check “Empty Project” on the Application Wizard, then add a new C++ file and paste in the above code. Flip the solution configuration from Debug to Release. Now before we build, let’s make this slightly less painful to follow along with at home. We can get Visual Studio to tell us the compiled file size in its output window which saves us having to go look for ourselves after each build, as that gets real old real quick. This can be done by having Visual Studio run “dir” on the program after every build. Such a feat can be accomplished with the project setting:

Configuration Properties \ Build Events \ Post-Build Event \ Command Line
	cmd /c dir "$(TargetPath)"

Okay, now we can build and see that file size….

Release mode baseline: 6,565 bytes!

Oh snap, that’s crazy small! 6.5kb, that works for me, especially since I didn’t have to do anything! Ship it! But as the scroll bar to the right sadly foreshadows, there’s more to the story. Believe it or not but that little HideAutoUpdate.exe we just compiled, that one that only calls three flipping functions, all of which have existed since 16 bit Windows aka The Time Before Christ… won’t run on a single default installation of Windows XP, 2003, or anything earlier! Gadzooks!

We’ve incurred a dependency: Visual C++ projects default to link against Microsoft’s Visual C++ RunTime dlls. Now wait, that’s supposed to be a good thing! The C++ RunTime (CRT) contains the code for standard functions like printf(), operators like new and delete, and the behind-the-scenes work for building up and tearing down an environment for a C++ program to run in. It’s efficient and sensible to have that shared code in a single set of dlls instead of baked into each and every exe, and it’s even in the spirit of reducing a program’s size which is what this article is about.

The problem is that Windows doesn’t come with the CRT dlls that HideAutoUpdate needs. Back in the day, Visual Studio 6.0 linked programs against msvcrt.dll which came with practically every copy of Windows, even though that wasn’t guaranteed, so a lot of programs got away without noticing this dependency let alone caring about it. That’s not the case anymore. Each version of Visual Studio now has its own versions of CRT dlls. If built with Visual Studio 2005 then HideAutoUpdate requires msvcr80.dll which can only be installed through a 2.6mb Microsoft installer whose version must match at least what you had installed when you compiled. Requiring an installer over four hundred times the size of our little program is unattractive enough, but factor in the drama from Visual Studio service packs and automatic Windows updates rendering future builds incompatible with previous CRT dlls and… nah I don’t think so I gotta boyfriend.

It seems I’ve strayed off track a bit since the topic is program size. To be fair though, dense stanzas of negativity are always on topic in Windows programming. Wait… come to think of it, I’m completely on track here, because when I talk about reducing program size what I’m really talking about is reducing dependencies. No… well, yes. Yes, I’m talking about reducing dependencies, but No, what I’m really really talking about is understanding dependencies, and that might just prove to be the most important thing ever. Yikes, a bold statement!

Now the wind is picking up. Let’s cut to the chase. We drop our lame program’s insignificant file size to 1.5kb by replacing Visual Studio’s CRT with our own tiny custom one and tweaking a few linker settings. It’s crazy hard and I’ll elaborate on the how later. The file size is small, hooray, but there’s something more interesting going on here: HideAutoUpdate doesn’t depend on the Visual Studio CRT anymore. Now obviously that means the dll mess from above no longer applies but that can be accomplished simply by statically linking to the CRT, which causes the necessary portions of CRT code to be implanted directly into HideAutoUpdate at the cost of a much larger file size, but HideAutoUpdate avoids that too. And here’s where independence gets its good rep: not depending on something means not depending on its dependencies. So what does the Visual Studio 2005 CRT depend on? A number of things, but of interest is the Windows API function IsDebuggerPresent(). This function simply returns TRUE or FALSE depending on if a debugger is attached to the program. I don’t know why a call to it is in the Visual Studio 2005 CRT code, the why is irrelevant. It’s in there, that’s all that matters, and the function lives in kernel32.dll… starting with Windows 98. It doesn’t get much more subtle than that. Out of the box, Visual Studio 2005 cannot produce a standalone C++ application that will run on Windows 95, because all C++ applications statically linked to the CRT depend on IsDebuggerPresent() which depends on Windows 98 or later. Windows 95 is unable to resolve that one link and will refuse to run such programs regardless of what they really do. HideAutoUpdate doesn’t have this dependency and happily runs on Windows 95, which for all I know doesn’t even have automatic update dialogs to hide.

It’s pretty easy to imagine some responses to that. “Who the fuck cares about Windows 95?” is probably the chart topper. The answer is: “people who care”, also known as “the right people”. It’s not about getting this program to run under Windows 95, it’s about understanding why it won’t, which means understanding its dependencies and their ramifications.

• “Why does a program that only calls three functions require a 2.6mb installer?”
• “Doesn’t it seem like a program that only calls three functions should be less than 48kb?”
• “Why can’t a program that only calls three functions run on an operating system that has them?”

These questions are all about details. These details have nothing to do with what a program does, and their answers don’t even need to make sense, but if nobody on a team is asking or caring about details just like these then I have concerns. Quality programs, regardless of function, feed on the socially devastating obsession to inconvenient, indirect, often otherwise inconsequential details that only nerds get right. Dependencies fall into that class of details. If a team of nerds can’t get those right, what can they?

An example of this quality that comes to mind is µTorrent. µTorrent, the most popular BitTorrent client (outside of China), has kept itself a small standalone program since 2005 by using its own custom CRT code. The µTorrent team has even figured out how to get the best of both worlds: µTorrent manages to link to the old ever-present msvcrt.dll despite being compiled with Visual Studio 2008! That’s extremely difficult and entirely unsupported, yet they go through all that trouble just to keep their program small without incurring the responsibility of managing dependencies. If µTorrent triples in size tomorrow and requires an installer, no one is going to stop using it. µTorrent’s only function that matters is its ability to download interesting things. That its programmers care enough to take extreme measures to keep it lightweight fills me with a great confidence in that primary ability, a confidence that turns out to be well founded.

Another example is the Windows Task Manager. I was delighted to find out that Task Manager’s original author avoided CRT reliance in the name of program size. Task Manager, the program that needs to work when all others don’t, is very concerned about dependencies. I’d never thought to appreciate Task Manager, but reading Dave’s account of the work he put in to make the program meet his self-imposed criteria for quality makes two things clear: Task Manager was built with love, and you want Dave on your team. Dave took the time to write flicker prevention code for his Performance tab because he cared, and his successors didn’t even care enough to invoke that code on their Networking tab. What does that say about the code that actually manages tasks? I can only speculate, but I’m certainly glad Dave got to Task Manager first before they did.

Alright, then. Enough of that, back to this. Let’s turn off dynamically linking to the CRT in favor of static linking.

Configuration Properties \ C/C++ \ Code Generation \ Runtime Library
	Multi-Threaded DLL (/MD) => Multi-Threaded (/MT)

Rebuilding nets us… 49,152 bytes! All profit! Wait…

Well we ditched our dll dependency but now we’re huge. Let’s try going cold turkey on Visual Studio’s CRT completely.

Configuration Properties \ Linker \ Input \ Ignore All Default Libaries
	No => Yes (/NODEFAULTLIB)

Rebuilding gets us… 2 unresolved external symbol linker errors!

Well that’s cold turkey for you. As I alluded to / blatantly stated earlier, we’re going to use a tiny custom CRT of our own to get by. This is what I meant by going off the reservation. It’s called minicrt and for now I’m going to completely gloss over the origin of this methadone and also kick these lame addiction metaphors. Kick ‘em like smoking. Dammit!

Configuration Properties \ Linker \ Input \ Additional Dependencies
	minicrt.lib

Rebuilding gets us… 3,072 bytes! And some warnings about section merging. Well, what doesn’t these days?

In one shot we dropped a Visual Studio 2005 standalone program to a sixteenth of its size, and for what it’s worth killed off the IsDebuggerPresent() dependency. That… seems like a big deal. In fact, that was the whole ballgame! Any size reduction beyond that is penny ante and just for fun. I know, right, what are we waiting for?

At this point HideAutoUpdate.exe has four sections, each of which is aligned on a 512 byte boundary, which is a fancy way of saying that they’re multiples of 512, which to us means that each is a minimum of 512 bytes. If we can eliminate or merge some sections then the program gets smaller. First on the chopping block is the resource section .rsrc. The only reason a resource section is being built is so that the XML manifest that Visual Studio generates can be embedded there. The only use this interfaceless app had for a manifest was to contain the version info for the necessary CRT dll. Since we’ve eliminated that need, disabling the manifest will in turn eliminate the resource section.

Configuration Properties \ Linker \ Manifest File \ Generate Manifest
	Yes => No

Rebuilding gets us… 2,560 bytes!

As prophesied, there goes 512 bytes. We’re left with three sections: .text, .rdata, and .data. We’re stuck with their contents so we’ll merge them together. First up, merging .text into .data, and while we’re at it let’s silence the merge warnings.

Configuration Properties \ Linker \ Command Line \ Additional Options
	/merge:.text=.data /ignore:4254

Rebuilding gets us… 2,048 bytes! And no more warnings!

That leaves .rdata and .data. Once more, with feeling:

Configuration Properties \ Linker \ Command Line \ Additional Options
	/merge:.text=.data /merge:.rdata=.data /ignore:4254

Rebuilding gets us… 1,536 bytes! Ding ding ding!

It’s that simple, and yet that hard. Or rather I just made it look hard with all the gabbing. Maybe a quick recap can save this:

Numbers don’t lie, replacing the Visual Studio CRT is how you make small programs small. Linker settings are peanuts. As we’ll see next time, this is old news.

I’d be remiss if I didn’t mention a few other settings. Though in this instance they didn’t affect file size, they do under other circumstances or are at least in the same spirit.

Configuration Properties \ C/C++ \ Optimization \ Optimization
	Maximize Speed (/O2) => Minimize Size (/O1)

HideAutoUpdate does so little that there’s nothing this setting can optimize further, and so it has no effect on it. On non-trivial programs it makes a difference, sometimes significantly. Both settings, /O1 and /O2, expand into a set of individual optimization settings, most of which the two share so it’s not an either/or thing. You get a lot of the same optimizations either way.

Configuration Properties \ Linker \ Optimization \ Optimize for Windows98
	Default => No (/OPT:NOWIN98)

When set to Default, this optimization automatically kicks in once a program reaches a certain size. This optimization changes the section alignment from 512 to 4,096, which makes a program load quicker on Windows 98. For small programs that means each section costs a minimum of 4kb instead of 0.5kb. HideAutoUpdate is so small that Visual Studio didn’t enable the optimization, but it should still be nipped in the bud. This setting was tripped when we first statically linked to the CRT and it contributed to the large 48kb file size. It would have been 37kb if the optimization was explicitly disabled.

Configuration Properties \ Linker \ Debugging \ Generate Debug Info
	Yes (/DEBUG) => No

It seems questionable to me that this is enabled by default for Release configurations. This setting embeds a string in the program to the full path of the program database file on your computer, which could easily be something along the lines of, oh I dunno, “C:\Documents And Settings\D.B.Cooper\My Documents\Visual Studio 2005\Projects\HideAutoUpdate\Release\HideAutoUpdate.pdb”. That feels like an inappropriate amount of information to be exposing by default, and frankly, a pretty lame way for me to go down.

Configuration Properties \ General \ Character Set
	Use Unicode Character Set => Not Set

To set the character set to ANSI, set the character set setting to Not Set. Think about that the next time you wonder what’s keeping normal people out of the industry. HideAutoUpdate has to use the ANSI versions of Windows functions to run on Windows 95, 98 and ME because ANSI versions are all those operating systems have. Otherwise I’d be in trouble for linking to FindWindowW() instead of FindWindowA(). Dependencies!

Let’s never write this article again, shall we? Next time I swear to God I’m not going to mention a single compiler setting. Instead we’ll learn about the origin of minicrt.lib. Well… I’ll learn how to write an origin of minicrt.lib and you’ll learn how to fact check it. Also, source code. Until then, enjoy the compiled library. For a lot of modest programs simply using this will shrink them without complications. Others… not so much. Eventually we’ll see what can be done about those too.

minicrt.lib

I think it’s safe to say that you’re familiar with this unabiding dude. Years ago I wrote a program to suppress Automatic Update’s repeated prompting by setting the window’s state to hidden. This simple parlor trick is easily the most well received program I’ve ever written. Ubiquitous loathing equals opportunity.

There are more official ways to silence the nagging such as stopping the Automatic Update service but they require admin rights so that’s likely a non-starter if you’re at work. This low-brow, low-impact trick requires no special access and is a great compromise: you get prompted when you need to restart, which is good, and you can choose to dismiss the prompt without further prompting, which is also good. And if you do want to see the prompt again, just click Automatic Update’s icon in the system tray and it will return.

So let’s take a look at this unadulterated pinnacle of twenty first century technology:

// HideAutoUpdate by Chris Benshoof
//  the best flipping thing i'll ever write
#include <windows.h>
#include <tchar.h>

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
    HWND dialog = FindWindow(WC_DIALOG, _T("Automatic Updates"));
    if (IsWindowVisible(dialog))
    {
        ShowWindow(dialog, SW_HIDE);
    }
    return 0;
}

Yup, a life well spent. There’s really not much to elaborate on, it’s easy to write self-documenting code when your entire program is three function calls. The reason this prevents the dialog from coming back is that as far as Automatic Update is concerned the dialog is already being shown. It’s only when the dialog is closed or minimized that Automatic Update considers it gone and in need of eventual resurrection. Automatic Update never considers the possibility that the dialog is hidden (why should it?) and so placation ensues. If it weren’t so thoroughly disrespectful to the civil rights movement to compare myself with a leader of nonviolent resistance, I would totally compare myself to a leader of nonviolent resistance.

I write a lot of programs like this, little ones that wrap around or make use of just a couple API calls. It’s kind of a stretch to even call them programs. They’d be scripts if I didn’t have to bust out a damn C++ compiler to do anything interesting in Windows. S’all in the game, yo. If I have to write some small programs then I’ll write some small programs. Fact is, I kinda like it. But if I have to compile some small trivial programs… well then I expect the resulting program files to be small, because they’re trivial. Who wouldn’t? Errrbody, apparently.

Next time we’ll get completely distracted by the issue of executable size in a modern Windows world without getting distracted by its questionable relevance. Until then, enjoy all 1.5kb of HideAutoUpdate.exe!

HideAutoUpdate.exe

I’m a computer programmer and consequently I’ve written a number of computer programs over the years. Most are big and written for pay but it’s the smaller ones written for myself that I think are interesting. Not being one for self-promotion, insobriety aside, these personal programs have gotten virtually no exposure. In order to even hear about them we’d need to be sharing a home, office, or pitcher of Pabst. That’s probably for the best as they’re geared towards a pretty specific and possibly eccentric audience, but it would be nice if someone besides me could get something out of them.

Whenever I’m done figuring out some computerish thing I fire up a text editor and write myself a note. Few things are as frustrating and humbling as learning something again from scratch, so these notes are desperate sandbags against time and forgetting. Written quickly and informally, they work, but there are limitations to the format. And again, it seems a shame that they only help me.

Now I find myself with a heap of programs and a grip of notes. Pawing through them I see an eclectic body of work, work that in theory other programmers might find interesting. Most of it is grounded in Windows programming but who knows, maybe someone out there still does that. Worst case scenario, it’s comic relief for everyone else.

So here’s the plan: I’m going to write about my programs and how they were built while wandering into ancillary note topics at the drop of a hat. This could take a while, but that’s okay. I have the time. Besides, what’s the worst that can happen? A little pretentious technical writing infused with awkward hip hop references ain’t never hurt nobody.