Very interesting.
I'd been suggesting to ISVs that they create a single winelib dll and conditionally load that if present, but winegate.dll might be an appealing alternative.
I don't think this really brings up any security considerations but it is a reminder that Windows programs under Wine have access to the entire Linux system just like Linux programs do.
btw nice name, but it pulls up 7 million hits for me, not sure what you mean by "google doesn't reveal any other uses of the name". - Dan
On Fr, 2009-02-13 at 22:44 -0800, Dan Kegel wrote:
Very interesting.
... but not needed
I'd been suggesting to ISVs that they create a single winelib dll and conditionally load that if present, but winegate.dll might be an appealing alternative.
Use wine_dlopen/wine_dlclose/wine_dlsym from libwine.dll It's much better (portable)
Dan,
On Sat, Feb 14, 2009 at 7:44 AM, Dan Kegel dank@kegel.com wrote:
I'd been suggesting to ISVs that they create a single winelib dll and conditionally load that if present, but winegate.dll might be an appealing alternative.
I think wine needs some universal library so as there is not 20 other ISV-specific solutions...
If wine-team decides not to include this (or similar .dll) in the Wine package, we'll just redistribute it with the application, but I think there is need for such library.
I don't think this really brings up any security considerations but it is a reminder that Windows programs under Wine have access to the entire Linux system just like Linux programs do.
btw nice name, but it pulls up 7 million hits for me, not sure what you mean by "google doesn't reveal any other uses of the name".
:-))) I was searching for "winegate.dll", not just plain winegate. I meant that there will likely be no collision with other .DLL.
Now it finds my post + some garbage. Google is damn fast.
Martin
2009/2/15 Martin Hinner martin@hinner.info:
If wine-team decides not to include this (or similar .dll) in the Wine package, we'll just redistribute it with the application, but I think there is need for such library.
You repeat yourself in another post:
2009/2/15 Martin Hinner martin@hinner.info:
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.
You obviously don't understand how Wine works. It's not in win32, nor is it in any other API standard Wine has to deal with (such as Directx). It won't be shipped with Wine. If you want to ship it with your product, that's your prerogative. If you want to release your project on public domain or under an open-source license such as LGPL, by all means.
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.
A standard like, for example, what was mentioned earlier with wine_dlopen stuff? I don't know all the details about winelib, but from what I understand you should be using those.
My feeling is that Linux desperately needs applications that currently run only on Windows.
It's my feeling that it doesn't. "Would be nice", yes, but nowhere near "desperately needs".
Companies will not use Linux if they cannot run their applications on it. It's like binary drivers.
No it's not.
Businesses in general have never been particularly receptive to stuff they don't already know (read Microsoft). Vendor lock-in contracts are quite common. Some contracts (probably most) bar businesses from installing any other operating system on any machine they run or suffer heavy fines. There's also cost of retraining staff, tech support, systems administrators ...
They are bad, but better than nothing. In an ideal world there would be no need for Wine anyway :-).
If you haven't noticed, we don't live in an ideal world. Wine has its uses, the set of which continues to increase.
Being able to run proprietary drivers where there is no way to run a device natively on Linux sounds good, but what you're talking about is essentially wrapping a win32 "driver" around native libs. It would be better for everyone involved if there was a fully-native Linux library that supports the device, with appropriate wrappers in winelib, possibly even using your winegate, if the companies really are that serious about supporting Linux systems.
On Sat, Feb 14, 2009 at 5:11 PM, Ben Klein shacklein@gmail.com wrote:
You obviously don't understand how Wine works. It's not in win32, nor is it in any other API standard Wine has to deal with (such as Directx). It won't be shipped with Wine.
I think that's not quite true. There are a couple supported wine extensions to win32, aren't there? I think there's an ioctl to get the unix path, or something... - Dan
2009/2/15 Dan Kegel dank@kegel.com:
On Sat, Feb 14, 2009 at 5:11 PM, Ben Klein shacklein@gmail.com wrote:
You obviously don't understand how Wine works. It's not in win32, nor is it in any other API standard Wine has to deal with (such as Directx). It won't be shipped with Wine.
I think that's not quite true. There are a couple supported wine extensions to win32, aren't there? I think there's an ioctl to get the unix path, or something...
From what I understand, they're not accessible to full win32 apps.
2009/2/15 Martin Hinner martin@hinner.info:
I understand this and in my opinion (if there will be any "official" WINEGATE.DLL)
I can't speak for the people who make these decisions in the Wine project, but I don't believe winegate is or will ever be a candidate for inclusion in Wine. If there's a good reason, it's thos:
Yes, the WINEGATE.DLL is not solving any problem on its own, it just simplifies "porting" process.
If it doesn't solve a problem, it doesn't make it much easier.
In any case, that's what winelib does too, you know, make porting easier. And from what I understand, you can just as easily use a winelib wrapper around a win32 application.
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.
If you foresee that you will have to maintain different versions of your library for different libc or Wine versions, you have big design flaws. It should "just work" without requiring maintenance. The Linux component may require a recompile on occasion to keep up with a change in libc (more likely frequent recompiling/code maintenance due to changes in the kernel every time you upgrade).
On Sun, 15 Feb 2009, Ben Klein wrote:
2009/2/15 Dan Kegel dank@kegel.com:
On Sat, Feb 14, 2009 at 5:11 PM, Ben Klein shacklein@gmail.com wrote:
[...]
I think that's not quite true. There are a couple supported wine extensions to win32, aren't there? I think there's an ioctl to get the unix path, or something...
From what I understand, they're not accessible to full win32 apps.
FWIW, it's kernel32.wine_get_unix_file_name(). So it's available to any Win32 application that knows about it. Just LoadLibrary()+GetProcAddress().
On Mon, Feb 16, 2009 at 12:14 PM, Francois Gouget fgouget@free.fr wrote:
From what I understand, they're not accessible to full win32 apps.
FWIW, it's kernel32.wine_get_unix_file_name(). So it's available to any Win32 application that knows about it. Just LoadLibrary()+GetProcAddress().
This is really nice end of our conversation, giving new dimension to all sharp statements (hack, not going into wine, etc) :-).
Just to add few comments at once, the problem is solved for us (libwinegate.dll.so is shipped with the software, we'll have to recompile it when libwine/libc changes...), so there is no need for other argumentation. I have already given up.
Regarding to maintenance of linux library, I meant to have different BINARY versions (because of other dependencies), not source code.
And finally regarding putting WINEGATE to some wiki: Feel free to do it, consider it public domain. But I think the point of this library was that if it is compiled WITH wine package, it would smoothly solve dependency problems (i.e. no need to carry separate WINEGATE-libcX-OSy-platformZ libraries).
Martin
2009/2/18 Marco Meijer marco@mandrivaclub.nl:
It is unfortunate that many discussions here on wine-devel to end this way. A new developer thinks he has solved a problem he has in wine, and wants to share the solution with the rest of the community. And 'the established' developers try to find as much issues they can find with the implementation to prove that what they have written has no problem but is so by design
Martin has raised an interesting issue. Should it be possible for a completely win32 application to explicitly load a Linux-native .so? I would argue "no, but a winelib application is another matter". Win32 exes and DLLs going direct to .so presents far too many problems for my tastes. The problems with this concept have already been discussed (such as calling conventions).
Maybe it would be better to to have a more constructive respond and to thank the developer for his attempt to share his work with the community
And after that then to see if:
- it is the right solution.
- needs a better implementation
- already has a implementation but needs better documentation.
- other.......
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.
2009/2/18 Martin Hinner martin@hinner.info:
The solution I have created is the cleanest possible way I think. If you decide to provide some GetProcAddress method to obtain any function location (or load library), let me know, we'll remove WINEGATE.DLL and change it to your way. Otherwise I think it's waste of time as you are not accepting that Win32 application should be able to load native Linux lib.
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.
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.
2009/2/17 Vincent Povirk madewokherd+8cd9@gmail.com:
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.
As I understand it, this isn't possible at present. If I'm wrong, I'd like to know :-)
(This is relevant to, e.g. malware analysis using Wine - where Wine-aware malware could easily just use int 0x80 to break out of the Wine environment. Which is one of the hazards of deliberately running toxic waste, and is why Zero Wine runs as a QEMU virtual machine rather than on the box directly, for a bit more safety.)
- d.
On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner martin@hinner.info wrote:
Just to add few comments at once, the problem is solved for us (libwinegate.dll.so is shipped with the software, we'll have to recompile it when libwine/libc changes...),
Wait, what can winegate do that
hdll = LoadLibraryA("libwine.dll"); wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); wine_dlclose = GetProcAdress(hdll, "wine_dlclose");
can't do? You really shouldn't need to ship winelib dlls. Can't you compile winegate as a real windows DLL that just knows about these special wine functions? - Dan
On Tue, Feb 17, 2009 at 3:34 PM, Dan Kegel dank@kegel.com wrote:
On Tue, Feb 17, 2009 at 4:35 AM, Martin Hinner martin@hinner.info wrote:
Just to add few comments at once, the problem is solved for us (libwinegate.dll.so is shipped with the software, we'll have to recompile it when libwine/libc changes...),
Wait, what can winegate do that
hdll = LoadLibraryA("libwine.dll"); wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); wine_dlclose = GetProcAdress(hdll, "wine_dlclose");
can't do? You really shouldn't need to ship winelib dlls. Can't you compile winegate as a real windows DLL that just knows about these special wine functions?
The above doesn't work ... LoadLibraryA fails (returns NULL). Tested both on fresh install from a package + latest source code build.
M.
On Tue, Feb 17, 2009 at 6:42 AM, Martin Hinner martin@hinner.info wrote:
hdll = LoadLibraryA("libwine.dll"); wine_dlopen = GetProcAdress(hdll, "wine_dlopen"); wine_dlsym = GetProcAdress(hdll, "wine_dlsym"); wine_dlclose = GetProcAdress(hdll, "wine_dlclose");
The above doesn't work ... LoadLibraryA fails (returns NULL).
Aha, you're right. libwine is shipped as an .so, not as a .dll.so.
But have a look at wine_dlopen and wine_dlsym, http://source.winehq.org/source/libs/wine/loader.c#L677 http://source.winehq.org/source/libs/wine/loader.c#L742 They really are very simple wrappers around Unix system calls. There's no reason you can't write your own wrappers in assembly inside your winegate, they would probably only be ten lines or so each. That would let you compile it as a real .dll instead of a winelib dll. It's possible this would be less of a maintenance hassle than shipping winegate as a winelib dll. - Dan
On Tue, Feb 17, 2009 at 3:56 PM, Dan Kegel dank@kegel.com wrote:
The above doesn't work ... LoadLibraryA fails (returns NULL).
Aha, you're right. libwine is shipped as an .so, not as a .dll.so.
But have a look at wine_dlopen and wine_dlsym, http://source.winehq.org/source/libs/wine/loader.c#L677 http://source.winehq.org/source/libs/wine/loader.c#L742 They really are very simple wrappers around Unix system calls. There's no reason you can't write your own wrappers in assembly inside your winegate, they would probably only be ten lines or so each. That would let you compile it as a real .dll instead of a winelib dll. It's possible this would be less of a maintenance hassle than shipping winegate as a winelib dll.
How do I get address of wine_dlopen/dlsym for the "assembly" part .DLL ? If I import it, how does PE loader know where to import from? I don't think this is possible ... except searching through memory, some Linux-only syscalls, etc.
The solution I have created is the cleanest possible way I think. If you decide to provide some GetProcAddress method to obtain any function location (or load library), let me know, we'll remove WINEGATE.DLL and change it to your way. Otherwise I think it's waste of time as you are not accepting that Win32 application should be able to load native Linux lib.
Martin
On Tue, Feb 17, 2009 at 8:56 AM, Dan Kegel dank@kegel.com wrote:
They really are very simple wrappers around Unix system calls. There's no reason you can't write your own wrappers in assembly inside your winegate, they would probably only be ten lines or so each.
According to the man page, dlopen() is a library call, not a system call. And a real .dll can't link to a native library, which is the problem we're trying to solve.
On Tue, Feb 17, 2009 at 7:10 AM, Vincent Povirk madewokherd+8cd9@gmail.com wrote:
On Tue, Feb 17, 2009 at 8:56 AM, Dan Kegel dank@kegel.com wrote:
They really are very simple wrappers around Unix system calls. There's no reason you can't write your own wrappers in assembly inside your winegate, they would probably only be ten lines or so each.
According to the man page, dlopen() is a library call, not a system call. And a real .dll can't link to a native library, which is the problem we're trying to solve.
*blush*
OK, so maybe we're back to the question: should wine be exporting wine_dlopen etc. via a PE DLL?
-
Ben Klein -
Dan Kegel -
David Gerard -
Detlef Riekenberg -
Francois Gouget -
Marco Meijer -
Martin Hinner -
Vincent Povirk