September 2024 - Wine-Devel

Re: ntdll WRITECOPY dropped from staging

by Zhiyi Zhang

Hi Fabian, It should be done with userfaultfd. I have a WIP branch at https://gitlab.winehq.org/zhiyi/wine/-/tree/bug-23670-implement-write-copy-…. The writecopy part is working. However, the performance impact is a concern. Some games call |VirtualQuery() tens of thousands of times and any slowdown makes these games stutter. Also, Paul mentioned that we should implement making shared pages private and make it work alongside PAGE_WRITECOPY so that it's both correct feature wise and performance wise. It needs more work. As for why not using signals to track page faults for implementing WRITECOPY. There are a few issues with that approach. First, it's too slow. Second, signals may be blocked. | Best Regards, Zhiyi On 9/29/24 01:55, Fabian Maurer wrote: > Hello, > > I noticed that the ntdll WRITECOPY changes got mostly dropped from staging in > commit https://github.com/wine-staging/wine-staging/commit/ > 16dce521242b3f4a52cd2c8799ce6fe464fac83c > >> The current state even after multiple iterations, the whole >> WRITECOPY implemenet needs differently. Upstream will need to >> do this. > As I understand it, the implementation marks WRITECOPY pages as read-only on > the unix side, handling the access violation and marking it as read-write > afterwards. (Correct me if I'm wrong) > > What is wrong with the underlying concept, how should it be implemented > properly? > > Regards, > Fabian Maurer > > > > >

Sept. 29, 2024

ntdll WRITECOPY dropped from staging

by Fabian Maurer

Hello, I noticed that the ntdll WRITECOPY changes got mostly dropped from staging in commit https://github.com/wine-staging/wine-staging/commit/ 16dce521242b3f4a52cd2c8799ce6fe464fac83c > The current state even after multiple iterations, the whole > WRITECOPY implemenet needs differently. Upstream will need to > do this. As I understand it, the implementation marks WRITECOPY pages as read-only on the unix side, handling the access violation and marking it as read-write afterwards. (Correct me if I'm wrong) What is wrong with the underlying concept, how should it be implemented properly? Regards, Fabian Maurer

Sept. 28, 2024

Re: Carry flag state after a system function call

by Paul Gofman

On 9/25/24 12:27, Robert Ayrapetyan wrote: > It was a 32-bit executable of the Polish version of the Galador game > (The Prince and The Coward). > It contains wrappers around calls to kernel32 functions (e.g. _llseek). > The very last instruction in most of the wrappers is clc, but not in > all of them. One of them, wrapping _llseek, contained no clc > instruction, causing random behaviour, when different versions of wine > behaved differently depending on how the Carry flag was set based on a > side effect of a stack frame cleanup code. > At least in Windows XP it didn't work because it uses instructions > which always set the Carry flag to true in the epilog of the > SetFilePointer function. > I don't think this is something we can fix in wine, if the application > relies on the state of the Carry flag and doesn't explicitly clear it > in case of success - it's a bug of that app, > which may accidentally work in some specific Windows versions. > I can provide a patch for this particular game which NOPs JB call > after _llseek, but I don't think it's appropriate for winehq.. > If this is just one msvcrt._llseek() and the behaviour is consistent on Windows (e. g., carry flags always ends up reflecting the error status), maybe an asm wrapper for this function in msvcrt is an option?

Sept. 25, 2024

Re: Carry flag state after a system function call

by Robert Ayrapetyan

It was a 32-bit executable of the Polish version of the Galador game (The Prince and The Coward). It contains wrappers around calls to kernel32 functions (e.g. _llseek). The very last instruction in most of the wrappers is clc, but not in all of them. One of them, wrapping _llseek, contained no clc instruction, causing random behaviour, when different versions of wine behaved differently depending on how the Carry flag was set based on a side effect of a stack frame cleanup code. At least in Windows XP it didn't work because it uses instructions which always set the Carry flag to true in the epilog of the SetFilePointer function. I don't think this is something we can fix in wine, if the application relies on the state of the Carry flag and doesn't explicitly clear it in case of success - it's a bug of that app, which may accidentally work in some specific Windows versions. I can provide a patch for this particular game which NOPs JB call after _llseek, but I don't think it's appropriate for winehq.. On Wed, Sep 25, 2024 at 10:16 AM Fabian Maurer <dark.shadow4(a)web.de> wrote: > > What app is it, is it a 16bit program? > > Also, what exactly does system function call mean? Is it one affected function > or multiple? > > Does it work reliably on windows? > > IMHO it wouldn't hurt to open a bug report, be it just for others who have the > same issue. You could try to come up with a patch, either as workaround or > possibly as upstream-able change. > > Regards, > Fabian Maurer > > >

Sept. 25, 2024

Re: Carry flag state after a system function call

by Fabian Maurer

What app is it, is it a 16bit program? Also, what exactly does system function call mean? Is it one affected function or multiple? Does it work reliably on windows? IMHO it wouldn't hurt to open a bug report, be it just for others who have the same issue. You could try to come up with a patch, either as workaround or possibly as upstream-able change. Regards, Fabian Maurer

Sept. 25, 2024

Re: Carry flag state after a system function call

by robert.ayrapetyan＠gmail.com

I was not able to find any configure or CFLAGS definitions at your links... Also I thought winehq provides builds which differ from Debian official builds. However I found compile flags in the output here: https://build.opensuse.org/package/live_build_log/Emulators:Wine:Debian/win… (which is referenced from winehq). Options are similar to mine, but the stack frame cleanup code differs (lea in the manually built Wine vs sub in the packaged version), likely due to different compiler versions. It seems the old game app in question was compiled with some exotic compiler, as I found explicit "clc" instructions in all function call wrapper epilogues, except for one, which led to the issue. In any case relying on the Carry flag seems wrong since it's fragile and can be easily influenced by various compiler options. Assuming it's an app bug, closing this thread.

Sept. 24, 2024

Re: Gitlab forks limit issue

by Alexandre Julliard

robert.ayrapetyan(a)gmail.com writes: > Thanks! [If it's not intentionally hidden] Could you add this to > https://gitlab.winehq.org/wine/wine/-/wikis/Submitting-Patches? I went > through all the links from > https://gitlab.winehq.org/wine/wine/-/wikis/Developers but couldn’t > find the info you've shared above. :( It's in the Git Wine Tutorial, but I've now added a note in Submitting Patches as well. It's also displayed on account creation, but you probably created your account before I finished setting that up... -- Alexandre Julliard julliard(a)winehq.org

Sept. 24, 2024

Re: Gitlab forks limit issue

by robert.ayrapetyan＠gmail.com

Thanks! [If it's not intentionally hidden] Could you add this to https://gitlab.winehq.org/wine/wine/-/wikis/Submitting-Patches? I went through all the links from https://gitlab.winehq.org/wine/wine/-/wikis/Developers but couldn’t find the info you've shared above. :(

Sept. 24, 2024

Re: Gitlab forks limit issue

by Alexandre Julliard

robert.ayrapetyan(a)gmail.com writes: > Hello, could you please let me know who I should contact to increase > the quotas for my account (rayrapetyan) on > https://gitlab.winehq.org/wine? I'm currently unable to fork Wine from > https://gitlab.winehq.org/wine/wine/-/forks/new due to the following > error: "Limit reached. You cannot create projects in your personal > namespace. Contact your GitLab administrator." You need to validate your account, cf. https://gitlab.winehq.org/winehq/winehq/-/wikis/home -- Alexandre Julliard julliard(a)winehq.org

Sept. 24, 2024

Re: Carry flag state after a system function call

by Hin-Tak Leung

I don't know about anything except possibly the answer to your last question . You can get the sources for the binaries you have from e.g. https://packages.debian.org/sid/wine (Or the equivalent in debian testing etc) Look at the side panel on the right - typically they rename the upstream tar ball to *.orig.*, And the debian-specific build machineries in *.debian.* . The build machinery files should unpack to a debian directory which is typically to be housed inside the source's top level directory to be used, and consists of some shell-script -like files with CFLAGS, etc. Or, instead of downloading manually from debian 's server like above, if you are on the debian system itself, you can use `apt-get source ...` to get at the source files corresponding to your binaries. Read about "apt-get source ...". The compiler flags etc should be somewhere in the debian/ directory once unpacked, either way. On Tuesday 24 September 2024 at 04:39:32 BST, <robert.ayrapetyan(a)gmail.com> wrote: Hello, some legacy applications depend on the carry flag state after calling system functions. I've noticed that certain apps work correctly when using Wine installed from packages, but fail when Wine is built from sources. After investigating, I found that Wine from Debian packages is compiled with certain flags that stabilize ESP at the end of system function calls (e.g., sub ESP, 0x10), which, as a side effect, clears the carry flag, making the application happy. I tried using fno-omit-frame-pointer, but it generates lea instructions, which don't impact the carry flag. Has anyone else encountered same behavior? How frequently do older applications rely on the carry flag after system function calls? Also, which specific flags are used to compile the Wine version available in Debian packages?

Sept. 24, 2024