WINEGATE.DLL: Wine gateway to native Unix libraries

[Ben Klein]

2009/2/14 Martin Hinner <martin at hinner.info>:
> Hi,
>
> On Sat, Feb 14, 2009 at 6:31 AM, Ben Klein <shacklein at gmail.com> wrote:
>> 2009/2/14 Martin Hinner <martin at hinner.info>:
>>>  Purpose of this Wine DLL is to allow Windows applications to use
>>> directly Unix library functions. This is useful  for example for
>>> applications which talk to specific drivers  and it's not
>>> efficient/possible to create system native DLL  for such driver or
>>> library. Win32 app. vendor is required only to detect execution under
>>> Wine and load proper native library.
>>
>> Windows apps don't call *nix libraries directly as is, so I'm not sure
>> I understand the purpose here. I can see it could potentially be
>> useful for porting apps using winelib, but I don't see how it can be
>> useful for full win32 apps precompiled for Windows systems.
>
> It is very useful for win32 apps in case you are dealing with hardware
> or some specific stuff. I am not talking about using this to fix wine
> bugs (i.e. creating a broken app).
>
> Think about application that is used for some industrial control, uses
> some USB device with vendor-specific driver (no hid, CDC, mass
> storage, etc). If you want to get it working on Linux, you have to
> either create complicated wrapper for your Windows drivers (which is
> in many cases impossible, btw) or you can use native linux driver,
> libusb, etc. Another good example is automotive diagnostics. And
> another example is FTDI FTD2xx drivers (although they have tried to
> maintain compatibility between Win/Linux/Mac versions, you have to use
> different routines on each system).

Wine is (or has been) working on a driver system to handle native
Windows USB device drivers via libusb, for things like printers and
scanners where there are no Linux-native drivers. This is a better
solution.

> All this is what WINEGATE.DLL sovles with minimum possible effort. You
> simply create class "CWin32Driver" "CLinuxWineDriver" and you're done.

Only when a suitable native Linux library already exists, correct?
There aren't many cases of this, from what I understand.

>>> I agree that in most cases it's better to fix Wine than applications,
>>> but there are real world problems that cannot be efficiently solved
>>> outside the application. One good example is when Win32 app has to
>>> talk to custom hardware. In many cases there are native Linux drivers
>>> that have different API/etc and it is very very difficult to create
>>> wrapper library between Windows-style and Linux/Unix-style drivers. In
>>> such cases it's much easier to modify source code of Windows app to
>>> use either Linux or Windows drivers/DLLs/etc.
>>
>> Why not use winelib for these cases if *nix support is important
>> enough to modify the source so it works nicer in Wine?
>
> Because sometimes you don't get enough customers to get paid for
> native Linux version and it's quite complicated to port even mid-sized
> projects using winelib. For example try to compile MFC ...

Given that for your system to work there has to be a Linux-native
library for winegate to hook into, the effort involved in porting to
Linux via winelib would likely be equal.