• A comment on DOSLITE and COMMAND.COM

    From Steve Nickolas@usotsuki@buric.co to comp.os.msdos.programmer on Tue Aug 2 09:28:32 2022
    From Newsgroup: comp.os.msdos.programmer

    This message is in MIME format. The first part should be readable text,
    while the remaining parts are likely unreadable without MIME-aware tools.

    --8323329-562253984-1659446913=:30401
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE

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

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

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

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

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

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

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

    -uso.

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

    Obviously the INT24 handler needs to be updated.

    Handling of the @ metacommand should go between GETCOM and NOPDRV=20
    somewhere.

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

    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=
    =20
    top of INIT.ASM, currently a constant. The fixed value is 160 (I think=20
    this remains the default). Whatever user value is supplied, to reallocate=
    =20
    (there seem to be two points in the same file, search for the word=20
    allocate, case-insensitive) the appropriate memory this value needs to be=
    =20
    SHIFTED RIGHT 4 BITS.

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

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

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

    LOADHIGH needs to be implemented.

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

    DATE

    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=
    =20
    this point, perhaps another register can be set to point to one of these=20 three strings, and then print it immediately after - (mm-dd-yy) (0,=20
    USPDAT), (dd-mm-yy) (1, EUPDAT), (yy-mm-dd) (2, the code immediately=20 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.

    TIME

    Being able to use "AM" or "PM" in time designation has only been a thing=20 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=20
    couple lines before SAVTIM, where AL is compared to 13 (carriage return).=
    =20
    I am not certain about this.

    Pseudocode - haven't worked this out yet.

    IF hour=3D12 AND ampm=3DAM, THEN hour=3Dhour-12, ELSE if hour=E2=89=A012 an=
    d ampm=3DPM,=20
    THEN hour=3Dhour+12

    MS-DOS 6.x and the COMMAND command

    /D

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

    /K

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

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

    /MSG

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

    /Y

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

    /H

    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=20 should be added at some point.

    DOSKEY

    DOSKEY is described well enough in the RBIL.

    The point in which it should be invoked is probably very near the point=20 where I suggested looking for a place to put the code to handle the @=20 metacommand.
    --8323329-562253984-1659446913=:30401--
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Robert Riebisch@Robert.Riebisch@arcor.de to comp.os.msdos.programmer on Sun Aug 7 21:54:32 2022
    From Newsgroup: comp.os.msdos.programmer

    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
    --- Synchronet 3.21d-Linux NewsLink 1.2