Some of you may have noticed that I am converting a DOS program to WIN32, I have now got to a piece of code that I need a bit of help on. For those of you who haven't done any 'low level' programming I'll explain The mechanics involved.
Down at the bottom of memory is the keyboard buffer, this takes the form of a circular Queue, it has a head pointer & a tail pointer and when these are equal it means the buffer is empty. When a key is pressed the keyboard interrupt inserts the character into this buffer and increments the head pointer and when a character is removed from the buffer the tail pointer is incremented. So within my program I check the head & tail pointer to see whether a keypress has taken place, but I do this from the timer interrupt. Within the timer interrupt is another interrupt usually referred to as TIMER TICK, this points to an IRET instructon and so does nothing. This interrupt can be made to point at a block of your own code, and thus gets executed approximately 18.2 times per second. This piece of code (in my program) checks the aforementioned head & tail pointers in the keyboard buffer, and if a keypress is present it sets a flag which I check once through the loop of my program code, if this flag is set it means a keypress is present and the program acts apon it accordingly. Now what I want to Know is how to implement something that will do a similiar task in WIN32,
Posted on 2001-08-18 09:26:25 by Mel
i would say: it depends. If your new win32 app is a GUI app, you will be notified of key strikes by WM_KEYDOWN messages. But of course, you can also install a Timer proc and in that proc call GetKeyboardState(). May be PeekConsoleInput() is also acceptable. Or DirectInput?

Posted on 2001-08-18 10:07:55 by japheth
Thanks japheth,
The program is a gui, but I don't want to return to the main message loop before my block of code has finished executing, unless the cancel button is pressed of course. Setting a timer looks interesting and as I am looking for one key in particular maybe GetKeyState would be appropriate, anyway I'll look into it,
Posted on 2001-08-18 10:20:31 by Mel
I've had a look at setting a timer and it seems that you can only process the WM_TIMER message in WindowProc, which isn't what I wanted to do,
Posted on 2001-08-18 10:33:36 by Mel
Have a look at Winmm timer. This one have a CallBack from which
you will do what you want:

; Run the Timer:

>call 'WINMM.timeSetEvent' D$_Period 10 TimerProc 0 &TIME_PERIODIC
>mov D$_TimerID eax

; Timer CallBack:

>Proc TimerProc:
> Arguments @ID, @Message, @UserValue, @wParam, @lParam
> ; What you want

For details, have a search in mmedia.hlp. If you don't have it: (Help Files section).

Posted on 2001-08-18 10:53:56 by Betov
By the way if anyone is wondering what the DOS program is, it's a LOTTERY Manager program for the U.K.Lottery. This was written about 6+ years ago and has been refined over the years. If anyone is interested in it I shall be happy to post it up here. It has too many features to list here, but be assured it does practically everything, including a prediction(not to be taken too seriously)> Source code is also available if anyone is interested.
Posted on 2001-08-18 10:54:20 by Mel
Thanks betov,
That looks like exactly what I wan't to do, I'm still looking at it,
Posted on 2001-08-18 11:24:15 by Mel
You could also have a look at multithreading. Multithreading is nice,
yum yum. Synchronization can be a bit bitchy though.

How come you don't want to handle your code in wndproc, btw? Because
it's time intensive and bogs down the GUI? Then multithreading
probably *is* the answer :).
Posted on 2001-08-18 11:38:53 by f0dder
I've had a good look at it betov, and it's perfect for what I wan't to do ,
Many thanks:alright:
Posted on 2001-08-18 11:39:52 by Mel
I better explain what I am doing f0dder,
my code generates a set of random numbers from a predefined range. It does this by cycling through the numbers and stops when a keyboard interrupt occurs, that number is removed and the code continues until I have a set. I find that the difference in speed of the running code and that of the keyboard interrupt gives a true random set, much better than a pseudo random number generator which has a mathematical connection with the previous,
Posted on 2001-08-18 11:50:59 by Mel
Mel, wouldn't the randomness be determined by what other code is running? I would think that fresh boots would lead to similar sets. I may be wrong - we all know how windows has a life of it's own. :)
Posted on 2001-08-18 13:05:27 by bitRAKE
bitRAKE I tested the program pretty thoroughly including holding a key down before running the code and I couldn't duplicate any results, in fact you can hold the key (spacebar) down all the time and the results are always different,
Posted on 2001-08-19 03:27:47 by Mel
mel, you can achieve results like that with any good pseudo-random
number generator (yeah, pseudo. Don't be fooled to think ANYTHING
in computers are random, except perhaps windows crashes).
A PRNG has an advantage over your method, though. If you use the
same randseed, you are able to reproduce the sequence of random
numbers, which can be very very very :) nice in some situations.
Posted on 2001-08-19 05:43:06 by f0dder