• A comment on DOSLITE and COMMAND.COM

    From Steve Nickolas@21:1/5 to All on Tue Aug 2 09:28:32 2022
    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    I thought I had an account on BTTR but I guess not. Anyway, I'm sure that posting here will get across what I intend to say.

    One of the criticisms I got when someone linked my project there was the
    lack of any kernel stuff or a working shell. Fair. I don't know what I'm doing at that level.

    However, I think I know enough to provide one end of the Chinese wall, if anyone else has the MS-DOS 2.11 command.com code as I do and would like to give it a whack, with some very specific suggestions on what needs to be changed (basically everything that was added to it since 2.11 until PC DOS
    7), and even where the code might need to be changed.

    Additionally, the document I wrote suggests where some code I *did* write might be usable.

    Original link: https://github.com/buricco/doslite/wiki/command.com

    For the record, a paste follows. The "command.a86" mentioned is https://github.com/buricco/doslite/blob/main/exper/command/command.a86 and implements some stuff that *could* be used for a command shell but the scaffolding is too buggy to be of any use.

    (If combined with the MS-DOS code, I obviously am granting the permission
    to use the X Window license in lieu of the UIUC license, as can be seen elsewhere in the project where I modified MS-DOS 2.11 code.)


    These notes regard the MS-DOS 2.11 command.com and how it could be made
    usable for DOSLITE.

    Obviously the INT24 handler needs to be updated.

    Handling of the @ metacommand should go between GETCOM and NOPDRV

    Perhaps one byte should be read from the file, checked against @, and then
    an lseek(file, -1, SEEK_CUR) (AX=$4201, CX=DX=$FFFF) if it doesn't match.

    A rough implementation of CHCP can be found in command.a86.

    I'm not sure how to handle CALL.

    I suspect the important thing for the /E switch regards ENVIRONSIZ at the
    top of INIT.ASM, currently a constant. The fixed value is 160 (I think
    this remains the default). Whatever user value is supplied, to reallocate (there seem to be two points in the same file, search for the word
    allocate, case-insensitive) the appropriate memory this value needs to be SHIFTED RIGHT 4 BITS.

    Mutatis mutandis, this should at least bring the functionality up to the
    3.3 level, and would be the hardest changes to make.

    An implementation of DEL which supports the /P switch (introduced in 4.0)
    can be found in command.a86. I don't know if it's better or worse than
    what is there now.

    It's possible I might have the better implementation of CTTY - haven't
    been able to test.

    LOADHIGH needs to be implemented.

    DIR may need to be gutted to implement the /A, /O and /S switches from
    MS-DOS 5.


    Currently, "Enter new date:" is printed at GETDAT in TCODE4.ASM.

    The code to determine which order is used is further up, in P_DATE, and at this point, perhaps another register can be set to point to one of these
    three strings, and then print it immediately after - (mm-dd-yy) (0,
    USPDAT), (dd-mm-yy) (1, EUPDAT), (yy-mm-dd) (2, the code immediately
    preceding USPDAT), to bring DATE up to the level of PC DOS 3.0.

    Perhaps the date check should assume a 2-digit year <80 is 20xx.


    Being able to use "AM" or "PM" in time designation has only been a thing
    since PC DOS 4.

    The important bit for display is P_TIME, again in TCODE4.ASM.

    Most likely where support for AM/PM entry needs to be hacked in is a
    couple lines before SAVTIM, where AL is compared to 13 (carriage return).
    I am not certain about this.

    Pseudocode - haven't worked this out yet.

    IF hour=12 AND ampm=AM, THEN hour=hour-12, ELSE if hour≠12 and ampm=PM,
    THEN hour=hour+12

    MS-DOS 6.x and the COMMAND command


    In MS-DOS and PC DOS 6+, the /D switch is used by the kernel to handle the
    F5 skip startup files option. But it has actually been in the code since
    just after version 2.0.


    A hint can be found at NEXTCH3 in INIT.ASM. This is where the /C switch is processed.

    The difference between /C and /K is that /K will not abort the shell after
    the command is run. If used with /P, the /K switch changes the name of the AUTOEXEC command that is invoked by the shell.


    No idea how this could be implemented. None of DOSLITE uses the
    functionality of /MSG for anything. Maybe make it a NOP.


    This is used by the F8 step trace option in MS-DOS 6.2/PC DOS 6.3 and
    later, but is also documented and can be invoked by the user along with /C
    and /K to trace other shell scripts.


    This switch is used by PC DOS 7 to cause the shell to move itself high.

    Although it is a low priority, this is a VERY useful switch and probably should be added at some point.


    DOSKEY is described well enough in the RBIL.

    The point in which it should be invoked is probably very near the point
    where I suggested looking for a place to put the code to handle the @ metacommand.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robert Riebisch@21:1/5 to Steve Nickolas on Sun Aug 7 21:54:32 2022
    Steve Nickolas wrote:

    I thought I had an account on BTTR but I guess not.

    I would think so too.

    I did some search on the user list, but didn't find your account.
    Feel free to ask me (or ecm) for an account: https://www.bttr-software.de/forum/contact.php

    Robert Riebisch

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)