ntdll: Don't modify LockCount in RtlLeaveCriticalSection if section is not acquired.

Alexandre Julliard julliard at winehq.org
Fri Mar 3 12:57:07 CST 2017


Sebastian Lackner <sebastian at fds-team.de> writes:

> On 03.03.2017 19:30, Jacek Caban wrote:
>> On 03.03.2017 19:13, Sebastian Lackner wrote:
>>> On 03.03.2017 18:48, Jacek Caban wrote:
>>>> Signed-off-by: Jacek Caban <jacek at codeweavers.com>
>>>> @@ -151,6 +154,9 @@ static void InitFunctionPtrs(void)
>>>>          pRtlIsCriticalSectionLocked = (void *)GetProcAddress(hntdll, "RtlIsCriticalSectionLocked");
>>>>          pRtlIsCriticalSectionLockedByThread = (void *)GetProcAddress(hntdll, "RtlIsCriticalSectionLockedByThread");
>>>>          pRtlInitializeCriticalSectionEx = (void *)GetProcAddress(hntdll, "RtlInitializeCriticalSectionEx");
>>>> +        pRtlInitializeCriticalSection = (void *)GetProcAddress(hntdll, "RtlInitializeCriticalSection");
>>>> +        pRtlEnterCriticalSection = (void *)GetProcAddress(hntdll, "RtlEnterCriticalSection");
>>>> +        pRtlLeaveCriticalSection = (void *)GetProcAddress(hntdll, "RtlLeaveCriticalSection");
>>> Those functions should not require dynamic loading. The *Ex function is only
>>> loaded dynamically because it was introduced in later Windows versions.
>> 
>> Hmm, sure, I may change it. But what's the convention here? Given that
>> basic functions such as NtReadFile are loaded dynamically, I was under
>> an impression that we want to load dynamically all functions from ntdll.
>> Now I see it's not the case for other functions. I recall considering to
>> change that, but I think Alexandre preferred it that way (I'm not sure
>> about that, I may remember it wrong).
>
> When we still had a Windows 2000 testbot VM it was required, but I think
> it is obsolete now and can be removed. Alexandre might know better if
> there is any other reason why we should keep it.

The reason was not because the functions may be missing, but because the
PSDK didn't have an ntdll import library, so we couldn't import anything
from ntdll if we wanted to support building against the PSDK.

It seems the latest PSDK now has an import library, so we can probably
stop worrying about that case.

-- 
Alexandre Julliard
julliard at winehq.org



More information about the wine-devel mailing list