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.
context: https://bugs.winehq.org/show_bug.cgi?id=55897
While implementing CopyFile2, I noticed that CopyFileEx does not respect the progress callback and never calls it. The tests too assume that it will not be invoked other than in the case of a file having multiple streams, which is not something that Wine supports.
There seem to have been multiple efforts to implement this functionality (in 2022 and 2013) but I can't tell find any reasoning for why they were not successful. Would implementing this be a desirable contribution?
I don't know how to get assigned to an issue on Bugzilla. I read the Wine Developers Wiki but it doesn't seem to have the information, so I left a comment in the bug log itself.
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 All,
Now that vkd3d 1.10 is out, I have a request for developers.
Would it be possible to include a file of all games/applications that
have fixes when they are committed. It's too hard to track unless you
really doing serious work with it.
The whole concept of including the latest vk3d3d in staging was to help
with testing but if people don't know what to test, they wont.
This would also, give a nice section in the ANNOUNCE as to what now
works. :)
Best Regards
Alistair
Hello all,
There is a Windows 98 program, a game called Nuclear Strike, which wants to do
some amount of direct VGA access. Part of this is port I/O, which naturally
throws SIGILL that we can trivially catch and emulate in Wine. The other part
is direct access to the video memory at 0xa0000, which in general isn't a
problem to catch and virtualize as well.
However, this program is a bit creative about how it accesses that memory;
instead of just writing to 0xa0000 directly, it looks up a segment descriptor
whose base is at 0xa0000 and then uses the %es override to write bytes. In
pseudo-C, what it does is:
int get_vga_selector()
{
sgdt(&gdt_size, &gdt_ptr);
sldt(&ldt_segment);
++gdt_size;
descriptor = gdt_ptr;
while (descriptor->base != 0xa0000)
{
++descriptor;
gdt_size -= sizeof(*descriptor);
if (!gdt_size)
break;
}
if (gdt_size)
return (descriptor - gdt_ptr) << 3;
descriptor = gdt_ptr[ldt_segment >> 3]->base;
ldt_size = gdt_ptr[ldt_segment >> 3]->limit + 1;
while (descriptor->base != 0xa0000)
{
++descriptor;
ldt_size -= sizeof(*descriptor);
if (!ldt_size)
break;
}
if (ldt_size)
return (descriptor - ldt_ptr) << 3;
return 0;
}
Currently we emulate IDT access. On a read fault, we execute sidt ourselves,
check if the read address falls within the IDT, and return some dummy data
from the exception handler if it does [1]. We can easily enough implement GDT
access as well this way, and there is even an out-of-tree patch written some
years ago that does this, and helps the game run.
However, there are two problems that I have observed or anticipated:
(1) On systems with UMIP, the kernel emulates sgdt instructions and returns a
consistent address which we can guarantee is invalid. However, it also returns
a size of zero. The program doesn't expect this (cf. the way the loop is
written above) and I believe will effectively loop forever in that case, or
until it finds the VGA selector or hits invalid memory.
I see two obvious ways to fix this: either adjust the size of the fake
kernel GDT, or provide a switch to stop emulating and let Wine handle it. The
latter may very well a more sustainable option in the long term (although I'll
admit I can't immediately come up with a reason why, other than "we might need
to raise the size yet again".)
Does anyone have opinions on this particular topic? I can look into
writing a patch but I'm not sure what the best approach is.
(2) On 64-bit systems without UMIP, sgdt returns a truncated address when in
32-bit mode. This truncated address in practice might point anywhere in the
address space, including to valid memory.
In order to fix this, we would need the kernel to guarantee that the GDT
base points to an address whose bottom 32 bits we can guarantee are
inaccessible. This is relatively easy to achieve ourselves by simply mapping
those pages as noaccess, but it also means that those pages can't overlap
something we need; we already go to pains to make sure that certain parts of
the address space are free. Broadly anything above the 2G boundary *should* be
okay though. Is this feasible?
We could also just decide we don't care about systems without UMIP, but
that seems a bit unfortunate; it's not that old of a feature. But I also have
no idea how hard it would be to make this kind of a guarantee on the kernel
side.
This is also, theoretically, a problem for the IDT, except that on the
machines I've tested, the IDT is always at 0xfffffe0000000000. That's not
great either (it's certainly caused some weirdness and confusion when
debugging, when we unexpectedly catch an unrelated null pointer access) but it
seems to work in practice.
--Zeb
[1] https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/
instr.c#l702
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
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 9.0-rc3 (498 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
* None
Added:
* None
Updated:
* None
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.
Binary packages for various distributions will be available from:
https://www.winehq.org/download
Summary since last release
* Rebased to current wine 9.0-rc2 (498 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
* None
Added:
* [45455] setupapi: Add stub for DriverStoreFindDriverPackageW.
* [55282] where: Implement search with default options.
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.
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 9.0-rc1 (493 patches are applied to wine vanilla)
Upstreamed (Either directly from staging or fixed with a similar patch).
* bcrypt: Allow multiple backends to coexist.
* bcrypt: Implement BCryptSecretAgreement with libgcrypt.
* bcrypt: Implement BCRYPT_KDF_HASH.
Added:
* None
Updated:
* vkd3d-latest to latest.
* ntdll-DOS_Attributes
* mfplat-streaming-support
* ntdll-ForceBottomUpAlloc
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.