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

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.


> - 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.


> 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.


Cheers,
-- 
Rémi Bernon <[email protected]>