On 6/29/21 3:43 PM, Rémi Bernon wrote:
On 6/29/21 10:25 PM, Zebediah Figura (she/her) wrote:
On 6/29/21 3:14 PM, Rémi Bernon wrote:
On 6/29/21 7:10 PM, Zebediah Figura (she/her) wrote:
This causes failures on my 64-bit Windows 7 VM; apparently KeInitializeSpinLock isn't actually exported from ntoskrnl until Windows 8.
I'm surprised that Marvin didn't report any failure. Should I then initialize the spinlock with 0?
I believe Marvin didn't report any failure because the only 64-bit machine that can run tests is the one with test-signing enabled, which runs Windows 10. But I still usually use my Windows 7 machine (which also has test-signing enabled) for all the tests and I'd appreciate being able to continue doing that ;-)
Windows conditionally (and the condition is big and terrible) defines KeInitializeSpinLock as an inline function. I think it'd be reasonable for us to do that unconditionally.
I'm not sure how to do that properly. It still needs to be exported, so a static FORCEINLINE version in the header will conflict with the one in ntoskrnl.exe.
I can add something like that to the header, and #undef in ntoskrnl.exe:
void WINAPI KeInitializeSpinLock(KSPIN_LOCK*); #define KeInitializeSpinLock( lock ) ((void)(*lock = 0))
Is that acceptable? Should it be guarded? I'm not sure if __WINESRC__ is there when building samples (especially the drivers).
The usual way to deal with this is to add a prefix to the exported function, e.g. NTOSKRNL_InterlockedCompareExchange.