https://bugs.winehq.org/show_bug.cgi?id=47208
Bug ID: 47208 Summary: Wine-staging's "winebuild-Fake_Dlls" cause Office 2019 to say "IOPL not enabled" Product: Wine-staging Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: peathot@hotmail.com CC: leslie_alistair@hotmail.com, michael@fds-team.de, z.figura12@gmail.com Distribution: ---
Created attachment 64469 --> https://bugs.winehq.org/attachment.cgi?id=64469 Console output before the offending patch is applied
Microsoft Word 2019 (version 1904, build 11601.20204, installed via Office 365) will not start if patchset "winebuild-Fake_Dlls" is applied to wine source. A popup saying "IOPL not enabled" will appear after starting up for a while.
To be exact, the patch that causes the problem is the patch "0003-winebuild-Generate-syscall-thunks-for-ntdll-exports.patch". This is found out by applying patches with "patches/patchinstall.sh DESTDIR=../wine-source --backend=git-am --all" then doing bisect between master & staging. By checking out this patch's parent commit, Microsoft Word 2019 starts successfully. [1]
I've tried to exclude this patchset (and patchsets that depend on it) while applying patches using [2]. By doing that, Microsoft Word starts successfully.
Wine's commit is "99114803b80f6e687f1d4ed11e0808b821cdbf22", while Wine-staging's commit is "6ce73c283d4953e348ef87e237c4d29b933abadb". The OS is Xubuntu 18.04. The machine is Mac Mini early 2009 with Nvidia Geforce 9400m. The graphic stack is mesa + nouveau (i.e. Nvidia proprietary driver is not installed).
The MS Office is installed using the instructions from [3]. Also, CSMT is disabled due to nouveau's problem with multithreaded OpenGL (see #46707).
[1] However, this means all patches which appear later isn't applied yet. The exact patch application order can be seen in the attachment. [2] ./patches/patchinstall.sh DESTDIR=../wine-source/ --backend=git-am --all -W winebuild-Fake_Dlls -W ntdll-NtContinue -W ntdll-RtlCreateUserThread -W eventfd_synchronization -W server-Desktop_Refcount -W ws2_32-TransmitFile -W kernel32-K32GetPerformanceInfo [3] https://appdb.winehq.org/objectManager.php?sClass=version&iId=35527&...
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #1 from Ratchanan Srirattanamet peathot@hotmail.com --- Created attachment 64470 --> https://bugs.winehq.org/attachment.cgi?id=64470 Console out after the offending patch is applied
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #2 from Ratchanan Srirattanamet peathot@hotmail.com --- Created attachment 64471 --> https://bugs.winehq.org/attachment.cgi?id=64471 Console output when excluding offending patchsets
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- Thanks for the report, and for finding the specific patch that causes the issue. (Would that all reports against Staging were so detailed...)
This seems somewhat painful to resolve. Probably best to hold off doing anything at least until Alexandre's current push to convert DLLs to PE is done; that patch set will need to see some reworking at that point anyway.
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #4 from Ratchanan Srirattanamet peathot@hotmail.com --- Created attachment 64472 --> https://bugs.winehq.org/attachment.cgi?id=64472 Patch application order for staging patches
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #5 from Ratchanan Srirattanamet peathot@hotmail.com --- Created attachment 64473 --> https://bugs.winehq.org/attachment.cgi?id=64473 Patch application order for staging patches when excluding offending patchsets
https://bugs.winehq.org/show_bug.cgi?id=47208
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #6 from Fabian Maurer dark.shadow4@web.de --- Is Word 2019 a 32bit or a 64bit program? Maybe it also wants the thunks to be exactly the same as on windows?
Do my patches from bug 45650 respective bug 45642 on top of staging help?
https://bugs.winehq.org/show_bug.cgi?id=47208
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC| |xerox.xerox2000x@gmail.com
--- Comment #7 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Fabian Maurer from comment #6)
Is Word 2019 a 32bit or a 64bit program?
I`m guessing it must be 32-bit because the 64-bit installers of Office will run into bug 45699 ;
Anyway, just stepped in to confirm the bug
https://bugs.winehq.org/show_bug.cgi?id=47208
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #8 from Jacek Caban jacek@codeweavers.com --- Created attachment 64476 --> https://bugs.winehq.org/attachment.cgi?id=64476 hacks
I didn't try Office 2019, but Office generally hooks some ntdll functions and those hooked functions need to be used by some ntdll code like loader. With syscall patchset internal ntdll calls don't use hooked syscall thunks unless we explicitly use them. I'm attaching a diff dug out from my tree. It may help, but it probably needs porting to current tree.
https://bugs.winehq.org/show_bug.cgi?id=47208
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #9 from Fabian Maurer dark.shadow4@web.de --- Do you know why wine needs to call the hooked functions for office to work? I mean those code paths shouldn't be triggered on windows, since this is wine specific.
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #10 from Jacek Caban jacek@codeweavers.com --- Not exactly. Office uses Click2Run virtualisation, which hooks things registry or file APIs. In some cases, it redirects calls to use registries or files stored in different paths. When you want to access those on Windows, you always end up calling one of Nt* syscall wrappers. The exact details about how it's called does not matter much as long as it's a proper use (assuming that hooks handle given use case correctly, but if they don't, applications would have a problem on Windows as well; still, I caught some bugs in C2R). For example for loader it's not important if we call functions exactly the same way as Windows, but it's important that when we load a virtualised DLL, we call hooked functions to access its file so that they have a chance to do the right thing.
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #11 from Fabian Maurer dark.shadow4@web.de --- Thanks for the explanation. Is there more information you could link for the working of click2run, or did you have to reverse-engineer that yourself?
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #12 from Jacek Caban jacek@codeweavers.com --- Created attachment 64480 --> https://bugs.winehq.org/attachment.cgi?id=64480 relay trick
Those are mostly my own findings and I don't have it documented (unless Wine git log counts as a documentation, it needed quite a few fixes). C2R is not limited to Office and AFAIR there was some documentation, but it wasn't very useful from Wine perspective.
https://bugs.winehq.org/show_bug.cgi?id=47208
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #13 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- (In reply to Jacek Caban from comment #8)
Created attachment 64476 [details] hacks
I didn't try Office 2019, but Office generally hooks some ntdll functions and those hooked functions need to be used by some ntdll code like loader. With syscall patchset internal ntdll calls don't use hooked syscall thunks unless we explicitly use them. I'm attaching a diff dug out from my tree. It may help, but it probably needs porting to current tree.
Would it be worth putting into staging?
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #14 from Ratchanan Srirattanamet peathot@hotmail.com --- (In reply to Fabian Maurer from comment #6)
Is Word 2019 a 32bit or a 64bit program? Maybe it also wants the thunks to be exactly the same as on windows?
I'm sorry to forget to mention it before. Both Office 2019 and Wine is 32 bit. (I didn't even enable win64 while compiling.) Although the rest of the system is 64 bit.
Do my patches from bug 45650 respective bug 45642 on top of staging help?
I'll try the patch from bug 45650. I'm not sure which patch from bug 45642 should I apply. However, it seems to be for 64 bit, so I'll try without either.
(In reply to Jacek Caban from comment #8)
Created attachment 64476 [details] hacks
I'll try your patch after the above patch.
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #15 from Ratchanan Srirattanamet peathot@hotmail.com --- (In reply to Fabian Maurer from comment #6)
Do my patches from bug 45650 respective bug 45642 on top of staging help?
Applying the patches from both of the above bugs doesn't solve the issue.
(In reply to Jacek Caban from comment #8)
Created attachment 64476 [details] hacks
I can't apply this patch on top of recent staging.
(In reply to Jacek Caban from comment #12)
Created attachment 64480 [details] relay trick
This doesn't help either.
https://bugs.winehq.org/show_bug.cgi?id=47208
Ratchanan Srirattanamet peathot@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |peathot@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=47208
Arthur Gautier winehq@superbaloo.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@superbaloo.net
--- Comment #16 from Arthur Gautier winehq@superbaloo.net --- Created attachment 64648 --> https://bugs.winehq.org/attachment.cgi?id=64648 patch from comment8 adapted
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #17 from Arthur Gautier winehq@superbaloo.net --- (In reply to Jacek Caban from comment #8)
Created attachment 64476 [details] hacks
I didn't try Office 2019, but Office generally hooks some ntdll functions and those hooked functions need to be used by some ntdll code like loader. With syscall patchset internal ntdll calls don't use hooked syscall thunks unless we explicitly use them. I'm attaching a diff dug out from my tree. It may help, but it probably needs porting to current tree.
I tried to adapt your patch to current master of wine and wine-staging. I attached the patch in the previous comment.
It doesn't look like it's working, I still get the IOPL error. I'd be happy to dig a bit more, but I have no idea where to start from :(
https://bugs.winehq.org/show_bug.cgi?id=47208
--- Comment #18 from Jacek Caban jacek@codeweavers.com --- (In reply to Arthur Gautier from comment #17)
It doesn't look like it's working, I still get the IOPL error. I'd be happy to dig a bit more, but I have no idea where to start from :(
If you apply .reg file from comment 12, you should be able to use +relay on the installer (+relay is very invasive for this kind of hooking, so if you can't reproduce the issue with +relay enabled, you may need to extend the list of excluded APIs). +ntdll,+file,+reg,+server may also be useful. With that, look for failing ntdll calls.
https://bugs.winehq.org/show_bug.cgi?id=47208
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47208
Andrea Vai andrea.vai@unipv.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrea.vai@unipv.it