[PATCH v2 3/5] ntoskrnl.exe/tests: Add some pending / remove tests.

Zebediah Figura (she/her) zfigura at codeweavers.com
Tue Jun 29 15:46:41 CDT 2021


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.



More information about the wine-devel mailing list