MUD code spelunking

This was an amusing process, which someone might enjoy reading.
My old DikuMUD has a message board system that saves all the messages to files, and it was next
on the chopping block for SQL conversion, so of course, I had to figure out how it actually worked.

Unlike MOST things, the board system uses a built-in line editor, and in a DikuMUD that means
it has to save state information across the main loop.  Rather than put the user into a special
connection state, they did something very odd instead, which let them reuse the same editor
for anything, but which also means the code involved doesn't know what is being edited.

These are simply the comments I put in the code while figuring out what the hell it was
doing, so I could plan a way to replace it.

    // OK, so now we need the player data structure to have buffers to store
    // the subject line, and relocate a bunch of stuff that's probably in nanny()
    // here, so it's all in one place.
    //
    // The message date will be generated by the database itself.
    // The owner is GET_NAME(ch)
    // The subject is provided by arg.
    // The body will be provided by the nanny() state after the user exits the editor.
    // The message_id will simply be MAX(message_id) + 1 WHERE vnum = this board's vnum.
    //
    // Presumably, this is where the message will be captured.
    //      ch->desc->str = &b->msgs[b->msg_num];
    //      ch->desc->max_str = MAX_MESSAGE_LENGTH;
    //
    // So convoluted....
    //      Rather than using a proper connection state like nanny() does,
    //      There's a custom check on descriptor->str.  If it isn't NULL,
    //      it calls string_add(), passing it the descriptor and socket input.
    //          line 557 comm.c
    //      The socket input was obtained via get_from_q()
    //          line 541 comm.c
    //      That code however, only runs if get_from_q() returns 1, which happens
    //      when there was some input to process, which happened in process_input()
    //      in the loop above this one.
    //          line 518 comm.c
    //      The question is... what uses descriptor->str BEFORE it gets NULL'd
    //      away in string_add(), which sets it to NULL when it sees the terminator
    //      line (an '@' by itself)?
    //          line 104 modify.c
    //          line 130 modify.c
    //      AHA!
    //      board_save_board() is called from command_interpreter()
    //      if board_kludge_char is set.
    //          line 236 interpreter.c
    //
    //      SOOOO, desc->str is a pointer to the board message array element that
    //      holds the message body.
    //
    //      string_add() uses strcat() to append every line of input to that array
    //      element until the terminaitor is found.
    //
    //      At that point desc->str is set to NULL, and board_save_board() is called
    //      to write the changed array to disk.
    //
    //      The tricky part here is that we don't KNOW what string_add() was modifying
    //      since it's used for anything that uses the built-in editor.  We only have
    //      the point that board_save_board() is called.
    //
    //      What we probably need to do is make a board_message_data structre in the
    //      descriptor strcture, and simply check that.  We can set desc->str to point
    //      at that element or be NULL, to work with the existing code, and the check
    //      for board_kludge_char will simply be changed to check if the message structure
    //      has a non-zero message_id and vnum.