WINEGATE.DLL: Wine gateway to native Unix libraries

[Vincent Povirk]

> The problems with this concept have already been discussed
> (such as calling conventions).

This is a problem for trying to expose a linux .so as a windows .dll,
as the interface is almost never identical. It's not a problem for a
program that is explicitly written to use a linux .so.

> I believe all of those things have been looked at already, and
> generally has been decided that it's not the "right" solution, and
> that it really doesn't belong as a part of Wine's source tree.

Except that the "right" solution (using wine_dlopen and friends)
turned out to be impossible.

The "most correct" solution is to distribute Wine binaries, Windows
binaries, and a Winelib wrapper all together. Failing that, one should
distribute only Windows binaries, as Winelib binaries won't work
across Wine versions.

An interface to Linux libraries that Windows binaries can use and be
binary compatible across different Linux and Wine versions would be a
useful thing.

Even if we can't have it in Wine, an open source winelib bridge for
this (so that a user can supply a version that works on his own
system, and to avoid duplicating the work) would be nice.

> Well, can a native Linux lib be loaded on Windows? After all, Wine is
> an implementation of Win32, not a series of hacks to integrate Win32
> into the *nix-based host system.

My opinion on this particular issue doesn't matter, but we don't
strictly prevent Windows apps from seeing the underlying Linux
environment. Any app can make linux system calls, access the filename
conversion functions, invoke linux programs, and access the unix
filesystem using a wine-specific shell extension.