Hello,
I have created a small library to allow Win32 applications running under Wine to load native Unix shared libraries (.so). First (one-hour hack) version is available at http://martin.hinner.info/tmp/winegate.tar.gz ; Please consider inclusion in WINE tree (dll/ directory). Please note that Makefile.in as well as configure scripts will likely need some changes.
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.
WinGate.DLL exports dlopen/dlsym/dlclose/dlerror functions which allow Windows app to load additional libraries and use them.
This library should export all functions that are required to load additional libraries and detect type & version of system we're running on. I believe that NO additional functions are required as you can always import uname() and call it to obtain more information on the running system, so dlopen/dlsym/dlclose is enough. Maybe some 'getwineversion' function should be included - waiting for your comments.
I am sure there will be a lot of people arguing that Win32 application SHOULD NOT be modified to behave differently in Wine. 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.
Example how to use WINEGATE.DLL is in winesupp.zip (please note this is quite silly example). If you want to see real world application which uses this library, go to http://www.jtagtest.com
I have chosen name Wingate because google did not reveal any other use of such name and I think it fits it's purpose. Feel free to suggest any other names or just rename the library.
Martin
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.
I am sure there will be a lot of people arguing that Win32 application SHOULD NOT be modified to behave differently in Wine.
The main reason for this is if the win32 app depends on some function of Wine caused by a bug or missing feature, then a future version of Wine will break the application (because the application is already broken, and only behaves correctly under broken Wine).
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?
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).
All this is what WINEGATE.DLL sovles with minimum possible effort. You simply create class "CWin32Driver" "CLinuxWineDriver" and you're done.
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 ...
Martin
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.
Ben,
On Sat, Feb 14, 2009 at 7:10 AM, Ben Klein shacklein@gmail.com wrote:
2009/2/14 Martin Hinner martin@hinner.info: 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.
Yes, but it is only for some devices. I will give you again one example I was mentioning: FTD2XX.DLL driver from FTDI. They have versions for many systems, but these behave a little bit different way. Tell me how would you solve this problem. Write a complicated libftd2xx.dll.so wrapper to maintain compatibility ? For how many applications would it work? There are thousands of similar problems between Win32-Linux world. Do you think that ISVs will find budget for this to support Linux or just not do it?
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 think it's more cases than you think. I can give a lot of examples, but that would be "spamming" of this mailing-list.
Just one more thing, I tried one of our applications using HID-usb device. Does not work under Wine. I have no idea why, it's probably possible to fix the problem (in wine), but this clearly shows that world is not always ideal.
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.
I disagree...
I am not pushing on WINEGATE.DLL inclusion in Wine package. If it's not included, we'll include it in our installers and problem is solved. But I think other developers need such library to make their apps. working under Wine and it's much better to have one "standard" and well documented library than 10 or 20 proprietary solutions. I understand it is not clean solution, but world is not perfect.
If it's included, I am willing to help with maintenance and write some documentation.
My feeling is that Linux desperately needs applications that currently run only on Windows. Companies will not use Linux if they cannot run their applications on it. It's like binary drivers. They are bad, but better than nothing. In an ideal world there would be no need for Wine anyway :-).
Martin
On Sa, 2009-02-14 at 05:39 +0100, Martin Hinner wrote:
Hello,
I have created a small library to allow Win32 applications running under Wine to load native Unix shared libraries (.so). First (one-hour hack) version is available at http://martin.hinner.info/tmp/winegate.tar.gz ; Please consider inclusion in WINE tree (dll/ directory). Please note that Makefile.in as well as configure scripts will likely need some changes.
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.
WinGate.DLL exports dlopen/dlsym/dlclose/dlerror functions which allow Windows app to load additional libraries and use them.
Hi Martin. Thanks for your interest in Wine. I read your Mail, and my first impresion was: not needed
After downloading winegate.tar.gz and reading the source: winegate is a nice Idea, but it's useless.
Why? - Your proxy code is not portable. - It's already present in Wine: libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym please read: libs/wine/loader.c
On Sun, Feb 15, 2009 at 12:35 AM, Detlef Riekenberg wine.dev@web.de wrote:
On Sa, 2009-02-14 at 05:39 +0100, Martin Hinner wrote: Hi Martin. Thanks for your interest in Wine. I read your Mail, and my first impresion was: not needed
After downloading winegate.tar.gz and reading the source: winegate is a nice Idea, but it's useless.
Why?
- Your proxy code is not portable.
I am aware of this, it was proof-of-concept, I am definitely NOT against using wine_dlopen or add #ifdefs to make it portable (for systems not having dlfcn.h).
- It's already present in Wine:
libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym please read: libs/wine/loader.c
I saw it, but I don't understand how is it exported to the "Win32 world", i.e. how do I import these using GetProcAddress() Win32 API ?
find /usr/src/wine* -name '*.spec' | xargs -n 10 grep dlopen did not reveal anything except winegate.dll :-).
Martin
Martin Hinner wrote:
On Sun, Feb 15, 2009 at 12:35 AM, Detlef Riekenberg wine.dev@web.de wrote:
- It's already present in Wine:
libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym please read: libs/wine/loader.c
I saw it, but I don't understand how is it exported to the "Win32 world", i.e. how do I import these using GetProcAddress() Win32 API ?
They are not part of any Wine "dll" so you can't get their address that way. They meant to be used by Wine itself or winelib apps.
Vitaliy.
On So, 2009-02-15 at 01:02 +0100, Martin Hinner wrote:
- It's already present in Wine:
libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym please read: libs/wine/loader.c
I saw it, but I don't understand how is it exported to the "Win32 world", i.e. how do I import these using GetProcAddress() Win32 API ?
As I already mentioned:
libwine.dll has exports for wine_dlopen/wine_dlclose/wine_dlsym
Just use this infos: hdll = LoadLibraryA("libwine.dll"); wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); wine_dlclose = GetProcAdress(hdll, "wine_dlclose");
Keep attention on the calling convention.
find /usr/src/wine* -name '*.spec' | xargs -n 10 grep dlopen did not reveal anything except winegate.dll :-).
A "*.spec" is used as input for winebuild to build a "*.def". Keep it as simple as possible and use only grep: "grep -r dlopen <wine-source>/libs/" You find the exported functions in "libs/wine/wine.def"
Detlef,
On Sun, Feb 15, 2009 at 12:50 PM, Detlef Riekenberg wine.dev@web.de wrote:
Just use this infos: hdll = LoadLibraryA("libwine.dll"); wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); wine_dlclose = GetProcAdress(hdll, "wine_dlclose");
The LoadLibraryA call does not work for me. Tried with many names (wine,libwine, etc) and wine is according to strace always trying to open /usr/lib/wine/{lib}libwine.dll.so which is not obviously present.
M.
Martin Hinner wrote:
Hello,
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.
WinGate.DLL exports dlopen/dlsym/dlclose/dlerror functions which allow Windows app to load additional libraries and use them.
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.
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.
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.
Vitaliy.
VItaliy,
On Sun, Feb 15, 2009 at 3:21 AM, Vitaliy Margolen wine-devel@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
Martin Hinner wrote:
reducing our task only to maintain native Linux shared lib for hardware access.
Which means you'll have to maintain it anyway. No, what you proposed not going to fly. It can not work within Wine. It's called "hack" and things with that name not getting into Wine.
Vitaliy
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
So now and then things come by which would be useful for some Wine users / developers but which aren't suited for inclusion in Wine. Nonetheless I think we need a place where such things can be stored. Perhaps that should be done on the Wine wiki (not sure if we can upload files to there). I can imagine that we should put a porting page there and mention winelib and winegate.
Roderick
On Sun, Feb 15, 2009 at 3:37 AM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
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
So now and then things come by which would be useful for some Wine users / developers but which aren't suited for inclusion in Wine. Nonetheless I think we need a place where such things can be stored.
http://code.google.com/p/winezeug/ ?
-
Austin English -
Ben Klein -
Detlef Riekenberg -
Martin Hinner -
Roderick Colenbrander -
Vitaliy Margolen