在 2023/10/31 08:06, Jacek Caban 写道:
I find the claim that it's fine to wait for longer to be questionable. GetTickCount's value may be
off by up to 16 ms, so the way elapsed time is calculated in those helpers may be off by up to 32
ms. I guess that precise waits matter mostly for short timeouts
On 30.10.2023 22:09, Martin Storsjö wrote:
On Mon, 30 Oct 2023, Jacek Caban wrote:
GetTickCount64 is used only for _pthread_wait_for_*_objects wrappers,
where the timeout is 32-bit anyway, so it should be possible to use
GetTickCount unconditionally and avoid the whole problem. It would
need
On Mon, Oct 30, 2023 at 9:54 PM Jacek Caban via Mingw-w64-public
wrote:
> However, looking at _pthread_wait_for_*_objects helpers, I'd argue that
> they don't make sense in the first. The comment claims that system
> functions have poor accuracy and then uses a function with the same
> accuracy to
On Mon, 30 Oct 2023, Jacek Caban wrote:
GetTickCount64 is used only for _pthread_wait_for_*_objects wrappers, where
the timeout is 32-bit anyway, so it should be possible to use GetTickCount
unconditionally and avoid the whole problem. It would need a bit of overflow
handling, but nothing too
On 30.10.2023 16:39, Martin Storsjö wrote:
On Mon, 30 Oct 2023, LIU Hao wrote:
在 2023-10-30 18:54, Martin Storsjö 写道:
FWIW, this is what we already had before
cb7f42e05b94cbb1d94edcebdbfb47b652a45484; we used GetTickCount64
unconditionally if _WIN32_WINNT was set to target vista or above.
S
On Mon, 30 Oct 2023, LIU Hao wrote:
在 2023-10-30 18:54, Martin Storsjö 写道:
FWIW, this is what we already had before
cb7f42e05b94cbb1d94edcebdbfb47b652a45484; we used GetTickCount64
unconditionally if _WIN32_WINNT was set to target vista or above.
Since f3c53a51df5c08f181e13a39b1cd6fd1d41edb9
在 2023-10-30 18:54, Martin Storsjö 写道:
FWIW, this is what we already had before cb7f42e05b94cbb1d94edcebdbfb47b652a45484; we used
GetTickCount64 unconditionally if _WIN32_WINNT was set to target vista or above.
Since f3c53a51df5c08f181e13a39b1cd6fd1d41edb96, our default _WIN32_WINNT is set to t
Well, I'll be leavinig this to your guys' capable hands.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
On Mon, 30 Oct 2023, LIU Hao wrote:
在 2023/10/30 18:25, Ozkan Sezer 写道:
I have no idea about store apps, sorry.
However, maybe something like the following can be done. (Not even
compile-tested, and don't know whether it's correct - just showing
the idea. Someone more familiar with winstrore
On Mon, 30 Oct 2023, Ozkan Sezer wrote:
On 10/30/23, Ozkan Sezer wrote:
On 10/30/23, Jeremy Drake via Mingw-w64-public
wrote:
On Tue, 24 Oct 2023, Ozkan Sezer wrote:
LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway.
How does this play out with winstore apps using
在 2023/10/30 18:25, Ozkan Sezer 写道:
I have no idea about store apps, sorry.
However, maybe something like the following can be done. (Not even
compile-tested, and don't know whether it's correct - just showing
the idea. Someone more familiar with winstrore should mess with it
And also note that
On 10/30/23, Ozkan Sezer wrote:
> On 10/30/23, Jeremy Drake via Mingw-w64-public
> wrote:
>> On Tue, 24 Oct 2023, Ozkan Sezer wrote:
>>
>>> LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway.
>>
>>
>> How does this play out with winstore apps using winstorecompat? It seems
>
On 10/30/23, Jeremy Drake via Mingw-w64-public
wrote:
> On Tue, 24 Oct 2023, Ozkan Sezer wrote:
>
>> LoadLibrary needs cleaning after, and we do link to kernel32.dll anyway.
>
>
> How does this play out with winstore apps using winstorecompat? It seems
> that GetModuleHandle in winstorecompat alw
13 matches
Mail list logo
