You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm guessing this is already something you guys know about and is a thorn in your side, but I wanted to start the discussion:
What are your plans for eliminating call_unsafe_wdf_function_binding (and friends)?
Context for the uninitiated: this macro exists because WDF exposes all of its APIs via a function table.
For example, here is the implementation for WdfDriverCreate. You'll note that it calls the function at WdfFunctions[WdfDriverCreateTableIndex].
This appears to be the same for all the APIs in WDF.
Some spitball ideas:
Enumerate WDFFUNCENUM at build-time in wdk-sys and generate a stub for each entry with a signature that matches the equivalent C function stub.
Maybe poke through the Windows metadata? Not even sure if these functions are exposed here.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm guessing this is already something you guys know about and is a thorn in your side, but I wanted to start the discussion:
What are your plans for eliminating
call_unsafe_wdf_function_binding
(and friends)?Context for the uninitiated: this macro exists because WDF exposes all of its APIs via a function table.
For example, here is the implementation for WdfDriverCreate. You'll note that it calls the function at
WdfFunctions[WdfDriverCreateTableIndex]
.This appears to be the same for all the APIs in WDF.
Some spitball ideas:
WDFFUNCENUM
at build-time inwdk-sys
and generate a stub for each entry with a signature that matches the equivalent C function stub.Beta Was this translation helpful? Give feedback.
All reactions