Feature: Rewrite Winetricks

[R1kaB3rN]

We use Winetricks as a stop-gap to fix games. While it works, it is slow and is poorly designed (e.g., it hardcodes metadata within its script). One of the primary motivations of the rewrite is to speed up its execution time, so fixes can be installed faster when users launch their games. Optimizing for speed will be important, as more launchers will begin to adopt umu.

The rewrite would also feature fetching fixes remotely, probably from the Bottles database, as the metadata would be separated from the program.

See #125 (comment) for more context.

[R1kaB3rN]

@Root-Core For the future rewrite, I think we should look into using the Bottles CDN as our source for some of our verbs due to the recent breach. At least as fallback. At this point, users won't get fixes applied if they don't already have the source in their local cache.

[R1kaB3rN]

I also think using Python as the language is fine and sufficient, given the nature of what we're doing. Anything more lower-level or CPU-bound, we can link to Rust modules. Same with the rewrite being protonfixes dependent as ARM-based Protons will probably be a thing in the future (if Valve gets it right and doesn't abandon it). When that happens, Heroic will likely look to prefering Proton for their macOS users in the future and obsolete winetricks competely.

[R1kaB3rN]

To address some of the expected bottleneck from wine, I think https://github.com/awaken1ng/winetricksfast may be helpful here.

[Root-Core]

I think we should look into using the Bottles CDN as our source for some of our verbs due to the recent breach.

What breach do you mean? I think I missed that.

To address some of the expected bottleneck from wine, I think https://github.com/awaken1ng/winetricksfast may be helpful here.

Yes, that's similar to what I intended to do. Having some kind of batch will make things faster. As proton is invoked while the prefix isn't running, we should be able to just edit the files in it. So we don't need to call regedit etc.. I haven't done extensive testing yet.

Heroic will likely look to prefering Proton for their macOS users in the future and obsolete winetricks competely.

Hm.. that doesn't affect us directly I guess. Winetricks is also designed to be (more or less) OS independent, but it is a cumbersome behemoth as a whole. So we should also prepare ourselves to get rid of it.

[GloriousEggroll]

We discussed this in the OWC group. Ultimately I'm strongly against rewriting winetricks:

GloriousEggroll — 10/13/2024 10:50 AM
im not sure if rewriting winetricks is a good idea
thats a long standing project with its own upstream
and would be yet another component to maintain if rewritten

loathingKernel — 10/13/2024 10:52 AM
I agree with GE about winetricks. Unless it fixes something substantial, there is no reason to alienate other long-standing maintained projects that get a lot of testing.

[R1kaB3rN]

Rather than getting rid of winetricks immediately, I’m in favor of having at least including an experimental backend to allow users to opt in to the winetricks rewrite.

Because one of the biggest problems currently when applying fixes is that some take over 2+ minutes to apply the verb to the prefix (e.g. wmp11, allfonts, etc.). This adds to umu-launcher’s total launch time, and in my opinion, that’s an unacceptable amount of time especially when gaming on a handheld device when the launcher may not even provide a UI of the progress state. I’m pretty sure @strycore would be in favor of this too as I know they care about launch times.

As a side effect of increased execution speed, the rewrite would also allow us to leverage other programming libraries for functionality. This would allow applications (e.g., JunkStore, Lutris, etc.) to actually create good progress bars when fixes are being applied.

[R1kaB3rN]

cc @Heus-Sueh due to their expressed interest at #125

[Heus-Sueh]

I don't think it's a good idea to depend on a bash script, even if it's being tested and maintained correctly. The fact that the code is mixed in one place with the dependencies makes it a hell to maintain. For each dependency there's a function and that's insane.

This idea of ​​not messing with what's working is a double-edged sword.

But if that's the final decision, I don't have much to do. I don't think I could help make an experimental implementation in another language. I don't trust my programming skills (I might be able to try, but I can't guarantee much success). The most I could help would be with the documentation.

[Heus-Sueh]

There is this lib used by bottles that is practically ready:
https://github.com/bottlesdevs/libwine

[Root-Core]

This is more of a wrapper over Wine's executables, it doesn't really help much with our use case.

[mirkobrombin]

There is this lib used by bottles that is practically ready: https://github.com/bottlesdevs/libwine

It should be noted that we have never actually used this in Bottles, and it is not even similar to the backend Bottles currently has.

That being said, rewriting winetricks is challenging. I can see many benefits in doing so, but also several downsides. For example, using the Bottles repository would spare OWC from having to maintain each dependency since Bottles already handles them.. however, a major issue arises: Bottles' dependency manager is not standalone, it's integrated into Bottles' code. So, OWC would need to develop its own utility using our APIs and maintain it. Developing it is not the biggest issue.. maintaining it is and I think OWC has more important tasks rn.