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