2009/2/14 Martin Hinner martin@hinner.info:
Hi,
On Sat, Feb 14, 2009 at 6:31 AM, Ben Klein shacklein@gmail.com wrote:
2009/2/14 Martin Hinner martin@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.