[WIP] Rough example of using custom WINE installations

[ghost]

Related to issue #22

This is just a quick throw together. There are considerations with how the script works I did not at all care about for a quick example:

• Different wineprefix directory from wine bins
• Preventing override of the system wine bin directory

Creation of a new prefix shouldn't be a big deal, so i'm not worried about that.

From there it would just be a case of setting your WINE_BASEDIR or something similar in the game launch options as WINE_BASEDIR=/home/USERNAME/.local/share/lutris/runners/wine/staging-3.12-x86_64/ %command%

[ghost]

There is no CONTRIBUTING.md, so I am not sure what expectations are for merging back / pull request formats

[Elkasitu]

you can just use os.environ.get here and leave the env and dlloverrides definition where they were

[ghost]

True. But in my mind that is a tad redundant and begs the question why set the os.environ into it's own dict in the first place.

I just was working within the code that was already set up by Valve and trying to avoid being opinionated. They're handling environment variables that way in the code, so maintain status quo unless another person wants to change it.

[Elkasitu]

they probably do so because they inject a bunch of variables into env that maybe they don't want to inject into the runtime environment, but they already do access os.environ further down in the code

[ghost]

Forgot to respond. I see yeah. I did not read their code completely. I glanced at it and did this in about 5 minutes. If you're pretty sure that is the intention I don't mind going with the approach of using os.environ 👍

[Elkasitu]

Btw your patch does not work for me, I know I'm supposed to mimick the file structure (dist folder, version file, default_pfx folder) but it still won't launch, does it work for you? If so, can you share your wine dir structure?

[ghost]

My local wine configuration (From lutris download):

.
├── bin
│   ├── function_grep.pl
│   ├── msidb
│   ├── msiexec
│   ├── notepad
│   ├── regedit
│   ├── regsvr32
│   ├── widl
│   ├── wine
│   ├── wine64
│   ├── wine64-preloader
│   ├── wineboot
│   ├── winebuild
│   ├── winecfg
│   ├── wineconsole
│   ├── winecpp -> winegcc
│   ├── winedbg
│   ├── winedump
│   ├── winefile
│   ├── wineg++ -> winegcc
│   ├── winegcc
│   ├── winemaker
│   ├── winemine
│   ├── winepath
│   ├── wine-preloader
│   ├── wineserver
│   ├── wmc
│   └── wrc
├── lib
│   ├── libwine.so -> libwine.so.1
│   ├── libwine.so.1 -> libwine.so.1.0
│   ├── libwine.so.1.0
│   └── wine
├── lib64
│   ├── libwine.so -> libwine.so.1
│   ├── libwine.so.1 -> libwine.so.1.0
│   ├── libwine.so.1.0
│   └── wine
└── share
    ├── applications
    ├── man
    └── wine

Dist structure:

dist
├── bin
│   ├── wine
│   ├── wine64
│   ├── wine64-preloader
│   ├── wine-preloader
│   └── wineserver
├── lib
│   ├── libopenal.so
│   ├── libopenal.so.1
│   ├── libopenal.so.1.18.2
│   ├── libwine.so.1 -> libwine.so.1.0
│   ├── libwine.so.1.0
│   └── wine
├── lib64
│   ├── libopenal.so
│   ├── libopenal.so.1
│   ├── libopenal.so.1.18.2
│   ├── libwine.so.1 -> libwine.so.1.0
│   ├── libwine.so.1.0
│   └── wine
├── share
│   ├── applications
│   ├── default_pfx
│   └── wine
└── version

There is a chance I might have missed something. This was just a rough draft from discussions on #22 Figured I'd open a PR for discussion. You can see some details in there on how the default_pfx wineprefix works.

As I said, i didn't test without having the default_pfx created. I'm not sure the process Steam takes to create that. It honestly looks like the default_pfx prefix is created via extraction of the proton_dist.tar.gz file.

Might need to just override the basedir for prefix related needs, and allow the basedir to remain default for the prefix , and give an override for now.

Line https://github.com/ValveSoftware/Proton/pull/697/files#diff-91df09b569af69b5e64d1506f50fa4bbR127 Leads me to think it SHOULD create the default_pfx

Can ya add some details with "It does not work"? Enable the logging https://github.com/ValveSoftware/Proton#runtime-config-options and let me know what it is saying.

[ghost]

I tried this again just now and did not notice steam seeing the game a 'running'. not sure how to approach that.

[ghost]

Created issue #724 (Steamclient dll) Hopefully there is some nice way to resolve it. I have commented in the IRC:

I wonder if just adding those two libs explicitly would allow for stuff to work ( I think you can add single files to the lib directory path, and that might* work for wine imports)

[Elkasitu]

Actually proton will copy the necessary steam client files into the wine prefix [1] so that shouldn't be a problem.

I tried debugging why it wouldn't work, first I found out that proton was crashing because it was trying to copy some vrclient dlls that are not in the lib/lib64 of a standard wine installation.

FileNotFoundError: [Errno 2] No such file or directory: '~/.local/share/lutris/runners/wine/esync-3.14-x86_64//dist/lib64/wine/fakedlls/vrclient_x64.dll'

So I ended up merging the libs from my lutris wine installation with the ones from the proton dist, and that seemed to work, kinda; Proton no longer crashes, but wine does:

3933.528:0008:0009:trace:module:load_builtin_callback loaded ntdll.dll 0x10790 0x7bc20000
3933.528:0008:0009:trace:module:load_builtin_dll Trying built-in L"kernel32.dll"
3933.529:0008:0009:trace:module:load_dll looking for L"ntdll.dll" in L""
3933.529:0008:0009:trace:module:load_dll Found L"C:\\windows\\system32\\ntdll.dll" for L"ntdll.dll" at 0x7bc20000, count=2
3933.529:0008:0009:trace:module:load_builtin_callback loaded KERNEL32.dll 0x10900 0x7b420000
3933.529:0008:0009:trace:module:LdrGetDllHandle L"kernel32" -> 0x7b420000 (load path (null))
3933.529:0008:0009:err:reg:create_key Cannot create \Registry\Machine\HARDWARE registry key
Warning: could not find DOS drive for current working directory '~/.local/share/Steam/steamapps/common/Fallout 3 goty', starting in the Windows directory.
pid 26953 != 26952, skipping destruction (fork without exec?)

[1] https://github.com/ValveSoftware/Proton/blob/proton_3.7/proton#L196

[ghost]

@Elkasitu So I've been working on something to make this PR more robust. I am going to have to do some re-installations, it seems, though. I've some reason stopped seeing environment variables get passed into my proton python file this morning in the midst of working on this.

I actually had something working, but I can't get the changes to work anymore. I got stopped at "No steamapps" error, regarding validation of onwership failing or something.

Steam was seeing the wine process running, and I was seeing everything pretty much work otherwise. Even had creation, and requirements.

The PR will be nasty, though. No "easy" solution for some of the issues I've noticed.

I've attached the diff here, if you want to have a play with it. I also added a really quick/dirty logging for the proton file. the version of git is not the same as the version on my linux system for some reason, so your miles may vary. I will work on this again later today if I get the time.

steam-wip-proton-diff.log

Unfortunately my work day begins now, so I can't invest more time. However I discovered I was running about 40 wine kingdomcome.exe processes, and numerous steam processes. My issues are very likely linked to not cleaning up my system regularly, and having some sort of weird issue due to that.

[ghost]

I'm taking an approach of:

• Remove nesting of the Proton specific functionality files, and the wine executable files
• Make proton script copy needed files to specified wine prefix
• Make proton copy extra dll.so files to the lib of specified wine location
• Keep format spec currently being used to avoid a huge PR moving stuff around

[aeikum]

The build system has been reworked since this. We describe how to use custom builds in the README now. Improvements welcome, but I think we're in decent state now.