3940
|
|
|
James Teh |
13 years ago
|
|
|
3939
|
|
|
James Teh |
13 years ago
|
|
|
3938
|
|
|
James Teh |
13 years ago
|
|
|
3937
|
|
|
James Teh |
13 years ago
|
|
|
3936
|
|
|
Peter Vágner |
13 years ago
|
|
|
3935
|
|
|
Michael Curran |
13 years ago
|
|
|
3934
|
|
|
James Teh |
13 years ago
|
|
|
3933
|
|
|
James Teh |
13 years ago
|
|
|
3932
|
|
|
James Teh |
13 years ago
|
|
|
3931
|
|
|
James Teh |
13 years ago
|
|
|
3930
|
|
|
James Teh |
13 years ago
|
|
|
3929
|
|
|
James Teh |
13 years ago
|
|
|
3928
|
|
|
James Teh |
13 years ago
|
|
|
3927
|
|
|
James Teh |
13 years ago
|
|
|
3926
|
|
|
James Teh |
13 years ago
|
|
|
3925
|
|
|
James Teh |
13 years ago
|
|
|
3924
|
|
|
Michael Curran |
13 years ago
|
|
|
3923
|
|
|
Michael Curran |
13 years ago
|
|
|
3922
|
|
nvdaHelper: hook all functions using apiHook_hookFunction_safe, at the same time catching and fixing some coding errors, which may have caused, or been the future cause of, some crashes. Specific code error fixes: *ExtTextOutHelper: lpString must be const. *TextOutA and TextOutW: the return type is int, not bool (lowercase), and lpString must be const. *PolyTextOutW and PolyTextOutA: do not use our own custom WA_POLYTEXT template struct, instead make the hookClass_PolyTextOut template class take the POLYTEXTA or POLYTEXTW as its template argument rather than just char or wchar_t. Although that sort of worked in the past, for actual verification of function signatures a custom struct can't be used. *ExtTextOutA and ExtTextOutW: lpString should be const, cbCount should be UINT not int, and lpdx should be INT (uppercase) not int (lowercase).
|
Michael Curran |
13 years ago
|
|
|
3921
|
|
nvdaHelper: added a much safer way of hooking functions, that verifies the function signatures at compile time. If using apiHook_hookFunction_safe it is now impossible to use the incorrect function signiture for the real function symbol, the real function variable, or the fake function symbol. They *must* match, or else it doesn't compile. To now hook a function, do something like real_GetDesktopWindow=apiHook_hookFunction_safe("USER32",GetDesktopWindow,fake_GetDesktopWindow). The only difference on the outside is that a real defined function symbol must be used as the real function name rather than a string. This does mean though that you must have the header file for the function in order to hook it. Either that or at least have defined it somewhere in the same file, though this would not be any more safer than the older method. How it works internally: apiHook_hookFunction_safe is a macro that takes 3 arguments: moduleName, realFunction and fakeFunction. apiHook_hookFunction_safe calls apiHook_hookFunction_tpl with these arguments, plus a stringified version of the realFunction argument. apiHook_hookFunction_tpl is a template function which takes a moduleName string, a realFunctionName string, a realFunction symbol, and a fakeFunction symbol. Its template argument is a typename called funcType, which it deduces from the realFunction and fakeFunction signatures, which must match. It also returns a symbol of type funcType, which again will match the other two function symbols. apiHook_hookFunction_tpl calls the original apiHook_hookFunction, hooking the function in the normal way. The macro and the template are only there for safety purposes at compile time. The only limit to this new way of hooking is that the symbol hooked in the particular module must have exactly the same name as the symbol defined in the header file. Plus a header file should be available containing this symbol you are hooking. If these limits are a problem then apiHook_hookFunction can be used directly, but when possible it is very important to use the safer version.
|
Michael Curran |
13 years ago
|
|
|