> Do you mean by winelib dll that the wine/Liunux native .so style DLL > is built which is linked/imported through fakedlib to the application? > That looks like feasible solution and I would consider this solution > if there is interrest in the application in Linux community > and not enough resource is find to port it as full Linux native > version.
I don't know what "fakedlib" is. I know you can use LoadLibrary/GetProcAddress, or create a Windows DLL with the same abi and link to that. There may be some other way to generate a .lib file that I'm not aware of. > How is it with wine version dependency if the wine .so style DLL uses > only bunch of Linux calls (open, close, read, write, ioctl) and exports > some small set of the functions to the application? The abi for winelib .dll.so files has been stable for a long time, but of course such files will be specific to Linux and will also rely on the abi of libraries they import (including glibc, which means it's a good idea to build on a relatively old distribution for better compatibility). I think it's possible to rename the .dll.so file to .dll and put it with your application's files, if you don't want to ship your own version of Wine or require a special build. > I have done some more search to find narrow passes which limits > my initial idea of the driver based solution. I am sending my dump > there because it can be usesfull to somebody else (or even to me > if I find time one day and return to the problem). This goes over my head. It sounds like you know a lot about Windows drivers, and it's too bad you don't have time to help us with that.
