From: "Rémi Bernon" Subject: Re: [PATCH 0/4] Update USER_SHARED_DATA timestamps more often. Message-Id: Date: Fri, 29 Nov 2019 11:40:23 +0100 In-Reply-To: <7af9d490-4bd3-b1e4-9a83-9b64aba29382@gmail.com> References: <20191129092401.8943-1-rbernon@codeweavers.com> <7af9d490-4bd3-b1e4-9a83-9b64aba29382@gmail.com> On 11/29/19 11:03 AM, Paul Gofman wrote: > On 11/29/19 12:23, Rémi Bernon wrote: >> This is a rewrite of the ntdll-User_Shared_Data staging patch series, >> with a simpler approach that still solves the issue. Although it is less >> correct in term of timestamp update than the original series, it should >> also have less impact and may be more acceptable. We already update the >> timestamps from time to time in ntoskrnl before accessing the memory, >> and this adds another update after each sleep. > > While this might allow the games to start, won't such approach break > (some of) game mechanics or sync with servers? The games might be using > this instead of GetTickCount(), having the time updated at some rare and > irregular intervals looks scary. AFAICS it's working fine although I didn't test it really deep to be honest. > I thought that somewhat potentially better approach than that currently > in Staging would be to map user shared area to wineserver and always > create a single thread in server to update the shared area. That would > be somewhat similar to what Windows does if wineserver stands for > kernel. I also heard that sharing memory with server is considered a no > go, but I could not find any discussion why is it so. > Yes, that was one of the approaches discussed in the original thread [1] and probably a more accurate way to do it. It has however some drawbacks, in addition to being much more complicated and probably having some unforeseen implications: * Creating a thread in wineserver is probably not going to be OK, as it is single threaded and should stay as such whatever the purpose is. * Regarding memory sharing, I understood from a WineConf discussion that sharing read-only memory from the server to applications would be OK generally speaking. But in this case, KUSER_SHARED_MEMORY contains some information about the emulated OS from an application perspective, and that can vary from on application to another. This would require sharing different memory regions depending on the application and updating all of them, complicating the whole thing. There are also some other fields currently written by applications and that would need to be updated by the server to keep the shared memory read-only. * Then according to [1], updating the timestamps continuously could apparently break some copy-protection schemes (SecuROM for instance) that measures the time taken by some syscalls. As Wine is not exactly doing as Windows, the syscall timings could be larger and having the timestamps not increase in this particular case allows us to pass these checks. [1] https://www.winehq.org/pipermail/wine-devel/2012-March/094788.html -- Rémi Bernon