Re: Unixlib support for non-Wine binaries? (Or: would upstream Wine take a Spout2 to PipeWire bridge?)

On 1/21/26 6:02 PM, Rémi Bernon via Wine-devel wrote:
> Hi Lina,
> 
> On 1/17/26 10:35, Hoshino Lina via Wine-devel wrote:
>> Hi!
>>
>> I'm working on a tool to bridge Spout2 [1][2] to PipeWire. Spout2 is a 
>> windows-only frame-sharing technology widely used for video-streaming 
>> and mixing apps. It allows one app to send video to another, much like 
>> JACK does for audio on Linux (and now PipeWire for both A/V). For 
>> example, the majority of the VTubing/streaming world relies on Spout2 
>> to stream avatars and graphics on screen.
>>
>> To make this work, the bridge needs to use unixlib to do the bridging 
>> between the Windows and Linux worlds. I got it to build outside the 
>> Wine source tree by using just a few headers outside the public wine 
>> headers (unixlib.h, server.h, server_protocol.h). Originally I 
>> intended to distribute it as a simple installable that users could 
>> throw into their WINEPREFIX, but it turned out that for unixlib to 
>> work, the exe needs to be marked as builtin and distributed as a Wine 
>> builtin exe in wine/ x86_64-windows with the .so file in the companion 
>> x86_64-unix directory.
>>
>> - Would it make sense for Wine to change its unixlib loading code to 
>> work with non-builtin binaries, such as looking for the .so in the 
>> same directory as the .dll/.exe?
> 
> Regarding supporting unixlibs for non-builtin modules, it's probably a 
> up to Alexandre whether he thinks it's future proof and stable enough.
> 
> I believe we are now distributing wine/unixlib.h as part of public Wine 
> headers, so it seems to me that this is indeed the directions we are 
> taking.
> 
> It's perhaps then just a matter of time before it's officially 
> supported, or just a matter of someone proposing the changes to make it 
> work.

Oh, I'd totally missed that! I just checked and indeed in the Wine 11 
packages, unixlib.h is there so I don't have to ship it myself any more.

I think at that point it just becomes a matter of changing the search 
path for .so files a bit, so WINEDLLPATH is not necessary.

> 
> 
>> - Otherwise, would upstream Wine be interested in merging this 
>> feature? The main dependencies are PipeWire and libfunnel [3].
>>
>> The app does rely on some Wine/DXVK internals (unixlib, 
>> KeUserDispatchCallback, \??\SharedGpuResource, 
>> ProcessWineMakeProcessSystem) but it's not strictly necessary for 
>> those to remain stable across all future Wine releases, as making 
>> updates to stay compatible is not a major issue.
>>
> 
> Please note that the Proton shared memory resource implementation (\?? 
> \SharedGpuResource) is now deprecated, it will be removed in future 
> Proton releases and replaced with Wine upstream implementation through 
> the D3DKMT API, which DXVK also supports now.

Yeah, someone else also pointed this out to me the other day. I'll take 
a look and make sure I support both mechanisms.

> 
>> At this time I plan to distribute it as a "patch" that can be applied 
>> to Proton installations (which just drops in the exe/so and adds it to 
>> wine.ini). Another option is using WINEDLLPATH, which should work for 
>> regular Wine (this one is problematic on Proton since the Proton 
>> launcher unconditionally clobbers that environment variable).
>>
> 
> Fwiw, we can consider preserving the variable if set externally, it's 
> not really intentionally overwritten. Feel free to open a Proton MR.

Thanks! I've opened a PR here: 
https://github.com/ValveSoftware/Proton/pull/9420

~~ Lina