I had an interesting thought the other day, and that is to having some built in support for forwarding windows dlls to linux .so's. A while back, I had worked on the CUDA wrapper, which basically just transfers the calls from the dll to so. At that point I didn't work on a CAL wrapper because there was not linux support from ATI with CAL. Now there is, and has been and someone has requested a CAL wrapper for folding@home. I've started the work on it but I have been thinking, that I think it might be benifical to have some sort of built in support in wine for this. A method for automatically sending calls made to a .dll to the linux counterpart .so, if one exist. The work involved with making a wrapper for CUDA or CAL isn't that much, it's fairly simple in the grand scheme of things. However I'm sure there must be a lot of 3rd party, non-microsoft libraries that have windows and linux counter parts, that both expect the same inputs and. I know wine already does a lot of this, but some sort of automation in the process, in which if a call is made to cudart.dll, wine sees it, and transfers the calls to cudart.so. The list of .dlls and respective .so s could simply be kept in the registry for easy editing, and adding of libraries without the need to recompile wine.
Hopefully I've put my idea across clearly. What are everyone's thoughts?
Thanks,
Seth Shelnutt
I had an interesting thought the other day, and that is to having some built in support for forwarding windows dlls to linux .so's. A while back, I had worked on the CUDA wrapper, which basically just transfers the calls from the dll to so. At that point I didn't work on a CAL wrapper because there was not linux support from ATI with CAL. Now there is, and has been and someone has requested a CAL wrapper for folding@home. I've started the work on it but I have been thinking, that I think it might be benifical to have some sort of built in support in wine for this. A method for automatically sending calls made to a .dll to the linux counterpart .so, if one exist. The work involved with making a wrapper for CUDA or CAL isn't that much, it's fairly simple in the grand scheme of things. However I'm sure there must be a lot of 3rd party, non-microsoft libraries that have windows and linux counter parts, that both expect the same inputs and. I know wine already does a lot of this, but some sort of automation in the process, in which if a call is made to cudart.dll, wine sees it, and transfers the calls to cudart.so. The list of .dlls and respective .so s could simply be kept in the registry for easy editing, and adding of libraries without the need to recompile wine.
Hopefully I've put my idea across clearly. What are everyone's thoughts?
Thanks,
Seth Shelnutt
Years ago we had this functionality is Wine. Next to 'builtin', 'native' we had an option 'so'. It worked for glide2x/glide3x but for the rest not for much other libs. It was dropped during some debugging rewrite if I rememeber correctly. I don't remember if it was due to maintenance issues or because of some technical issue.
Roderick
"Roderick Colenbrander" thunderbird2k@gmx.net writes:
Years ago we had this functionality is Wine. Next to 'builtin', 'native' we had an option 'so'. It worked for glide2x/glide3x but for the rest not for much other libs. It was dropped during some debugging rewrite if I rememeber correctly. I don't remember if it was due to maintenance issues or because of some technical issue.
It was removed because it's not worth the trouble. There are essentially no Unix libraries that are guaranteed to be binary compatible with the Windows version, so you always end up needing a wrapper anyway.
Hi, Wine once had a feature like this. In addition to load a DLL as builtin or native, there was a third option called "so", which loaded a native linux lib and looked for the symbols in there.
It was removed because it didn't really work. The main problem were +relay logs I think. The other issue are the calling conventions. In many cases a DLL call cannot be simply forwarded because the calling convention is different, or because the DLL works with filenames which have to be converted between Windows and Linux. So somewhen this feature was removed.
However, I think it would come handy in a few situations:
*) OpenAL *) Cuda & Friends *) PunkBuster *) glide?
On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote:
I had an interesting thought the other day, and that is to having some built in support for forwarding windows dlls to linux .so's.
IIRC, this kind of thing is generally discouraged, except in cases where needed (eg. opengl32). Part of the problem is internal differences.. for example, what would a Linux .so do if it's given a Win32 filename path? Other problems would be if the Linux equivalent wants a Window for a function argument and the DLL wants an HWND instead, or if the DLL has more/different functions (eg. CUDA on Win32 has functions for dealing with D3D objects; CUDA on Linux doesn't, and it wouldn't be straight forward to even implement them through wined3d).
Something like OpenGL, and even OpenAL to some degree, would directly benefit from having the DLLs forwarded to their host equivalents as it provides better access to the hardware and better integration with the host system. Something like zlib or ogg/vorbis and stuff wouldn't though, since the code should largely be the same, and save for some bugs/inefficiencies in Wine (which should be fixed), would work identically.
-
Alexandre Julliard -
Chris Robinson -
Roderick Colenbrander -
Seth Shelnutt -
Stefan Dösinger