Errorlevels Codes in the DOS Batch process

[deathshadow]

It works (although it's only 8 bytes long, not 14) but it doesn't return the extended codes you're looking for.

It DOES return them -- the second time you call it -- that's why my batch file checks for non-zero codes first, retries if the value >=1, or drops through to the extended code test!?!

You guys did notice the rather convoluted batch file, right? Did any of you actually USE the .rar?!?

 

[deathshadow]

Is this your code for ASK?


function readkey:
char; assembler; asm

mov ah,$08
int $21 end;

no, that was an example of the source code of Turbo Pascal's readkey function -- which does the exact same thing which is why I keep pointing at the TP and FPC manuals for the list of extended keycodes.

 

[deathshadow]

Here's a TP program to show how int21 works, since it seems people aren't getting it.

program int21ah08;

function ourReadKey:char; assembler;
asm
	mov  ah,$08
	int  $21
	{ tp7 asm files return al to byte sized function results }
end;

var
	ch:char;

begin
	repeat
		ch:=ourReadKey;
		writeln(ord(ch));
	until ch=#27;
end.

You run that, press 'a', you get 97... your press shift-A, you get 65... your press F1, it outputs a zero followed by 59. Extended keycodes are two bytes long -- a Zero and then the code, so as to differentiate them from normal keystrokes.

INT 21 function 8 reads the keystroke, turns it into ascii if it can -- if the keystroke has no ascii equivalent it will send you a zero and the NEXT time your read it you'll get one of those extended keycodes... that's why that batch file has the convoluted check to see if the value is zero (via dropthrough) and call the read a second separate time with it's own run of checks. Anyone who's ever trapped an arrow key in pascal using readkey knows this -- if the first read is a zero, and the next read returns 121 (79h) -- then it's an up-arrow.

Hence why that batch file in the .rar and above drops through on zero and reads a second byte for a SEPARATE set of IF statements.

One fun thing I just realized -- because this is calling DOS and not BIOS, this should work on a Tandy 2000.

 

[MikeS]

Yes, I read the batch file, yes I understand what you're doing, no need to get testy.

AO stated that the 8-byte version did not work; I replied that (without the external test to see if it needed to be run again) it did indeed work but would not (by itself) return the extended codes he was looking for (in case that's why he thought it didn't work).

I also offered him a step-by-step example of using debug (in case he made a mistake using debug) to create the original 14-byte version which would display the extended codes, although as I understand it he wasn't looking for a code read program like yours at all, but a means of displaying the errorlevel value.

Once again, sorry I butted in.

 

[deathshadow]

Yes, I read the batch file, yes I understand what you're doing, no need to get testy.

Sorry folks, I have a low tolerance for "Do you understand the words coming out of my mouth!?!"

AO stated that the 8-byte version did not work; I replied that (without the external test to see if it needed to be run again) it did indeed work but would not (by itself) return the extended codes he was looking for (in case that's why he thought it didn't work).

I'm not getting how you are saying it would not work -- if it's looping back on itself blind (like it probably should) it would work identical to the previous one apart from the 0 being thrown away -- and since it outputs the zero it provides the extended code... how exactly does that "not work"?!? Also there is no '8 byte' version due to the minimum size of a COM file... the resulting file should be 14 bytes, not 8 -- SURE, the code you enter to do the gruntwork may work out to 8 bytes, but that's not the total filesize.

I also offered him a step-by-step example of using debug to create the original 14-byte version which would display the extended codes, although as I understand it he wasn't looking for a code read program like yours at all, but a means of displaying the errorlevel value.

Was that via PM or something as I'm not seeing it in the thread -- or are you referring to linking to the SAME ARTICLE I LINKED TO IN THE FIRST RESPONSE?!?

*SIGH*

 

[MikeS]

Sorry folks, I have a low tolerance for "Do you understand the words coming out of my mouth!?!"

No problem; it was AO who said your code does not work, so I'll leave you to explain it to him.

I still think that if the version of REPLY.COM he's using in his original post works then most of this is irrelevant to his question.

 

[MikeS]

...Also there is no '8 byte' version due to the minimum size of a COM file... the resulting file should be 14 bytes, not 8 -- SURE, the code you enter to do the gruntwork may work out to 8 bytes, but that's not the total filesize.

Is this "minimum size" documented anywhere? If I say rcx 8 I get an 8-byte file that seems to work OK; what prevents code after the 8th byte from being executed?

 

[Agent Orange]

It's getting late but there is some progress. This seems to work for the F12 key:

if errorlevel 134 not errorlevel 135 goto END

More tomorrow - hopefully.

P.S. Thanks you MikeS and deathshadow for pitching in on this. Wondering where Ole Juul is on this - seems this would be right down his alley.

 

[Ole Juul]

Wondering where Ole Juul is this - seems this would be right down his alley.

You'd think so. I'm into batch files, but I'm not a programmer and don't really understand what DS and MS are on about. Anyway, I'm in BSD symlink hell just now - so not feeling very sociable and my cat is hiding under the couch.

 

[deathshadow]

Is this "minimum size" documented anywhere? If I say rcx 8 I get an 8-byte file that seems to work OK; what prevents code after the 8th byte from being executed?

I do 8 here in 6.22 (under virtualBox -- just checked), I get a com file that just locks up and does nothing... unusual it would work, I was always told never declare less than E... though it's been so long damned if I can remember where.

 

[deathshadow]

if errorlevel 134 not errorlevel 135 goto END [/B]

I'd probably make that

if errorlevel 135 goto ASK
if errorlevel 134 goto END

because there's no reason to let it cascade down to the other checks for values higher than that. Values >134 would STILL drop-through with the double IF on one line... So checking for 133 for example would ALSO have to check for 134 and greater... then you'd have to check 69 and greater -- if you look at the BAT I made I try to pre-emptively loop back and pull another character as soon as possible for that reason. Simplifies the logic code.

Since you'd end up with:
if errorlevel 134 if not errorlevel 135 goto F12
if errorlevel 133 if not errorlevel 134 goto F11
if errorlevel 68 if not errorlevel 69 goto F10
if errorlevel 67 if not errorlevel 68 goto F9
etc, etc, etc..

for what could be just
if errorlevel 135 goto ASK
if errorlevel 134 goto F12
if errorlevel 133 goto F11
if errorlevel 69 goto ASK
if errorlevel 68 goto F10
if errorlevel 67 goto F9


YMMV, I find the latter a clearer approach to handling it.

 

[MikeS]

You'd think so. I'm into batch files, but I'm not a programmer and don't really understand what DS and MS are on about.

I'm not surprised; I'm not sure either ;-)

As happens so often the original question was answered in post #2 and then we had fun repeating and exploring various more or less related stuff and generally confusing the issue ;-)

 

[MikeS]

I do 8 here in 6.22 (under virtualBox -- just checked), I get a com file that just locks up and does nothing... unusual it would work, I was always told never declare less than E... though it's been so long damned if I can remember where.

Wonder if it depends on the DOS version...

 

[deathshadow]

Wonder if it depends on the DOS version...

Testing that here it seems to be the case - I just tried the SAME version of debug in dosbox, and it builds ok at 8. Dos 3.3 on the tandy 1000 sx is a no go, but if I use the hx with it's in-rom 2.2 and the proper system disk it works fine there...

Weird part is on 6.22 and 3.3 if I say 8, I get 10 with two nop's at the start... the 8 byte version from the systems where it works also runs fine... why would debug be putting two nops at the start, and even stranger what would make a nop hang the system? 0x90 is a nop, right?

 

[wiwa64]

... Invoke would in-turn execute reply, wait until it terminates and then display the result code (aka error code) returned by reply.

that's pretty well what command /z does, but as noted it's not available in all versions of ms-dos.

Well that's exacly why Invoke exists
It is supposed to work even under those incarnations of DOS that do not provide "command /z"

 

[MikeS]

Well that's exacly why Invoke exists
It is supposed to work even under those incarnations of DOS that do not provide "command /z"

indeed... Misunderstandings galore... ;-)

I didn't mean to suggest that COMMAND /z was better or even as good as your INVOKE (unless he's using DOS7, in which case it's already built in); since the /z option is not well known or documented I was just answering AO's question about what COMMAND /z actually does and reiterating that unlike INVOKE it only works in DOS 7.x AFAIK. I did remind him about INVOKE in post #19...

Thanks for those utilities BTW; I do have them (as well as a couple from BTTR) but until you mentioned it I'd forgotten about INVOKE.

 

[Krille]

Testing that here it seems to be the case - I just tried the SAME version of debug in dosbox, and it builds ok at 8. Dos 3.3 on the tandy 1000 sx is a no go, but if I use the hx with it's in-rom 2.2 and the proper system disk it works fine there...

Weird part is on 6.22 and 3.3 if I say 8, I get 10 with two nop's at the start... the 8 byte version from the systems where it works also runs fine... why would debug be putting two nops at the start, and even stranger what would make a nop hang the system? 0x90 is a nop, right?

Yeah, that's a NOP. And my guess is that you have a virus. Afaik, the minimum file size for a .com is 1 byte (the size of a single RET instruction).

 

[Agent Orange]

My DOS Menu System is now updated to include the F11 & F12 keys as well as the HOME key. It has been tested on MS-DOS 6.22 and seems to work okay. The below is a a sample that I call MAINMENU.BAT:

[mainmenu.bat]
echo off
:START
cls
cd \menu
type mainmenu.doc
nocurs
:GET_RPLY
reply
if errorlevel 135 goto GET_RPLY
if errorlevel 134 goto F12
if errorlevel 133 goto F11
if errorlevel 71 goto HOME
if errorlevel 68 goto F10
if errorlevel 67 goto F9
if errorlevel 66 goto F8
if errorlevel 65 goto F7
if errorlevel 64 goto F6
if errorlevel 63 goto F5
if errorlevel 62 goto F4
if errorlevel 61 goto F3
if errorlevel 60 goto F2
if errorlevel 59 goto F1
goto GET_RPLY
:HOME
cls
c:
dir /w
:F12
cls
C:
echo on
norcurs
dir /w
:F11
cls
goto END
:F10
goto GET_RPLY
:F9
goto GET_RPLY
:F8
goto GET_RPLY
:F7
goto GET_RPLY
:F6
goto GET_RPLY
:F5
goto GET_RPLY
:F4
goto GET_RPLY
:F3
goto GET_RPLY
:F2
goto GET_RPLY
:F1
cls
normcurs
goto END
:END


reply = REPLY.COM

A>debug
-a 100
xxxx:0100 mov ah,8
xxxx:0102 int 21
xxxx:0104 cmp a1,0
xxxx:0106 jnz 10a
xxxx:0108 int 21
xxxx:010A mov, ah,4c
xxxx:010C int 21
xxxx:010E <Enter>
-r cx
CX 0000
:e
-n reply.com
-w
Writing 000E bytes
-q

nocurs=NORMCURS.COM

A>debug
-a 100
xxxx:0100 mov ah,0F
xxxx:0102 int 10
xxxx:0104 cmp a1,7
xxxx:0106 jz 10d
xxxx:0108 mov cx,607
xxxx:010B jmp 110
xxxx:010D mov cx, 0b0c
xxxx:0110 mov ah,1
xxxx:0112 int 10
xxxx:0114 int 20
xxxx:0116 <Enter>
-r cx
CX 0000
:16
-n normcurs.com
-w
Writing 0016 bytes
-q

nocurs=NOCURS.COM

A>debug
-a 100
xxxx:0100 mov ah,1
xxxx:0102 mov ch,20
xxxx:0104 int 10
xxxx:0106 int 20
xxxx:0108 <Enter>
-r cx
CX 0000
:8
-n nocurs.com
-w
Writing 0008 bytes
-q

REPLY.COM ID's the pressed key and holds your place.
NOCURS.COM turns the cursor off
NORMCURS.COM the cursor on

the DOC screen is up to your imagination. The following will help you get your border started:

ALT-185 = ╣
ALT-186 = ║
ALT-187 = ╗
ALT-188 = ╝
ALT-200 = ╚
ALT-201 = ╔
ALT-202 = ╩
ALT-203 = ╦
ALT-204 = ╠
ALT 205 = ═
ALT 206 = ╬

example:
╔════╗
║ F1 ║
╚════╝

prompt $e[37;44m will give you high-intensity white foreground (letters) and a blue background (screen).

Be sure to ANSI.SYS to your CONFIG.SYS [DEVICE=C:\DOS\ANSI.SYS]

Have fun!

 

[deathshadow]

I still say the biggest issue (and why I suggested gutting reply.com into something simpler) is the sheer number of false positives you'd get from this system. Not only do you have all the unescaped keycodes that will be mistaken for your function keys, the gaps in your errorlevel tests means well over half the keyboard will respond as 'home'.

Remember, "if errorlevel" is a ">=" not a "==", meaning that codes 69 and 70 will be treated as F10, all codes 72 to 132 will be treated as 'home', etc, etc... much less that again, because the 0 is discarded instead of sent, semi-colon through shift-D will be treated as F1 to F10, while pretty much every key unshifted/caps off is treated as 'home'.

That's not a good thing.

 

[Agent Orange]

I still say the biggest issue (and why I suggested gutting reply.com into something simpler) is the sheer number of false positives you'd get from this system. Not only do you have all the unescaped keycodes that will be mistaken for your function keys, the gaps in your errorlevel tests means well over half the keyboard will respond as 'home'.

Remember, "if errorlevel" is a ">=" not a "==", meaning that codes 69 and 70 will be treated as F10, all codes 72 to 132 will be treated as 'home', etc, etc... much less that again, because the 0 is discarded instead of sent, semi-colon through shift-D will be treated as F1 to F10, while pretty much every key unshifted/caps off is treated as 'home'.

That's not a good thing.

You are correct. The first step was to get it up and running, which it is at this time. I will attempt slim it it down a bit. Open to all comers, don't be bashful.