With GitLab and the spinning off of commit messages to wine-gitlab I
think the traffic estimates on the mailing list page need to be
updated... at least for wine-devel: it no longer has 50 messages per
day.
https://www.winehq.org/forums
(unfortunately there is no unit on the little per mailing-list graph)
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Theory is where you know everything but nothing works.
Practice is where everything works but nobody knows why.
Sometimes they go hand in hand: nothing works and nobody knows why.
Folks,
As you may have noticed, we haven't been making any plans for WineConf
this year. Jeremy has been busy preparing his retirement, and I haven't
been pushing it either, mostly because I'm not convinced that we want to
continue the traditional WineConf model.
Even though we skipped a few years because of the pandemic, attendance
at last year's WineConf wasn't great. We also suggested meeting at
FOSDEM in February, like we did in previous years, but essentially no
one showed up.
So I'm wondering whether there is still enough interest for a
traditional WineConf, or whether we should try a different approach, to
maybe capture some of the recent excitement around gaming and downstream
uses of Wine in general.
I'd like to hear your thoughts. Should we do a Proton conference, or
join some kind of gaming-related event? Do people even want to travel
to conferences anymore? What kind of event would you be interested in,
particularly those of you who don't show up to the traditional WineConf?
--
Alexandre Julliard
julliard(a)winehq.org
Hi,
I've been looking to get League of Legends work in Wine.
The issue is that their Anti-Cheat hooks bunch of functions in
ntdll.dll directly by prepending `jmp their_code` before the real
function and it seems it messes something up.
Anyway, topic of this email is about handling of stack overflow.
When their exception handler gets messed up it is invoked recursively
until stack overflow.
And because it happened while it was in critical section it causes
other threads to deadlock.
My question is how such case should be handled?
When thread is killed should lock be released so other threads can
still proceed?
Or maybe just whole process should be killed if any thread has stack overflow?
To me it looks like in Windows when exception handler goes too deep
then Just in Time debugger is invoked or if that's not enabled then
process is killed with EXCEPTION_ACCESS_VIOLATION (maybe because it
tried to access beyond end of stack?)
Log looks like:
[...]
0120:trace:seh:call_handler calling handler 00006FFFFFC97030
(rec=00007F3214C54360, frame=00007F3214D4E710
context=00007F3214C538D0, dispatch=00007F3214C537A0)
0120:trace:seh:call_handler handler at 00006FFFFFC97030 returned 2
0120:trace:seh:call_stack_handlers nested exception
0120:trace:seh:call_handler calling handler 00000001413B347C
(rec=00007F3214C54360, frame=00007F3214D4F570
context=00007F3214C538D0, dispatch=00007F3214C537A0)
0120:err:virtual:virtual_setup_exception stack overflow 2576 bytes
addr 0x6ffff9e66327 stack 0x7f3214c505f0
(0x7f3214c50000-0x7f3214c51000-0x7f3214d50000)
0124:err:sync:RtlpWaitForCriticalSection section 00006FFFFFCAE4C0
"../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread
0124, blocked by 0120, retrying (60 sec)
011c:err:sync:RtlpWaitForCriticalSection section 00006FFFFFCAE4C0
"../wine/dlls/ntdll/loader.c: loader_section" wait timed out in thread
011c, blocked by 0120, retrying (60 sec)
[...]
// stuck like this
And several threads stuck like this
Thread 8 (Thread 472 "011c"):
#0 0x00006fffffc966d4 in NtWaitForAlertByThreadId () from
/opt/wine-lol-staging/lib/wine/x86_64-windows/ntdll.dll
#1 0x00006fffffc9db68 in RtlWaitOnAddress
(addr=addr@entry=0x6fffffcae4d8 <loader_section+24>,
cmp=cmp@entry=0x6fffffcbda90 <zero>, size=size@entry=4,
timeout=timeout@entry=0x7fc37b38f700) at ../wine/dlls/ntdll/sync.c:912
#2 0x00006fffffc9dd06 in wait_semaphore (timeout=<optimized out>,
crit=0x6fffffcae4c0 <loader_section>) at ../wine/dlls/ntdll/sync.c:196
#3 RtlpWaitForCriticalSection (crit=crit@entry=0x6fffffcae4c0
<loader_section>) at ../wine/dlls/ntdll/sync.c:314
#4 0x00006fffffc9df71 in RtlEnterCriticalSection
(crit=crit@entry=0x6fffffcae4c0 <loader_section>) at
../wine/dlls/ntdll/sync.c:383
#5 0x00006fffffc7667b in loader_init
(context=context@entry=0x7fc37b38fb00,
entry=entry@entry=0x7fc37b38fb80) at ../wine/dlls/ntdll/loader.c:4405
#6 0x00006fffffc9a444 in LdrInitializeThunk (context=0x7fc37b38fb00,
unk2=<optimized out>, unk3=<optimized out>, unk4=<optimized out>) at
../wine/dlls/ntdll/signal_x86_64.c:1716
#7 0x00006ffff88f7954 in ?? () from /mnt/Riot Games/League of
Legends/wine/dosdevices/s:/Riot Games/League of Legends/Game/stub.dll
Best regards,
Dāvis
Folks,
With the end of the year approaching, it's time to start preparing for
the 9.0 stable release.
We'll follow the same schedule as every year, with code freeze in early
December, and a final release sometime in January. This year, the code
freeze period will start on December 8th.
So if you have things that you'd like to see included in 9.0, make sure
to submit them soon, so that there's enough time for review before code
freeze starts.
--
Alexandre Julliard
julliard(a)winehq.org
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 8.21 (491 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
* None
Added:
* None
Updated:
* vkd3d-latest to latest.
Where can you help
* Run Steam/Battle.net/GOG/UPlay/Epic
* Test your favorite game.
* Test your favorite applications.
* Improve staging patches and get them accepted upstream.
* Suggest patches to be included in staging.
As always, if you find a bug, please report it via
https://bugs.winehq.org
Best Regards
Alistair.
Hello wine-devel,
I wanted to follow up on the discussion on https://gitlab.winehq.org/wine/
wine/-/merge_requests/3059
For those not in the loop: The question came up what GCC version is the oldest
supported one, and which language features can't be used in Wine.
Is there already a wiki entry on this?
Associated bug report:
https://bugs.winehq.org/show_bug.cgi?id=54601 (Compilation fails with gcc
4.3.4 (error: unknown field ‘Type’ specified in initializer)
I have a bunch of gcc 4.3 patches, and if it's supported, I think it would be
useful getting those in before the next stable.
Although ongoing gcc 4.3 support is probably a bit of work, since most people
don't test against gcc 4.3 compatibility so there's some "regressions" from
time to time.
An option would be to just patch it when someone complains, which would be the
most reasonable to me. Or just cap it at 4.8 which currently works. In the
end, some compiler will be too old, so where is the line?
In a similar vein, what about
https://bugs.winehq.org/show_bug.cgi?id=20474 (Wine can't be built with GCC in
C99 mode)
Is this a supported setup? IMHO itwould be too much effort work to get this
working, but I don't make the decisions.
Regards,
Fabian Maurer
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 8.20 (493 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
* winemenubuilder: Create .desktop files for programs that open URIs.
* winecfg: Mention protocol associations.
Added:
* None
Updated:
* vkd3d-latest to latest.
Where can you help
* Run Steam/Battle.net/GOG/UPlay/Epic
* Test your favorite game.
* Test your favorite applications.
* Improve staging patches and get them accepted upstream.
* Suggest patches to be included in staging.
As always, if you find a bug, please report it via
https://bugs.winehq.org
Best Regards
Alistair.
Hi all,
The planned release for vkd3d 1.10 is about 4 weeks away. As usual, that
means the development branch will become increasingly frozen as we're
nearing release.
If you're an upstream vkd3d developer, please do the following:
- Keep an eye on Bugzilla for any reported regressions.
- Review any API changes since the previous release.
- Verify all the vkd3d tests pass on your hardware, and please send
fixes if they don't.
- Review and improve the documentation.
- Apply your best judgment about which patches are appropriate for the
current stage of the release process.
If you're a downstream user of vkd3d, please test your applications for
regressions, and file bug reports if you find any. If you're the
maintainer of a Wine module that (indirectly) depends on vkd3d, like
e.g. d2d1, d3dx9, d3dcompiler, or any of the core Direct3D modules, that
includes making sure the unit tests still pass with the new version.
The planned release date for the release following vkd3d 1.10 is
currently sometime in March.
Regards,
Henri
