WINEGATE.DLL: Wine gateway to native Unix libraries

[Martin Hinner]

VItaliy,

On Sun, Feb 15, 2009 at 3:21 AM, Vitaliy Margolen
<wine-devel at kievinfo.com> wrote:
> Depending on what you need to do it might be a good thing or might be a
> complete no-go. Remember that Wine has an additional layer on top of system.
> If you bypass it, you can potentially create lots and lots of problems.

I understand this. For ourselves, it is intended to gain access to
native Linux drivers. It would be nightmare to try to create wine dll
that would act as a wrapper between "virgin" Win32 app and Linux
driver.

> For example, handles, synchronization, GUI, messages, d3d, ddraw (and most
> other things) depend on those extra layers. You won't be able to use them
> together without major risk of instability. Eg. you can't pass fd to
> ReadFile(). Nor can you block on read() and expect message processing in the
> same thread. Not saying it can't be done. It just needs to be coded with
> consideration of Wine inerworkings.

I understand this and in my opinion (if there will be any "official"
WINEGATE.DLL) there should be documentation mentioning things like
this one. In addition there should be also functions to convert file
handles between posix & wine handles + path conversion tool (but we do
not need any of these, I mean they migh be useful to someone else).

> What I want to say, what you did is just an API that doesn't solve anything
> on its own. Anything using it will be as complex as writing winelib
> application. Or will have to be expanded to properly fit into Wine.

Yes, the WINEGATE.DLL is not solving any problem on its own, it just
simplifies "porting" process. Using it is NOT as complex as writing
winelib application, because you have to write only Linux-dependent
parts, the rest of application can remain untouched. Please note that
to my knowledge it is not even legal to create winelib application if
it is using some libraries such as MFC (depends on version, license,
etc.).

I think I have clearly explained in my previous posts what this
library should do and what would advantages of having it be. Now I
would like to hear if you (wine people) accept such solution and
include it in some way in Wine distribution. Currently I understand
there is no interest.

I don't want to be rude, but I have better things to do than
propagandize my solution. We can live without such library in Wine, it
would just require us to maintain separate libraries for different
libc or wine versions. Having it in wine distribution would solve this
problem smoothly, reducing our task only to maintain native Linux
shared lib for hardware access. If anything changes in your position,
let me know, I am willing to help with it.

Martin