DOS ain't dead

RayeR complained that under WinXP does not work the keyboard input in Blocek 1.73.
I found that it is true.
For now please try this exacutable.

What is wrong?
I made a change in the non-rezident part of the keyboard handler. Previous versions used the INT 21h/AH=07h for getting the ASCII value from keyboard.

Later I changed to INT 21h/AH=06h/DL=255 because it worked much better for key combinations like CTRL-ALT-arrow.

Do you have some idea in you look at the code below?


(*  {WORKS NICE BUT NOT UNDER WIN XP}
mov bh,255
@again:
   mov ax,0600h
   mov dl,0ffh
   inc bh       {in the first pass changes to 0, then to 1}
   int 21h
jz @nochar      {RBIL says that if the char is not ready, then AL=0 and ZF=1}
   cmp al,0
   jz @again
@nochar:
   mov ah,bh
   mov dos_ascii,ax
*)

{WORKS UNDER WIN XP BUT HAS PROBLEM WITH SOME KEY COMBINATIONS}
mov AX,$0700
   int $21     
   or AL,AL      {here ekvivalent to "cmp al,0"}
   jnz @haveit {AL<>0? We are done, go to end}
   int $21       {AL=0? call INT once again (in AH is stil $07)}
   mov AH,1      {store 1 to AH (marker for extended key)}
   jmp @finished    {done}
@haveit:
   xor AH,AH     {AH=0 (normal, not extended key)}
@finished:
mov dos_ascii,ax



---
DOS-u-akbar!

> RayeR complained that under WinXP does not work the keyboard input in
> Blocek 1.73.
> I found that it is true.
> For now please try this
> exacutable.
>
> What is wrong?

I don't know what you mean by "does not work" but I know one oddity that relates to keyboard handling in the same environment...

If your DOS program is checking for keyboard input too often (via BIOS or DOS service interrupt) in a loop while also trying to do something useful in that same loop, Windows may decide that the program isn't doing anything else but waiting. Windows will then stop executing the program until there's keyboard input available. This will appear as if the program is hung.

One possible way of fixing this is installing a chained ISR on the keyboard interrupt to set a global variable/flag to 1. Then the loop should look at the global variable/flag instead of calling the BIOS/DOS to see if there's any input. If the program sees the flag as non-zero, it should clear it to let the ISR set it to 1 again.

Alex

It seems that WinXP sets differently the ZF flag in case when INT 21h/06h is called for second time to get the code for extended key.


   mov bh,0
   mov ax,0600h
   mov dl,0ffh
   int 21h
jz @nochar      {RBIL says that if the char is not ready, then AL=0 and ZF=1}
   cmp al,0
   jnz @nochar

   int 21h
   inc bh
@nochar:
   mov ah,bh
   mov dos_ascii,ax


The new executable is here.

But still it is not perfect. Under WinXP does not work correctly the key combinations like CTRL+arrow. But under DOS and under Win98 it works fine.

---
DOS-u-akbar!

I tried both exe and F-keys now seems to be handled OK.
BTW what shortcut is used for copy&paste? Neither ctrl+c/v nor ctrl/shift+int works

Problems that persists:
mouse wheel scrolling - even under DOS
crash at open file via F3 - only under NTVDM

---
DOS gives me freedom to unlimited HW access.

> I tried both exe and F-keys now seems to be handled OK.
> BTW what shortcut is used for copy&paste? Neither ctrl+c/v nor
> ctrl/shift+int works
>
> Problems that persists:
> mouse wheel scrolling - even under DOS
> crash at open file via F3 - only under NTVDM


Yes, I know. The mouse wheel scrolling does not work now. The reason is that usualy I use Win98 for development which has not the mouse wheel API for DOS. But yes, in next version it will be fixed. It should not be hard.

However I do not understand the crash with open file via F3.
It happens only by pressing F3 or also using mouse and the upper menu?
I can not reproduce this bug.

BTW - the editor Kasmar which I have on the same www site like Blocek also suffers by this bug? They share some code...

For Copy and paste use the CTRL-[1-7] for copying and ALT [1-7] for pasting.
(Inspired by Command and Conquer game)

---
DOS-u-akbar!

> However I do not understand the crash with open file via F3.
> It happens only by pressing F3 or also using mouse and the upper menu?
> I can not reproduce this bug.

It crashes after selecting any file from open dialog but when filename is passed from command line it opens. You may add some debug output to open chain to see where it dies. BTW Zyzzle also reported similar issues in thread below, I think...

---
DOS gives me freedom to unlimited HW access.