EDIT 0.5 bug-bashing: five bug sources, anybody got time to fix?

Hi,
I think I got the edit c:\foo.bat bug source.
Please check the bugtrack system. I have also
found the sources for the edit ignores altgr combos
and the edit ignores chars < ' ' bugs. See the
bugtrack system. Finally, I think I know why killing
EDIT with control-c crashes the system when you start
the next program.


Very short summary for the list, if anybody else got time
to fix the bugs:

    if (cm & DIRECTORY)    {
        cp = dir+strlen(dir)-1;
        if (*cp == '\\')
            *cp = '\0';
        chdir(dir);
    }

in DIRECT.C will strip trailing "\" from "cd foo\", but will
also strip down "\" to "" producing a "cd ".

static void StopMsg(void)
{
    if (oldtimer != NULL)    {
        setvect(TIMER, oldtimer);
        oldtimer = NULL;
    }
    if (oldkeyboard != NULL)    {
        setvect(KEYBOARDVECT, oldkeyboard);
        oldkeyboard = NULL;
    }
...
}

in MESSAGE.C will not be called when you terminate EDIT 0.5 by control-c,
so the interrupt vectors are left dangling. Solution: Add a control break
handler.

static void KeyTyped(WINDOW wnd, int c)
{
    char *currchar = CurrChar;
    if ((c != '\n' && c < ' ') || (c & 0x1000))
        /* ---- not recognized by editor --- */
        return;
...

in EDITBOX.C will not allow you to type characters < ASCII 32 (' ') into
your text file.

int getshift(void)
{
    regs.h.ah = 2;
    int86(KEYBRD, &regs, &regs);
    return regs.h.al;
}

in CONSOLE.C cannot distinguish between left and right (altgr) ALT key,
so all AltGr combos will be treated as hotkeys. So if you press @ on a
German keyboard (AltGr+q), EDIT will do plain nothing, as no hotkey
Alt+@ is defined. Solution: use function 12 and regs.x.ax instead of
function 2 and regs.h.al - this will give you a more detailed shift
status. See RBIL (IntList) 61, -1612- and -1602- for details. You may
want to run the -1609- and -15C0- install checks to know whether the
-1612- extended shift status is available before using it.

Eric

PS: Bonus bug:
Even if you are using wildcards, EDIT 0.5 will do, in EDIT.C:

        if ((fp = fopen(fileargs[1],"r")) == NULL)
            {
            NewFile(wnd,fileargs[1]);
            }
                else
            PadWindow(wnd, fileargs[1]);

        --argc;
                argv++;
        }

I think this is very bad style for testing the existence of fileargs[1],
which you do not even know of whether it contains wildcards at that point.
PadWindow is the one that handles wildcards, NewFile is the one that
creates a new file. Weird, hu?