read keyboard input b4 windows does

[KenshinHimura]

Is there a way to read the keyboard input b4 it passes thru windows and then to DOS. Maybe by using the BIOS or something. I either just want to read it or disrupt it so that it doesn't get to windows and perform functions. like the windows key or ctrl-alt-del. Any help would be great thx.

 

[CubeE101]

the closest you can get would be inp(96) aka inp(&h60)

Which reads the keyboard port...

this can get tricky...

to learn more about this, you can use a simple program like this...

Do
Locate 1rint "Scan Code: "; Inp(96)
Loop Until Inp(96) = 1

this will loop until Esc is pressed and show the current scan code on the screen...

take note of what codes it returns when you press keys, release them, and when you hold keys down while pressing other keys, and release them in different orders...

(or just do a search on Inp(96) or Inp(&h60), there are many tutorials out there...)



Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

 

[qbasicking]

Since Qbasic runs under Windows or DOS there is no way for you to read it before the OS.

 

[CubeE101]

that is why i said "the closest you can get..."

Inkey$, Input, and Input$(x) are all processed comands...
Meaning They go through Dos / Windows and Qbasic to process the output to return characters and formated data...

INP(96) reads the keyboard port directly (or very close to that)

Windows / Dos might have a hand in routing you to and from the port, but the data is unprocessed, and is rerturned MUCH faster...

However, you must then process it your self...

On the upside, It will unlock the ability to alow Multi-Key programs and know if a Key is Pressed, Held Down, and Released...

If you Want your program to pause or loop until you press a key, you can do this...
K = INP(96) 'read the current Key Status
Do
'optional code here
LOOP UNTIL INP(96) <> K 'Loop until the status changes...

The more traditional way is to use Input$(1) or Inkey$

This will Freeze your program until you press 1 key
A$ = Input$(1)

Which, is fine, if you don't want anything to happen while the program is waiting you input...

This will also Loop until a key is Pressed...
Do
'optional code here
Loop Until Inkey$<>&quot;&quot;

This is OK, and I used this method for years, but now I have a 2GHz processor, and after 5 seconds of looping with no input, the program speed slows down by approx 50% (until I move the Mouse or something) which is NOT A GOOD THING. So the solution resulted in using INP(96) to read the KB Port so you don't have to wait for QB to process the Inkey$ command (or whatever it does to slam your program speed)...

If you can't find help on INP(96) aka INP(&h60), let me know and I will provide detailed information and a few Tips to increase it's usability and improve it's performance...

Good Luck,
J S

Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

 

[qbasicking]

Yeah, reading the keyboard is as close as you can get, but as for disabling CTRL+ALT+DEL, I don't believe that you can do that.

FAQ314-4291 is a multikey routine, it uses assembly to read from the keyboard. Its a lot smoother than INP(96), but it repeats instantly without a pause, you will have to work that in yourself (if you want it).

 

[CubeE101]

My bad, I guess I didn't finish reading the whole post

To disable Crtl-Alt-Delete, etc... try the following code from...

http://www.phys.uu.nl/~bergmann/basic-faq.html#break

This is done using the ON KEY x GOSUB statement, like this:

KEY 15, CHR$(&H04) + CHR$(70) 'CTRL-BREAK
KEY 16, CHR$(&H04) + CHR$(&H08) + CHR$(83) 'CTRL-ALT-DEL
ON KEY (15) GOSUB 100
ON KEY (16) GOSUB 200

DO
  ...
LOOP

100 PRINT "CTRL-BREAK pressed."
RETURN

200 PRINT "CTRL-ALT-DEL pressed."
RETURN

------------------------------------
If that does not work... try this (same site)

Another way of disabling CTRL-BREAK is as follows:

' DISABLE CTRL-BREAK:
dim brk$(3)

' First save the current vectors:
def seg=0: for i=108 to 111: brk$(i-108)=str$(peek(i)): next       

' Then poke new interrupt vectors:
poke 108,83: poke 109,255: poke 110,0: poke 111,240: def seg       

' RESTORE CTRL-BREAK:
def seg=0: for i=108 to 111: poke i,val(brk$(i-108)): next: def seg

If all else fails, Google:
Disable Ctrl Alt Delete Qbasic

Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

 

[KenshinHimura]

So there would be know way to monitor the windows key without asm? I'm horrible at asm and the little I do know I can't put in qb because its just to confusing and time consuming to do. So reading directly from the port (INP(96))
won't monitor it either. I was thinking that windows has some kind of dll to monitor the keyboard or something. I just wanted to know if there was a way to monitor the keyboard like windows does.

 

[qbasicking]

I might be mistaking but using a DLL command would be using DOS. My multikey routine uses assembly, but the way that CubeE101 shows doesn't, that would be the thing to use.

 

[CubeE101]

Windows uses Port 96 (&H60)

That IS the keyboard input port...

And is the way the keyboard directly interfaces with rest of the computer...

The reason Qbasic's version of this is So slow compared to assembly, etc... is that QBASIC IS SLOW...

But the only way to directly acces the keyboard (for input) is Port 96 (no matter what method you use to do it...)

I believe there is a way (another port or something) to to send keys to the Keyboard buffer..., but I don't remember what they are...

Have Fun, Be Young... Code BASIC
-Josh

http://cubee.topcities.com

 

[KenshinHimura]

if that is so then why can't it read the windows key (that key that makes the start menu pop up). I mean its still a key and its gotta be giving some kind of input to the computer since windows can read it. Is it just that dos isn't formatted to read it or something?

 

[qbasicking]

I think its because that qbasic is a exe, everything that it gets goes through windows, I think that you should be able to read it, but windows will get to it first and will make the start menu come up. I bet if yo figured out which button the windows key is and you made it do something every time you hit it qbasic would react to it, but the start menu will pop up at the same time.
The multikey routine i directed you to disables every button on the keyboard (Including PRTSCRN and CTRL-BREAK) but doesn't diable any windows combinations (CTRL-ALT-DEL, ALT-TAB...), but if I wanted to make those combinations do something, I could.

 

[qbasicking]

The only way to effectivly use the windows key would be to do it under true DOS. Otherwixse every time you hit it windows would switch tasks and you would have to switch back manually, this could get very annoying.

 

[KenshinHimura]

ok thx I'll try to run in pure dos and c if it works. The thing is that when using the inp command u can hold down the windows key and it won't switch to windows, but it doesn't give you the code for it but once you let it go then it switches to the start menu. So maybe the windows key has a code for the release of the key and not the code for when you press it well I'll try it in pure dos than thx.

 

[KenshinHimura]

I tried it and it works although so does INKEY$, but I guess thats because nothing nowadays is pure dos. It's weird tho when I push the some keys it does something weird.
For exmple when I push the windows key it gives the code 92 an then it keeps changing. It alternates between 92 and 224 if you hold it down. the same thing happens with the ctrl, arrow keys, etc... And one time is sorta froze input from the keyboard. It wouldn't let me turn caps lock on and off and when I pushed a key it qbasic would read it as a different key. Then one time it held shift down even though i was pushing it. I thought all that was pretty odd, but at least I know how to read the windows key. I just gotta kill windows cause it doesn't deserve to live and run in pure dos cause windows is pure evil. But a lot weird things hapenned in pure dos

 

[KenshinHimura]

I found out why in alternates the scan codes (I think....). On the original keyboard there wasn't as many keys as there is now. There was just nough for 255 key with key presses and key releases. Well when the new keys were developed there were not enough scan codes left (I guess they could've changed the format but they wanted to keep it 255 since that #s cool). Well when adding the right ctrl and alt key, as well as the home, end keys, and basically all the new keys nowadays. When a key is pressed it gives the scancode then it switches to the identifer of that key or something. So that was there solution too all the new keys that were made and are going to be made (of course I'm not sure). Like the new media keys and junk they have. I think windows disguises the alternating scancodes while your in the windows environment (isn't windows annoying? since its always hiding the truth), but if you run in pure dos and use inp(96) and hold down the keys that were &quot;newly&quot; developed you'll see that there code switches alternately between some other scancode. You can use the INKEY$ as well, but it is less evident that it is switching. That is my theory based on all the jnk I found out, but heck I'm prolly wrong cause I'm wrong about most things.

&quot;Quotes are cool because they're all quote-like&quot; My quote

 

[KenshinHimura]

What about interrupt 9? Doesn't that have something to do with getting the keyboard input?