Wine 6.x

[sfjuocekr]

The newer wine versions allow things like Blitz.gg to work!

[M-Reimer]

But they don't allow LoL to work. Sorry I already tried it. Doesn't work! I'll only accept this as TESTED Pull Request!

[sfjuocekr]

I've currently got a 6.11 build going, I'm just trying to figure out what parts of the code are critical for LoL to function.

Right now Im trying to modify signal_init_early in signal_i386.c and checked if the seccomp filters were setup.

edit: I did get it to work once, but I can't reproduce it which is doing my head in for the past few hours :(

[M-Reimer]

If you are interested in my try with Wine 6.10, then you can find it here:

https://github.com/M-Reimer/wine-lol/tree/wine-6.10

TBH: For me it seems like the wine devs lost interest in LoL a bit. The bugs, I've commented on about Wine 6.10 compatibility with LoL, haven't got any further responses since months.

[sfjuocekr]

I've done the following instead, I took the wow-lol-bug patch and went path hunting to find where the new NTDLL patches have refactored the code to.

I found the function init_teb to be the most likely candidate, so I hacked the seccomp_init into it before the return teb and also added a SIGSYS error handler. Now I'm getting a stack overflow as soon as the game starts, everything else works fine it is just when you start for example the tutorial.

Now Im changing the stack size just to see where it leads me before I go tracing where it happens.

[sfjuocekr]

I'm still getting this:

0a54:err:virtual:virtual_setup_exception stack overflow 1156 bytes in thread 0a54 addr 0x7bc7bf0b stack 0x35a0b7c (0x35a0000-0x35a1000-0x36a0000)

I think this line:

(uint64_t )(tcbhead + 0x60) = (uintptr_t)(tcbhead + 0x68);

Is there to fix this overflow as the game expects this to be be earlier down the stack?

I unintentionally lied as well, I did not change virtual.c I also changed signal_i386.c more or less in the same way that you did. I initially put the code in init_teb, but moved it to signal_init_process and added the sys_handler the same way as the other handlers.

[M-Reimer]

I'm still unsure if it can be fixed at that region at all. Could also be a new bug somewhere else.

[sfjuocekr]

I'll probably try to go back to 5.6 and move up until it breaks to bisect where it breaks down.

Or my other idea was to backport the secur32 algo patches to just get the Blitz client working with 5.6.