13:42 linkmauve: Hi, I’m working on yet another Mesa frontend, for another API, and I’m a bit stuck wrt how to expose it as a dll for Wine usage.
13:43 linkmauve: I currently generate a .so which exposes the relevant symbols, and which Linux versions of these games can use, but so far besides SDK samples I haven’t found any actual Linux game. ^^'
13:44 linkmauve: Oh hmm, maybe I could just take your wine-nine-standalone and adapt it to my API?
14:54 linkmauve: Until now I haven’t paid any attention to winsys integration, my frontend dumps a .bmp file at each buffer swap; should I implement support for dri2 or is dri3 supported widely enough nowadays?
14:54 linkmauve: Also about winsys integration, I currently use Collabora’s wayland branch of wine, do I need to do anything special in the wrapper to support it?
15:18 linkmauve: In wine-nine-standalone, I replaced all functions in the .spec file with mine, and added very simple stubs only calling fprintf(stderr, "%s()\n", __func__), renamed the .dll.fake to .dll like it’s done in the ArchLinux package, but wine doesn’t seem to be able to resolve the symbols. How can I check that I did it correctly?
15:19 linkmauve: I had a look at the exports from said dll, but there is no exports section (neither in the d3d9-nine.dll.fake before my changes).
15:55 linkmauve: I succeeded in creating a dll, by compiling my stub printf file with i686-w64-mingw32-gcc, prefixing all function names with an underscore, and setting them as __stdcall __declspec(dllexport).
15:56 linkmauve: This is obviously not gonna fly, especially since mingw32 doesn’t know how to dlopen() a .so.
15:56 linkmauve: But at least I have a baseline of a “working” dll.