valvesoftware / wine Goto Github PK

Running wine cmd.exe /c echo '%ProgramFiles%' causes the original process to exit successfully, but wineserver and other background processes continue in the background without cleaning themselves up. If the command is executed using Steam Runtime Soldier, this means the entire command will hang indefinitely due to the remaining processes. If not, the background processes will continue in the background after the command has finished.

The issue can be reproduced this way:

• Launch a Steam game using Proton Experimental with the PROTON_DUMP_DEBUG_COMMANDS=1 set.
• Go to the debug directory and edit run to remove steam.exe from the last line. If this is not removed, Wine will clean up after itself properly.
• Run ./run cmd.exe /c echo '%ProgramFiles%'. The path will be printed and cmd.exe will exit, but other processes will continue execution in the background.

This issue occurs on Proton Experimental 1632501009 experimental-6.3-20210924, but not Proton 6.3. Other commands such as winecfg.exe work properly without causing the background processes to hang.

I've uploaded a Wine log with WINEDEBUG="+timestamp,+pid,+tid,+seh,+debugstr,+loaddll,+mscoree" here:

https://gist.github.com/Matoking/e59586e9d9f929ec7506663d4b907039

Tested on Arch Linux with kernel version 5.14.6-arch1-1.

I'm new to Linux / Wine and have been trying to install some old favourite games of mine. While this software installed properly, running it is an issue due to a Quick Time error as shown. Any advice would be welcome and much appreciated.

wine-mirror/wine@ed75a7b#diff-556449596eac325214e3d355dfaa9826
wine-mirror/wine@b9af369#diff-556449596eac325214e3d355dfaa9826
wine-mirror/wine@3c329e2#diff-556449596eac325214e3d355dfaa9826

these fix the high corecount issue with games like skyrim se and fallout 4 hanging infinitely at save loading/new game loading on systems with processors like the Threadripper 1950x. also fixes the neverwinter launcher. tested and working on my custom build.

https://www.myabandonware.com/game/al-qaeda-hunting-3d-dwh
without WINE_FULLSCREEN_INTEGER_SCALING:

with WINE_FULLSCREEN_INTEGER_SCALING only black screen is shown

al-3d.log

If wine process is already confined externally (e.g. with some container sandbox like flatpak, LXC, docker, etc), it's own seccomp filters are never applied.
It comes from this check:

After some discussion regarding this patchset with the patch creator regarding this bug:

https://bugs.winehq.org/attachment.cgi?id=66387

The author has made an updated version compatible with proton. There is one block that needs modification, which I've applied here:

https://bugs.winehq.org/show_bug.cgi?id=46309#c12

The reason I'm bringing this up is because this bug also affects Origin, and the patch allows origin to be freely dragged smoothly without issue.

I know that you guys have already stated that everything that will be accepted upstream, will be pushed upstream.

However I'm wondering if there are any easily available patch sets that we can apply ourselves to upstream wine. I'm asking because there are a few very old games that I run with wine and I would really like to use the "Scale fullscreen to native desktop resolution" patches for these games.

I guess I could just compile and use the wine version in this repo, but it would be easier for me with patch sets (because I can easily apply them to upstream wine with Gentoo portage).

Or perhaps these patches could be submitted to wine staging in the mean time?

e921eb5 has been made redundant by the app_compat_configs in 891390:

https://steamdb.info/app/891390/

It should be dropped from the proton patch set.

Does the Proton 4.11 branch have the fsync patches already applied?

Caused by 289f450 ("mmdevapi: Implement ActivateAudioInterfaceAsync.")

Looks like we are missing two other patches from the upstream:

• 6e09636 ("include: Split objidl.idl to objidlbase.idl.")
• cdf013b ("include: Add IAgileObject to objidlbase.idl.")

Then 29ccc21 ("windows.globalization: Add stub dll.") needs a small fixup:

diff --git a/dlls/windows.globalization.dll/windows.globalization_main.c b/dlls/windows.globalization.dll/windows.globalization_main.c
index f29079d6a5e..e6bba5e096f 100644
--- a/dlls/windows.globalization.dll/windows.globalization_main.c
+++ b/dlls/windows.globalization.dll/windows.globalization_main.c
@@ -25,7 +25,6 @@ static const char *debugstr_hstring(HSTRING hstr)

 DEFINE_GUID(IID_IGlobalizationPreferencesStatics,0x01bf4326,0xed37,0x4e96,0xb0,0xe9,0xc1,0x34,0x0d,0x1e,0xa1,0x58);
 DEFINE_GUID(IID_IVectorView,0xbbe1fa4c,0xb0e3,0x4583,0xba,0xef,0x1f,0x1b,0x2e,0x48,0x3e,0x56);
-DEFINE_GUID(IID_IAgileObject,0x94ea2b94,0xe9cc,0x49e0,0xc0,0xff,0xee,0x64,0xca,0x8f,0x5b,0x90);
 DEFINE_GUID(IID_IInspectable,0xaf86e2e0,0xb12d,0x4c6a,0x9c,0x5a,0xd7,0xaa,0x65,0x10,0x1e,0x90);

 typedef struct IVectorView IVectorView;

Depth test does not work. Seems to be a bug somewhere in wgl/glx translation layer. Check if depth buffer size translated correctly
SeriousEditor has the same issue
In D3D mode game does not draw anything with such errors:

Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)

https://github.com/ValveSoftware/wine/blob/proton_3.7/dlls/opengl32/wgl.c
vega 11, amdgpu
glxinfo:
https://pastebin.com/LpjkiwyD

Hi,

Have see a strange prefix creation.
In 6.3-5 :
drive_c/users/steamuser/Application Data exist
In 6.3-6 :
drive_c/users/steamuser/Application Data not exist
After update to wine-proton 6.3-6 some games lost save.

Full Compare :
6.3-5

AppData
Application Data
Contacts
Cookies
Desktop
Downloads
Favorites
Links
Local Settings
My Documents
My Music
My Pictures
My Videos
NetHood
PrintHood
Recent
Saved Games
Searches
SendTo
Start Menu
Temp
Templates

6.3-6

AppData
Contacts
Desktop
Documents
Downloads
Favorites
Links
Music
My Documents
My Music
My Pictures
My Videos
Pictures
Saved Games
Searches
Temp
Templates
Videos

Best Regards

Please update with patch to fix Mac OS build:

As mentioned in This comment for Subnautica there's some mouse issues where there's unexpected movement during mouse button presses. I'm experiencing a very similar issue in Stationeers (APPID: 544550) so I suspect it's got something to do with unity3d, which both games use.

Hi,

Now with last stable build 6.3-5 have this error :

../host-wine-proton-proton-wine-6.3-5/tools/widl/widl -o dlls/xactengine3_0/xact_classes_r.res -b x86_64-buildroot-linux-gnu -m64 \
  --nostdinc -Idlls/xactengine3_0 -Idlls/xactengine3_7 -Iinclude \
  -I/build/wine/output/x86_64/host/bin/../x86_64-buildroot-linux-gnu/sysroot/usr/include/gstreamer-1.0 \
  -I/build/wine/output/x86_64/host/bin/../x86_64-buildroot-linux-gnu/sysroot/usr/include/glib-2.0 \
  -I/build/wine/output/x86_64/host/bin/../x86_64-buildroot-linux-gnu/sysroot/usr/lib/glib-2.0/include \
  -D__WINESRC__ -pthread -DXACT3_VER=0x0300 dlls/xactengine3_7/xact_classes.idl
../host-wine-proton-proton-wine-6.3-5/tools/widl/widl: invalid option -- 'e'
Usage: widl [options...] infile.idl
   or: widl [options...] --dlldata-only name1 [name2...]
   --acf=file         Use ACF file
   -app_config        Ignored, present for midl compatibility
   -b arch            Set the target architecture
   -c                 Generate client stub
   -d n               Set debug level to 'n'
   -D id[=val]        Define preprocessor identifier id=val
   -E                 Preprocess only
   --help             Display this help and exit
   -h                 Generate headers
   -H file            Name of header file (default is infile.h)
   -I path            Set include search dir to path (multiple -I allowed)
   --local-stubs=file Write empty stubs for call_as/local methods to file
   -m32, -m64         Set the target architecture (Win32 or Win64)
   -N                 Do not preprocess input
   --nostdinc         Do not search the standard include path
   --ns_prefix        Prefix namespaces with ABI namespace
   --oldnames         Use old naming conventions
   -o, --output=NAME  Set the output file name
   -Otype             Type of stubs to generate (-Os, -Oi, -Oif)
   -p                 Generate proxy
   --prefix-all=p     Prefix names of client stubs / server functions with 'p'
   --prefix-client=p  Prefix names of client stubs with 'p'
   --prefix-server=p  Prefix names of server functions with 'p'
   -r                 Generate registration script
   -robust            Ignored, present for midl compatibility
   --sysroot=DIR      Prefix include paths with DIR
   -s                 Generate server stub
   -t                 Generate typelib
   -u                 Generate interface identifiers file
   -V                 Print version and exit
   -W                 Enable pedantic warnings
   --win32, --win64   Set the target architecture (Win32 or Win64)
   --win32-align n    Set win32 structure alignment to 'n'
   --win64-align n    Set win64 structure alignment to 'n'
   --winrt            Enable Windows Runtime mode
Debug level 'n' is a bitmask with following meaning:
    * 0x01 Tell which resource is parsed (verbose mode)
    * 0x02 Dump internal structures
    * 0x04 Create a parser trace (yydebug=1)
    * 0x08 Preprocessor messages
    * 0x10 Preprocessor lex messages
    * 0x20 Preprocessor yacc trace
make[2]: *** [Makefile:149742: dlls/xactengine3_0/xact_classes_r.res] Error 1
make[2]: *** Waiting for unfinished jobs....

I have never had this error before do you know what has changed?

Best Regards

Current input implementation has a high latency as compared to windows - which makes (e.g. first-person shooters) unplayable. A hacky test implementation using evdev (/dev/input) + eliminating unnecessary context switches (X11 -> wineserver -> client) yields very low latency input. It also results in more precise (mouse)-input when using relative events as compared to using X11 event data. Pls consider a low latency input implementation for proton.

Please apply the recently staged bugfix for ReplaceFile behavior when trying to replace own executable. (Affects the Warframe launcher self-update at least): wine-staging/wine-staging@8b930ae
Thank you.

If I understand it right this hack is to ensure that the game can be scaled up from his res to the target res of the monitor?
Which patches where applied to upstream to do this?

Hello. I've troubled with building wine-valve AUR package on my Manjaro Linux.
I've always got errors like following outputs.
Errors say several "undefined reference to `sincosf'," which means needs of math library?
But I don't know how to add and where to modify.
Please help.

tools/winegcc/winegcc -o dlls/d3d10/d3d10.dll --wine-objdir . -b x86_64-w64-mingw32 --lib-suffix=.cross.a \
  -Wl,--wine-builtin -shared ../wine-experimental-wine-6.3-20210616/dlls/d3d10/d3d10.spec \
  -mno-cygwin dlls/d3d10/d3d10_main.cross.o dlls/d3d10/effect.cross.o dlls/d3d10/reflection.cross.o \
  dlls/d3d10/shader.cross.o dlls/d3d10/stateblock.cross.o dlls/d3d10/utils.cross.o \
  dlls/d3d10/version.res dlls/uuid/libuuid.cross.a dlls/d3d10core/libd3d10core.cross.a \
  dlls/d3dcompiler_47/libd3dcompiler.cross.a dlls/dxgi/libdxgi.cross.a \
  dlls/ucrtbase/libucrtbase.cross.a 
/usr/lib/gcc/x86_64-w64-mingw32/11.1.0/../../../../x86_64-w64-mingw32/bin/ld: dlls/d2d1/brush.cross.o: in function `d2d_brush_fill_cb':
/home/aki/PKGBUILD/wine-valve/src/wine-valve-64-build/../wine-experimental-wine-6.3-20210616/dlls/d2d1/brush.c:1215: undefined reference to `sincosf'
/usr/lib/gcc/x86_64-w64-mingw32/11.1.0/../../../../x86_64-w64-mingw32/bin/ld: dlls/d2d1/factory.cross.o: in function `D2D1MakeRotateMatrix':
/home/aki/PKGBUILD/wine-valve/src/wine-valve-64-build/../wine-experimental-wine-6.3-20210616/dlls/d2d1/factory.c:637: undefined reference to `sincosf'
/usr/lib/gcc/x86_64-w64-mingw32/11.1.0/../../../../x86_64-w64-mingw32/bin/ld: dlls/d2d1/factory.cross.o: in function `D2D1SinCos':
/home/aki/PKGBUILD/wine-valve/src/wine-valve-64-build/../wine-experimental-wine-6.3-20210616/dlls/d2d1/factory.c:718: undefined reference to `sincosf'
collect2: error: ld returned 1 exit status
winegcc: /usr/bin/x86_64-w64-mingw32-gcc failed
make: *** [Makefile:37138: dlls/d2d1/d2d1.dll] Error 2
make: *** Waiting for unfinished jobs....
==> ERROR: A failure occurred in build().
    Aborting...

In Wine 3.7, I was able to use my Wii Classic Controller to play Hyperdimension Neptunia. In Proton's Wine, the game no longer detects it. However, it still shows up in wine control under "Game Controllers" as "Nintendo Wii Remote Classic Controller (js)".

This patch applied to Proton's Wine fixes the issue:

diff --git a/dlls/dinput/dinput_main.c b/dlls/dinput/dinput_main.c
index 91119548d5..0fc384be1c 100644
--- a/dlls/dinput/dinput_main.c
+++ b/dlls/dinput/dinput_main.c
@@ -88,9 +88,9 @@ static const struct dinput_device *dinput_devices[] =
 {
     &mouse_device,
     &keyboard_device,
-    &joystick_sdl_device,
     &joystick_linuxinput_device,
     &joystick_linux_device,
+    &joystick_sdl_device,
     &joystick_osx_device
 };
 #define NB_DINPUT_DEVICES (sizeof(dinput_devices)/sizeof(dinput_devices[0]))

I'm super unfamiliar with the codebase so this might be a bit of a stupid question, but why stop enumeration after SDL?

I've noticed that in games that like to identify the GPU (two games in question were Flatout2 (dx9 game) and Skyrim Special Edition (DX11/dxvk game)) that my laptop's RTX 2060 is being read as a GTX 470.

This strikes me as more than a little bit odd, not sure how much of a problem it could actually be as the games run fine, but it's one of those little things that might get confusing on occasion.

I imagine it's possible that other RTX series cards have a similar issue.

This is the normal version used throughout loader.c which was added for the steamclient swap:

static WCHAR *strstriW( const WCHAR *str, const WCHAR *sub )
{
    while (*str)
    {
        const WCHAR *p1 = str, *p2 = sub;
        while (*p1 && *p2 && tolowerW(*p1) == tolowerW(*p2)) { p1++; p2++; }
        if (!*p2) return (WCHAR *)str;
        str++;
    }
    return NULL;
}

And this second one was added specifically for the AoE3 game check:

static WCHAR *strcasestrW( const WCHAR *str, const WCHAR *sub )
{
    while (*str)
    {
        const WCHAR *p1 = str, *p2 = sub;
        while (*p1 && *p2 && tolowerW(*p1) == tolowerW(*p2)) { p1++; p2++; }
        if (!*p2) return (WCHAR *)str;
        str++;
    }
    return NULL;
}

It's the exact same function with a different name.

Used specifically for:

            strcasestrW( libname, mfc42W ))
            
            

So you can remove the duplicate function and change strcasestrW on that line to strstriW

Also for future proofing, you can use RtlDowncaseUnicodeChar in the function instead of tolowerW:

static WCHAR *strstriW( const WCHAR *str, const WCHAR *sub )
{
    while (*str)
    {
        const WCHAR *p1 = str, *p2 = sub;
        while (*p1 && *p2 && RtlDowncaseUnicodeChar(*p1) == RtlDowncaseUnicodeChar(*p2)) { p1++; p2++; }
        if (!*p2) return (WCHAR *)str;
        str++;
    }
    return NULL;
}

https://www.winehq.org/announce/3.15

Building always fails with this error:
fatal error: gnutls26/gnutls.h: No such file or directory

libgnutls28-dev is installed, and I have no clue why I get this message!
What can I do to avoid this error?

It has
"Support for DXTn texture decompression."
And some fixes for saving games.(since wine 3.11, https://source.winehq.org/git/wine.git/patch/ff7c2c51718e8f64c9b708847f3a322bd136eb75)

https://www.winehq.org/announce/3.14

Hi,

Why release have been removed ?

Best Regards

Please cherry pick the following commits for compatibility with GCC 10

wine-mirror/wine@5740b73
wine-mirror/wine@fba65a1
wine-mirror/wine@453980e
wine-mirror/wine@e402fdf
wine-mirror/wine@cc7f698
wine-mirror/wine@c13d587
wine-mirror/wine@93888fb
wine-mirror/wine@4a91eb3
wine-mirror/wine@bc51c5d
wine-mirror/wine@388348d
wine-mirror/wine@44e6940

It appears that this only happens within the Valve modified sources:

luke@stardust:~/src/Proton/dist$ PROTON_NO_ESYNC=1 PROTON_DUMP_DEBUG_COMMANDS=1 STEAM_COMPAT_DATA_PATH="/Users/luke/.wine" ./proton run /Users/luke/Downloads/vkquake-1.00.0_win64/vkQuake.exe -basedir /Users/luke/quake/
Command line: Z:\Users\luke\Downloads\vkquake-1.00.0_win64\vkQuake.exe -basedir /Users/luke/quake/
Found SDL version 2.0.8
Detected 8 CPUs.
Quake 1.09 (c) id Software
GLQuake 1.00 (c) id Software
FitzQuake 0.85 (c) John Fitzgibbons
FitzQuake SDL port (c) SleepwalkR, Baker
QuakeSpasm 0.93.0 (c) Ozkan Sezer, Eric Wasylishen & others
vkQuake 1.00.0 (c) Axel Gneiting & others
Host_Init
Playing registered version.
Console initialized.
UDP Initialized
WIPX_OpenSocket: Address family not supported by protocol family
WIPX_Init: Unable to open control socket, IPX disabled
Server using protocol 666 (FitzQuake)
Exe: 20:55:34 Jun 11 2018
256.0 megabyte heap

Vulkan Initialization
[mvk-info] MoltenVK version 1.0.19. Vulkan version 1.0.83.
[mvk-info] GPU device:
		model: AMD Radeon Pro 560
		type: Discrete
		vendorID: 0x1002
		deviceID: 0x67ef
		pipelineCacheUUID: 00000000-0000-0000-0000-271300002723
	supports the following Metal Feature Sets:
		macOS GPU Family 1 v3
		macOS GPU Family 1 v2
		macOS GPU Family 1 v1
[mvk-info] GPU device:
		model: Intel(R) HD Graphics 630
		type: Integrated
		vendorID: 0x8086
		deviceID: 0x591b
		pipelineCacheUUID: 00000000-0000-0000-0000-271300002723
	supports the following Metal Feature Sets:
		macOS GPU Family 1 v3
		macOS GPU Family 1 v2
		macOS GPU Family 1 v1
wine: Unhandled page fault on read access to 0xffffffffffffffff at address 0x4742f774 (thread 0009), starting debugger...
winedbg: Internal crash at 0x43525885

This the same issue reported here.

When replacing the wine source in the Proton project with a fresh winehq version (devel or staging) this problem goes away.

PROTON_NO_ESYNC=1 has no effect.

Wine's current implementation of xinput uses SDL on Linux. This shows the following problem:

Microsoft clearly points out that xinput device have no dead zones on the API level, dead zones must be handled by the game itself: https://docs.microsoft.com/en-us/windows/win32/xinput/getting-started-with-xinput

But on Linux, SDL handles dead zones for evdev devices, and devices from joydev have dead zones at the kernel level. The current work-around is to set flatness to zero for such devices in the kernel. So Proton currently has no way to control this.

This has a big impact on any gamepad-controlled game played in Proton and makes a very bad experience when precision is needed such as in fast first person games, simulations etc. Evidence shows that the situation is greatly improved by setting the flatness to 0 at the Linux layer so SDL or joydev will no longer handle dead zones, in consequence Proton will see no dead zones from the lower layers and can pass unfiltered input data through the xinput API.

Since reading from evdev exposes no dead zones, the best approach would probably be to patch SDL to have an API call if one wants to receive input data without any dead zones applied. Proton could then just switch dead zones from SDL off and receive unfiltered inputs. Wine can already apply its own dead zone handler if games set that property, so that's probably all that's needed.

An intermediate solution would be that Proton makes that switchable on a game-per-game basis by setting flatness for devices to zero at launch time, and restoring the original value when the game quits. Maybe it's fine to just to that for any game and instead set the default Wine dead zone to 10%.

We currently implemented that in xpadneo by reducing the fuzz parameter by a factor of 8 for Xbox controllers which already makes a perceivable smoother and more direct input experience. We also shrunk the dead zone by 25% which improves the situation a little for games requiring precise control. We also added a driver option for high-precision mode which turns dead zones off, and that has a huge impact on game experience. xow is probably following soon at least partially with a similar solution. But this can only be a work-around as it messes with joydev (games and applications may not expect to have a joydev without dead zones). The xpad driver walks the middle ground by using 128 as the dead zone but this is no solution on either side because it makes joydev jittery without eliminating the dead zone for xinput games.

@aeikum I wonder what the best solution would be?

See also:
atar-axis/xpadneo#232
medusalix/xow#105

So now that this is out in the wild...

FAudio is a new, accuracy-focused reimplementation of XAudio2 and its relative libraries (such as X3DAudio, XACT, and XAPO). Part of this work includes a COM wrapper that mimics the Windows XAudio2 DLLs, allowing Windows games to use FAudio for audio support instead. This is known to work on both Windows and Wine for 32- and 64-bit, and both @JohanSmet and @aeikum have been putting in work to make it more compatible with the whole range of XAudio2 versions.

At the moment Wine is reimplementing XAudio2 with OpenAL Soft, and the other libraries (including X3DAudio) are currently stubbed. In addition to the feature gaps, there are also various accuracy issues that come from wrapping a low-level audio API around a high-level API (as we found ourselves while making FNA, hence the creation of FAudio).

The idea is that FAudio would both fill in large gaps left by the current Wine implementation as well as make the existing implementation much more accurate, and in a perfect world, remove the need for the DX redist for audio support.

Andrew has been leading the charge with Wine compatibility lately so I'll let him drive this thread, but the main things that Wine cares about:

• WMA support via FFmpeg
• XAPOFX support
• Full X3DAudio support
• Possible (read: real) support for CommitChanges
• Possible support for unaligned buffer data (see: Super Meat Boy ADPCM)
• XACT DLLs (two example games: Resident Evil 4, P.B. Winterbottom)
• More...?

When trying to make the configured project i get this error:

dlls/mfreadwrite/tests/mfplat.c: In function ‘test_source_reader_from_media_source’:
dlls/mfreadwrite/tests/mfplat.c:977:5: error: ‘pos’ undeclared (first use in this function)
  977 |     pos.vt = VT_I8;
      |     ^~~

Hello. I did try to install wine-stable on ubuntu 18.04,
but I see the following errors:

Preparing to unpack .../wine-stable-i386_6.0.0~bionic-1_i386.deb ...
Unpacking wine-stable-i386:i386 (6.0.0~bionic-1) ...
dpkg: error processing archive /var/cache/apt/archives/wine-stable-i386_6.0.0~bionic-1_i386.deb (--unpack):
unable to securely remove '/opt/wine-stable/lib/wine/regedit.exe.dpkg-new': Invalid argument
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
/var/cache/apt/archives/wine-stable-i386_6.0.0~bionic-1_i386.deb

I did go to /opt/wine-stable/lib/wine/
and see there, this:

user@comp:/opt/wine-stable/lib/wine$ dir
regedit.exe.dpkg-new regsvr32.exe.dpkg-new

two files, and this can not be deleted, using sudo rm -rf -- *?

How to install wine 6.0 or another stable version, on Ubuntu 18.04?
Or compile from the source code...

According to Henri, the last two patches by Stefan that were cherry picked cause a crash, at least in the tests.

See https://bugs.winehq.org/show_bug.cgi?id=51047
https://source.winehq.org/git/wine.git/commit/095bdc6
https://source.winehq.org/git/wine.git/commit/7fabcf6
(although these patches are a part of a series and it might be best to backport them all:
https://source.winehq.org/git/wine.git/commit/d7cd5587df5c0dfc6a5b0b9586b0feee28ee0de8
https://source.winehq.org/git/wine.git/commit/ab431c70b4537ce62ead8d79939d801932327159
https://source.winehq.org/git/wine.git/commit/59e5a8d055f28bde9f53354cd250a641d84b9a51
https://source.winehq.org/git/wine.git/commit/9b2f59cb94d5aa7b8fbe4e0373d933a630b51dc1).

I realize that the bug report references The Sims 2, a game not available on Steam, but I can imagine this affects more than just that game.

https://gist.github.com/qsniyg/ec21d68f9407991a1043a71fa6ffd4cf

This would allow ModOrganizer 2 (probably the most popular program to mod Skyrim/Fallout) to work under Proton.

The patch is mostly just a point of reference (hence why the check was commented out instead of removed), so you'll probably want to implement it your own way.

Researching more into the check however, I believe the check present in wine actually doesn't follow Windows's behavior at all, because USVFS will consistently return only one entry when iterating through the virtual filesystem with NtQueryDirectoryFile, and Windows accepts it. So I believe any regressions stemming from removing the check would rather be a separate inaccuracy in wine, rather than the check being at fault (so far, I haven't noticed any regressions).

Reddit thread explaining about the patch: https://www.reddit.com/r/linux_gaming/comments/d3493y/i_got_mod_organizer_2s_usvfs_running_under_wine/

Apparently, many old DX3-7 games rely on being able to create a rendering target in system memory rather than video memory, and mainline Wine does not support that. This patch from Staging solves this issue by creating the render target in video memory instead.
Some notable games that depend on this according to WineHQ: *The Sims, Zoo Tycoon, TOCA Touring Car Championship, Conquest: Frontier Wars (the latter is available on Steam and has a demo)
However, there might be many more games out there that depend this feature, there are just the ones that were reported to use it.
I can personally confirm that it works very well with The Sims and that game was stable for hours and hours.
The patch: https://github.com/wine-staging/wine-staging/tree/master/patches/ddraw-Rendering_Targets
The WineHQ issue: https://bugs.winehq.org/show_bug.cgi?id=34906

when i type
wine myexefile.exe

000f:err:service:process_send_command receiving command result timed out
000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 1053
0035:fixme:ver:GetCurrentPackageId (0x82fe8c (nil)): stub
0015:err:service:process_send_command receiving command result timed out
002b:err:plugplay:handle_bus_relations Failed to load driver L"WineHID"

ubuntu 16 x64

The app works but it closes or stops responding after some time.

Hello,

In wine-staging there is some useful patches to fix some wine problems:

1. CEF (Chromium Embedded Framework) crashes on process startup, some games use it for their GUI, for example: AION, World of Tanks, etc.
2. PulseAudio (winepulse patchset) (2 of 10 already merged) rest of patches resolves audio crackling problem in games that's reported multiple times.

Patches from wine-staging to get CEF working:

• ntdll-ThreadTime
• ntdll-Hide_Wine_Exports
• ntdll-User_Shared_Data
• winebuild-Fake_Dlls - functions that cef_sandbox uses
• bcrypt-BCryptDeriveKeyPBKDF2
• bcrypt-BCryptGenerateKeyPair - support for ECDSA certificate chains
• kernel32-SetFileCompletionNotificationModes - this function used in networking code

Patches from wine-staging to get PulseAudio working:

• winepulse-PulseAudio_Support - only 2 of 10 patches are merged now, merge rest of patches to get crackling-less sound.

BR, sorry for my bad English and thanks for your work.

futex2 with latest experimental hangs at startup and is unusable. This is because at https://github.com/ValveSoftware/wine/blob/experimental_5.13/server/fsync.c#L86

if (use_futex2 && (f = fopen( "/sys/kernel/futex2/wait", "r" )))
        {
            char buffer[13];

            fgets( buffer, sizeof(buffer), f );
            nr_futex2_wake = atoi( buffer );
            fclose(f);

            do_fsync_cached = 1;
        }

Should be f = fopen( "/sys/kernel/futex2/wake", "r" ) instead, since we're assigning to nr_futex2_wake.

Parent issue (ValveSoftware/Proton#66), but likely needs to be a discussion specific to wine maintainers (perhaps the same group). See ValveSoftware/Proton#66 (comment) for a summary of the suggestion, but given the state of d3d9 over vulkan and the performance gains for those able to make use of Gallium Nine it seems worth consideration. Obviously, may have other priorities and this would require maintaining the changes to some degree which is why the topic should be discussed before much effort is given.

Hello the physic memory in wine is swap + ram, but swap is instable and cause bug on game become Call of duty... Just add PROTON_IGNORE_SWAP=1 ? Thanks for read my message

When I'm running a game on my second monitor and switch it to fullscreen, the mouse cursor is clipped to the primary screen but the game is resized to cover the secondary screen.

It works correctly for games displayed only on the primary screen.

Tested with: Path of Exile (CoInitialize patch applied so it can work in DX11 mode)

Setup your window manager to force the window to the secondary screen. Start the game, press Alt+Enter, the games successfully switches into fullscreen on the second monitor. But now the mouse cursor is clipped to the primary monitor.

I think that multi-monitor support in wine is somewhat buggy. Without making kwin forcing the game to the second monitor, it will display always on the primary monitor (happens with standard wine, too). Since this is a mouse-and-keyboard game, I'd like it to display on the desktop monitor, not the TV. TV is already set as the primary X11 monitor because otherwise many games (native and SteamPlay) would display on the wrong monitor.

The return statement on line 482 in dlls/kernel32/module.c may be executed without the loader lock set earlier never being released.

Currently this dll is built inside of proton:

 build_lsteamclient64
{
    cd "$TOP"
    rm -rf build/lsteamclient.win64
    cp -a lsteamclient build/lsteamclient.win64
    cd "$TOP"/build/lsteamclient.win64/
    $AMD64_WRAPPER "$TOP"/wine/tools/winemaker/winemaker \
        --nosource-fix --nolower-include --nodlls --nomsvcrt \
        -DSTEAM_API_EXPORTS \
        -I"$TOOLS_DIR64"/include/ \
        -I"$TOOLS_DIR64"/include/wine/ \
        -I"$TOOLS_DIR64"/include/wine/windows/ \
        -L"$TOOLS_DIR64"/lib64/ \
        -L"$TOOLS_DIR64"/lib64/wine/ \
        --dll .
    CXXFLAGS="-Wno-attributes -O2" CFLAGS="-O2 -g" PATH="$TOOLS_DIR64/bin:$PATH" $AMD64_WRAPPER make $JOBS
    if [ x"$STRIP" != x ]; then
        $AMD64_WRAPPER $STRIP lsteamclient.dll.so
    fi
    cp -a lsteamclient.dll.so "$DST_DIR"/lib64/wine/
}

function build_lsteamclient32
{
    cd "$TOP"
    rm -rf build/lsteamclient.win32
    cp -a lsteamclient build/lsteamclient.win32
    cd "$TOP"/build/lsteamclient.win32/
    $I386_WRAPPER "$TOP"/wine/tools/winemaker/winemaker \
        --nosource-fix --nolower-include --nodlls --nomsvcrt --wine32 \
        -DSTEAM_API_EXPORTS \
        -I"$TOOLS_DIR32"/include/ \
        -I"$TOOLS_DIR32"/include/wine/ \
        -I"$TOOLS_DIR32"/include/wine/windows/ \
        -L"$TOOLS_DIR32"/lib/ \
        -L"$TOOLS_DIR32"/lib/wine/ \
        --dll .
    CXXFLAGS="-Wno-attributes -O2" CFLAGS="-O2 -g" PATH="$TOOLS_DIR32/bin:$PATH" $I386_WRAPPER make $JOBS
    if [ x"$STRIP" != x ]; then
        $I386_WRAPPER $STRIP lsteamclient.dll.so
    fi
    cp -a lsteamclient.dll.so "$DST_DIR"/lib/wine/
}

it would be nice if this DLL could be integrated with the wine builds rather than a patch by the proton project itself. I suggested pulling this upstream into wine in: ValveSoftware/Proton#724 , and was told this might be the correct place for such an issue to be proposed.

Using Wine and attempting to play any game using Raw Input results in the game having a completely different sensitivity than on Windows with same settings.
Tested using Overwatch, which uses Raw Mouse Input by default.

Raw Input works on any native port (I have the same sensitivity when using Raw Input in TF2 on Windows and Linux), but not on Wine.

I have already disabled any mouse acceleration on GNOME:

Keyboard Control:
auto repeat: on key click percent: 0 LED mask: 00000002
XKB indicators:
00: Caps Lock: off 01: Num Lock: on 02: Scroll Lock: off
03: Compose: off 04: Kana: off 05: Sleep: off
06: Suspend: off 07: Mute: off 08: Misc: off
09: Mail: off 10: Charging: off 11: Shift Lock: off
12: Group 2: off 13: Mouse Keys: off
auto repeat delay: 500 repeat rate: 33
auto repeating keys: 00ffffffdffffbbf
fadfffefffedffff
9fffffffffffffff
fff7ffffffffffff
bell percent: 50 bell pitch: 400 bell duration: 100
Pointer Control:
acceleration: 0/1 threshold: 0
Screen Saver:
prefer blanking: yes allow exposures: yes
timeout: 0 cycle: 0
Colors:
default colormap: 0x20 BlackPixel: 0x0 WhitePixel: 0xffffff
Font Path:
/usr/share/fonts/X11/misc,/usr/share/fonts/X11/Type1,built-ins
DPMS (Energy Star):
Standby: 0 Suspend: 0 Off: 0
DPMS is Enabled
Monitor is On

https://www.reddit.com/r/wine_gaming/comments/9g9br6/disable_mouse_acceleration_in_overwatch/
Someone told me it's possible to make Wine use SDL for getting Raw Mouse Input instead of X11 itself. It would be great if you guys can patch this in somehow, as it would also help Wayland.

https://github.com/wine-mirror/wine/commits/master/dlls/crypt32

The patches from September 25 to September 27 fix a segfault in crypt32 that affects Rise of Nations:

ValveSoftware/Proton#298

It would be nice to cherrypick them into Proton's wine so that Rise of Nations and anything else that hits it won't need end users to install the native crypt32 DLL as a workaround.

Hi,

I know you don't support a compilation out of proton build system.
But have fixe issue on 6.3-5 but 6.3-6 have new compilation issue.
And my OS don't support your build system.
@aeikum If you have any idea how to fix ?

dlls/user32/focus.c: In function ‘GetForegroundWindow’:
dlls/user32/focus.c:372:78: error: ‘const struct get_thread_input_reply’ has no member named ‘foreground’
  372 |         if (!wine_server_call_err( req )) ret = wine_server_ptr_handle( reply->foreground );
      |                                                                              ^~
make[2]: *** [Makefile:125538: dlls/user32/focus.o] Error 1
make[2]: *** Waiting for unfinished jobs....
dlls/user32/input.c: In function ‘GetCursorInfo’:
dlls/user32/input.c:293:57: error: ‘const struct get_thread_input_reply’ has no member named ‘cursor’
  293 |             pci->hCursor = wine_server_ptr_handle( reply->cursor );
      |                                                         ^~
dlls/user32/input.c:294:32: error: ‘const struct get_thread_input_reply’ has no member named ‘show_count’
  294 |             pci->flags = (reply->show_count >= 0) ? CURSOR_SHOWING : 0;
      |                                ^~
make[2]: *** [Makefile:125598: dlls/user32/input.o] Error 1
dlls/user32/message.c: In function ‘peek_message’:
dlls/user32/message.c:2743:50: error: ‘const struct get_message_reply’ has no member named ‘active_hooks’
 2743 |                 thread_info->active_hooks = reply->active_hooks;
      |                                                  ^~
make[2]: *** [Makefile:125696: dlls/user32/message.o] Error 1

Best Regards

As per this issue here: https://bugs.winehq.org/show_bug.cgi?id=49160

In Unity games the SystemInfo.deviceUniqueIdentifier is consistent across all wine users. This causes issues when trying to individually determine users.

Wine 5.10 appears to have an update to address this issue.

Is it on the road map?

Thanks