funcA(false);
funcB(false);
funcC(false);
funcD(false);
funcA(true);
funcB(true);
funcC(true);
funcD(true);

and, in a burst of sheer genius, came up with this solution:

for (bool status = false; status <= true; ++status) {
  funcA(status);
  funcB(status);
  funcC(status);
  funcD(status);
}

He then scratched his head as the program looped for eternity.

Who could have predicted that a common-or-garden bool could have so many values? Let me count them. The possible values of bool are false, snopes, statistically_significant, almost_true, true, very_true and tautology. ++tautology gives you tautology right back, as any fule kno.

Firstly, I’ll tell you what I’m not showing you.

• I’m not showing you that this claims to be an XHTML page, despite the invalid element nesting that makes Firebug mark many of the elements of the DOM in its faded “what the hell?” style
• I’m not showing you that the same JavaScript function is included twice, for no useful purpose.

In fact, I’m showing you a cleaned-up snippet that demonstrates the behaviour of the login form while sparing you some of the worst syntax of the original.

The login form

The login form appears on the page as two text fields, for username and password, and a “Connect” button, as you’d expect. What is not apparent until you examine the source, is that the username and password are in different forms, which I believe is the key to this trick.

 <form name="login"
       action="sm_login.fcc"
       method="post"
       onsubmit="connect(); return false;">
    <input type=hidden name=SMAUTHREASON value="0">
    <input type=hidden name=SMAGENTNAME value="IoqEFNY64K">
    <input type=hidden name=POSTPRESERVATIONDATA value="">
    <input type=hidden name="SMENC" value="ISO-8859-1">
    <input type=hidden name="SMLOCALE" value="US-EN">
    <input type="hidden" name="PASSWORD" value="">
    <input type="hidden" name="lang" value="">
    Username: <input type="text" name="USER" maxlength="8" size="23">
  </form>
  <form name="pwd"
       onsubmit="connect(); return false;"
       method="post"
       action="">
    Password: <input type="password" name="tpep" size="23">
  </form>
  <input type="button" value=" Connect " onclick="javascript:connect()">

So here we have two forms. One is the real login form, login, but what should have been a password text field has been made hidden. A second form, called pwd, has been used to hold a new password text field. The “Connect” button doesn’t belong to either form, but calls a global connect() function, just as the other two forms do.

connect() function

Both forms run submissions through a piece of JavaScript:

function connect() {
  if (document.login.USER.value == "") {
    alert('Enter your user name');
    document.login.USER.focus();
  } else {
    if (document.pwd.tpep.value == "") {
      document.pwd.tpep.focus();
    } else {
      document.login.PASSWORD.value = document.pwd.tpep.value;
      document.login.lang.value = document.pwd.lang.value;
      document.pwd.tpep.value='';
      document.login.submit();
    }
  }
}

This little beauty does some standard checking that neither the username or password are blank, but then it copies the password field that we typed into the other form’s hidden field, blanks the visible password, and then forces submission of the login form.

This function can’t just return true or false to allow or stop the normal submission event, because it might have been invoked from the second form, “pwd”, if I pressed Enter after typing my password.

Greasemonkeying this baby

I routinely use Greasemonkey to make our intranet even vaguely usable, which for me means making sure that text isn’t too small for me to read, correcting structural defects that Internet Explorer ignores but which break the layout on Firefox, and adding functionality to applications.

Unfortunately, the structure of the real page that contains this snippet is ugly enough that I’ve so far failed to fix it. What I need to do is to defang the connect() function and put the password field in the first form, but I’m going to have to rewrite quite a chunk of the login page to achieve this.

While considering how to do it, however, I was playing around in Firebug, and quite by accident managed to rewrite the form enough to get Firefox to remember the password, and then insert it in the real thing. Bizarre, but satisfying

I’ve been working on some vintage code (at least 15 years old) that provides a model for how not to do things. The compilation is controlled by no fewer than 750 #ifdef switches. Many of these are used in header files as guards against double inclusion, but the others roughly split into these jobs:

• controlling platform-specific code generation
• controlling project-specific code generation
• experimental features
• controlling different versions of hardware

The oddest of these switches are:

For the people who don’t like to document:

#ifdef __

For dyslexic programmers:

#ifdef DSTL_UPGRADES
#ifdef DTSL_UPGRADES

For those who think the code runs too quickly:

#ifdef INEFFICIENT

For those hopeful of a quick fix:

#ifdef MAKETHISWORK

For those who aren’t confident of our source control systems (and are dyslexic):

#ifdef OLD_SLOW_WAY
#ifdef ORIGINAL_CODE
#ifdef OROGINAL_CODE
#ifdef REDUNDANT_CODE
#ifdef REDUNDANT_FUNCTIONS

For those who can’t quite remember which operating system they are using:

#ifdef _vxworks
#ifdef __vxworks
#ifdef VXWORKS
#ifdef _VXWORKS
#ifdef __VXWORKS

For those trying the super-secret go-faster-stripes:

#ifdef WIN32_LEAN_AND_MEAN

For those who super unpositively don’t no way double negative want that code:

#ifdef _WIN32_trynot

. . . but just the once, or later, or huh, maybe not at all?:

#ifdef __JUSTONCE__
#ifdef _JUST_ONCE_
#ifdef notdef
#ifdef __NOTSMART_
#ifdef _NOTSMART_
#ifdef notyet
#ifdef NOTYET
#ifdef THIS_IS_NECESSARY
#ifdef THIS_IS_TOO_EXPENSIVE

Even the choice of names for include guards shows how coding standards change over time, or are ignored, or how the language standards themselves are ignored (the leading underscores):

xxx_inc_
_xxx_H_
__xxx_H__
xxx_include
xxx_H
xxx_inc
xxx_h
xxx_Hinc
_INC_xxx
INC_xxx

This all made sense until we discovered the shortcomings of the disks and drives. We’d buy disks, write them on the work PC, then take them home and find that we couldn’t read them. After a while, you could be unlucky enough to not even read disks on the machine you’d used to write them. We sighed heavily and moved onto writing CD-Rs instead.

Moving on a decade, I’ve recovered my old PC from under the bed in the guest bedroom and set about reading my old SuperDisks. Rather than fire up the old Windows 95 box, I moved the Matsushita LS-120 drive into my current desktop PC, running Fedora 9 Linux. I still have ten SuperDisks, and I know that one of them contains the contents of a bunch of old floppy disks that I thought, ten years ago, would be better off consigned to a single disk. Ho hum. Those floppy disks contained a load of Type 1 fonts that I made, the PostScript files that I used to design and test them and the programs, written in VAX Pascal, that I used to build them.

Of the ten SuperDisks, two turned out to be unreadable, but the remaining eight had a just a single read error, corrupting a zip file containing some programs from my day job, so no real loss. All in all, I’ve recovered 300 MiB of old work, fonts and photographs. I must confess, I’m shocked and impressed at the success rate.

The recovered work is being stored on the hard drive of my desktop PC, being burned to a CD and squirrelled away on my ReadyNAS. I’m not making that mistake again!