DINPUT: Enforce single mouse acquire

[Alex Villací­s Lasso]

Dmitry Timoshkov wrote:
> On Wed, 2006-01-25 at 17:55 -0500, Alex Villací­s Lasso wrote:
>
>   
>> The problem is that if (This == NULL), then This->hook cannot be 
>> evaluated (for CallNextHookEx) without generating a segmentation fault. 
>> This is the very situation the patch is trying to prevent.
>>     
>
> Sorry for not spotting it earlier. 'This' can't be NULL, that's an
> impossible situation. You need to debug it and find out why hook
> proc is being called without This->hook being set.
>
>   
I already did. The scenario is as follows:
1) Start Fate/Stay Night (current_lock starts as NULL)
2) Mouse gets acquired (current_lock becomes valid), and mouse function 
gets hooked
3) User selects About dialog.
3) About dialog attempts a second (nested) mouse acquire, which (before 
my patch) succeeds because there is no check on whether current_lock is 
already set. Again, current_lock is assigned (overwriting the previous 
value), and the mouse function gets hooked (again). Notice that the 
mouse function is now hooked twice.
4) User dismisses the About dialog. Second acquire is released. The 
current_lock pointer gets set to NULL, and the second instance of the 
mouse function gets unhooked, but the first instance (the one hooked at 
program startup) remains hooked, now with current_lock == NULL.
5) Mouse event happens. Function hook gets called, and tries to use the 
NULL pointer. Instant segmentation fault.

The easiest way out of this (the one the patch implements) is to 
disallow nested acquires. It is a little more complicated if DirectInput 
actually requires support for nested acquires (why? I have only one 
mouse...)

Alex Villacís Lasso