Reply to Re: Dink Smallwood v1.08 Beta 3
If you don't have an account, just leave the password field blank.
Input streams cannot be flushed. (Flushing invloves commiting buffers to disk and only works on output.) There is probably a special function provided by Windows or DirectInput to clear the input buffer
I'm a network guy and not a programmer per se, but in the real world, flushing means to purge, but committing means to keep.
In my greenness, I am assuming that the key-data enters an 'application defined' buffer, and sits there in a que until our application asks for it. Theoretically, as long as it is in que ehr buffer, we should be able to mangle it as we see fit; Altering, Deleting, etc. Of course, we would need to ensure that the data pointer remaind accurate.
Is there not a way for an application to recognize when it is no longer the active application, i.e. when Alt-Tabbing to windows? Perhaps flushing the buffer prior to losing focus and again when our Application regains focus would be sufficient.
This would not solve the repeat attack problem but should remove the errant key-data coming out of a windows session.
Just a thought,
mm
I'm a network guy and not a programmer per se, but in the real world, flushing means to purge, but committing means to keep.
In my greenness, I am assuming that the key-data enters an 'application defined' buffer, and sits there in a que until our application asks for it. Theoretically, as long as it is in que ehr buffer, we should be able to mangle it as we see fit; Altering, Deleting, etc. Of course, we would need to ensure that the data pointer remaind accurate.
Is there not a way for an application to recognize when it is no longer the active application, i.e. when Alt-Tabbing to windows? Perhaps flushing the buffer prior to losing focus and again when our Application regains focus would be sufficient.
This would not solve the repeat attack problem but should remove the errant key-data coming out of a windows session.
Just a thought,
mm
