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.