Two different shells present the exact same two bugs only if using EDR-DOS kernel

[igully]

PsysTechSoft PTS-DOS 32 and V Communications DOS98 shell interpreters show the exact same anomalies:

CTTY CON (or whatever other char device)
Invalid device

CLS
Changes the font color to blue.

Since both shells are totally unrelated and behave well with their own original kernels, I can only assume that the EDR-DOS kernel is failing to do something that it should be expected to do.

I am attaching a bootable floppy image that has the EDR-DOS kernel and a startup menu that will allow you to switch between the two shells mentioned above, so that you may reproduce the issues.

twoshells.zip

[boeckmann]

Relevant source of the PTS-DOS 6.51 command interpreter:

CTTYproc	proc	near	;; new
	;;	In : None
	;;	Out: redirected In/Out in MainPSP, not this
	;;	     CF set on error
	;;	Mdf: Flags,SI,AX,ES,DI
;;  First Set Parent PID as active
	call	GetNextParam

;;  Start COMMAND critical section.
	mov	dl,0	;; Disable Ctrl-Break
	Func	XchgBreak
	DOSint
	push	dx
;;
	LoadExtra
	mov	bp,ds
	mov	ds,ds:[ParentPSP]
	SaveExtra
;;  Now make CTTY.
	call	TestIfStdDev
	jnc	__doRedir
	mov	dx,di

	push	ds
	push	es
	pop	ds
	Func	GetFileAttrib
	DOSint
	jc	__invDev
	test	cl,DeviceAttr
	jz	__invDev
	Func	OpenReadWrite
	DOSint
	jc	__invDev
	pop	ds
	mov	bx,ax

__doRedir:	mov	cx,2	;; CX = StdErr handle
__nextRedir:	Func	DoRedirect
	DOSint
	jcxz	__finished
	dec	cx
	jmp	__nextRedir

__finished:	cmp	bl,5
	jb	__exit	;; Do not close Standard Devices.
	Func	CloseFile
	DOSint
__exit:
	mov	ds,bp
	SaveExtra
;;  Restore old Break value
;;  End of COMMAND critical section.
	pop	dx
	Func	SetBreak
	DOSint
	jmp	Quit
;;    Invalid device.
__invDev:	pop	ds
	mov	dx,offset InvalidDevice
	call	TypeErr
	jmp	__exit

CTTYproc	endp

CLSproc	proc	near	;; new
	;;	In : None
	;;	Out: If StdOutput is screen then clear it
	;;	Mdf: All
	mov	bx,StdOutHandle
	Func	IOCTLDevInfo
	DOSint
	test	dl,SpecialDevice
	jz	__exit
;;  Test iIsSwf ANSI installed.
	Func	ChkInstANSI
	DOSmulti
	cmp	al,0ffh
	jnz	__clearScreen
;; ANSI installed, send escape sequence
	push	cs
	pop	ds
	mov	dx,offset CONspec
	Func	OpenWrite
	DOSint
	jc	__clearScreen	;; Failed, clear rudely
	mov	bx,ax
	mov	cx,ANSIClsSeqSize
	mov	dx,offset ANSIClsSeq
	Func	WriteFile
	DOSint
	jc	__clearScreen
	Func	CloseFile
	DOSint
	jmp	__exit
;;  Work directly with screen.
__clearScreen:	mov	ah,0fh	;; Get current video mode
	VideoCall
	push	bx
	push	ax cx es bp bx
	mov	dl,25
	mov	bh,0
	mov	ax,1130h	;; Get EGA info
	VideoCall
	;dec	dl
	pop	bx bp es cx ax
	mov	dh,dl
	mov	dl,ah
;;  Get DOS attribute to draw (white on black)
	mov	ax,1262h
	DOSmulti
	mov	bh,al
	xor	al,al
	xor	cx,cx
	mov	ah,6
	VideoCall
	pop	bx
	mov	ah,2	;; Set cursor position
	xor	dx,dx
	VideoCall
__exit:	jmp	Quit
CLSproc	endp

[boeckmann]

Regarding the CTTY error: Seems that INT21.4300 returns with carry set and AX=2 (file not found) under the EDR kernel when a device is given. Seems to work for files on disk.

[boeckmann]

Regarding the CLS: PTS COMMAND uses the PTS specific INT2F.1262, and does not check for error, so screen seems to be cleared with some unspeficied character attribute.

[boeckmann]

Regarding the CTTY error: Seems that INT21.4300 returns with carry set and AX=2 (file not found) under the EDR kernel when a device is given. Seems to work for files on disk.

This should also be the behaviour of the FreeDOS kernel: https://github.com/FDOS/kernel/blob/56a86d2ad414a733d4c9b9346cfdee611d04eb4e/kernel/dosfns.c#L1200

Not verified yet how MS-DOS handles this. Probably the same...

[boeckmann]

This "unspecified" I mentioned above is probably the error value AX=1 (invalid function number). Writing this as character attribute results in blue text on black background (on color display).

[boeckmann]

@igully where did you get the DOS98 shell from? Never heard of it before. As it shows similar behaviour as the PTS shell one might come to the conclusion that both shells have the same origin.

[boeckmann]

Inspecting both PTS-DOS.COM and DOS98.COM indeed reveal similarities that cannot be a coincidence. I am quite certain that these shells originate from the same code base.

[igully]

Quick and dirty information that I found out from DOS98:

Commercial life started around 1997 and ended up in 2007 approximately. During
its life-time it appears that no DOS component was ever updated with the
notable exception of its specialized GUI which seemed to have reasonably
received all the attention with updates, fixes and changes to its visual
appearance in an attempt to follow the style of what the current version of
Microsoft Window was more popular back then.

It came integrated within the following products:
"V Communications, Inc." later "Avanquest Publishing, Inc." - "System Commander"
and "Partition Commander" products that are versions 4.0 and higher

This is a standalone DOS with a mouse driven 32-bit GUI that uses
the DOS 32-bit extender DOS/4GW version 1.97. The GUI is actually a multi-boot
manager, partitioning tool, drive formatting utility and an OS installer.

Minimum hardware requirements:
386 CPU or better
128 KB of conventional memory
120 KB of FAT 12 or FAT 16 storage space for only the DOS text mode components.
2.6 MB of FAT 12 or FAT 16 storage space for a full installation including GUI components.

Main files:
SCIN.EXE - (Compressed with PKLite) Utility to enable/disable System Commander, diagnostics and other information.
SCDISK.EXE - Boot selector. Utility to look at partition information, view the OS selection screen and other options.
SCOUT.EXE - Generates a text file of the System Commander settings and general system information.
CHECKMBR.EXE - Validates and updates MBR if System Commander was disabled by a new OS installation.
SETUP.EXE -
SCOSW.EXE - System Commander OSWizard (GUI)
SCOSW_A.SYS - MS-DOS.SYS counterpart loads CONFIG.SYS (15.845 bytes)
SCOSW_B.SYS - IO.SYS counterpart loaded by the boot sector (59.416 bytes)
SCOSW_C.SYS - CONFIG.SYS counterpart (59 bytes = less than 100 bytes/variable)
SCOSW_D.SYS - Shell interpreter (45.115 bytes)

Internal Shell commands:

ATTR/ATTRIBUTES
BR/BREAK
CALL
CD/CHDIR
CHCP
CLS
COPY/XCOPY
CTTY
DATE
DEL/DELETE/ERASE
DIR
ECHO
ECHONLF
EXIT
FOR
GOTO
IF
LOADHIGH/LH
LS
MKDIR/MD
PATH
PAUSE
PROMPT
REPLACE
RH/RUNHIGH
RMDIR/RD
REM
REN/RENAME
RUN
SET
SHIFT
TIME
TREE
TRUE/TRUENAME
TY/TYPE
VER/VERSION
VERI/VERIFY
VOL/VOLUME

Shell peculiarities:

TREE, ATTR, REPLACE and XCOPY are internal commands. Also VERSION (internal
command) works as a SETVER (version number faker) counterpart.

The MORE command is absent, however its functionality is integrated as optional
parameter on ATTR, DIR, TREE and TYPE internal commands.

The CHOICE/ASK command is available thru the IF (internal command), which also
implements comparative conditionals like EQ, NE, LT, GT, LE, and GE.

The DELETE command has a parameter which works much like DELTREE which actually
does not exist as such.

LS (internal command) is much like DIR /W but without byte counts, which makes
it much faster on slower systems. It is not internally documented, however it
has at least /A (with specified attributes much like DIR /A) and /O (in sorting
order much like DIR /O) as valid parameters.

ECHONLF (internal command) is an echo without Line Feed (without jumping to a
new line).

TYPE can convert text style from Unix/Linux (LF) to MS-DOS/Windows (CR+LF)

Interesting variety of command interpreter prefixes: CALL, LH/LOADHIGH, RUN,
RH/RUNHIGH, C/COMMAND, K/KEEP, P/PERMANENT, E/ENVIRONMENT, F/FAIL, D/DEFAULT,
Y/YES, and /? or /HELP

[boeckmann]

So to come to an conclusion: both shells are derivates of the PTS command interpreter, with the DOS98 one likely being a rebranded later iteration, and as such they are not "totally unrelated" products regarding their code.

As the shells make use of PTS DOS specific API calls, I do would not classify the CLS issue as an EDR bug. Regarding the CTTY issue, I will investigate whether MS-DOS also returns with carry set when INT21.4300 is invoked on a device.

[boeckmann]

MS-DOS explicitly tests for a device and returns with CY,AX=2 "file not found" according to the MS-DOS 4 source.

[igully]

So, then, false alarm.
Would it make sense to recreate a few of those specific PTS-DOS API falls to achieve some level of compatibility? Or is this a case of too much effort for little gains?

[boeckmann]

Would it make sense to recreate a few of those specific PTS-DOS API falls to achieve some level of compatibility?

I do not think so, as I am not aware of anything else than the PTS specific commands using these calls. We should keep in mind implementing it would result in dozens to hundreds of extra kernel bytes, with VERY limited use case. One could make this a kernel build option though, but if you are strongly interested in the PTS command interpreter running on the EDR kernel I suggest adapting the PTS command source. It can be found on the PTS-DOS 6.51 CD-ROM, which you probably know where to find.

[igully]

Yes, probably not worth it, if only few cases exist and do not conform to the "standard" DOS API.
A pity, but absolutely reasonable.