10:01adavy: linkmauve: hey
10:02adavy: Yes of course
10:03linkmauve: For now I’ve written an apitrace-like tool to record the win32 applications, and replay them in my driver natively on Linux.
10:04linkmauve: This is my state as of yesterday evening. :)
10:05linkmauve: I haven’t been able to generate a fake dll yet, despite having wine-nine-standalone as a base.
10:07adavy: looks promising
10:07adavy: What's the hurdle relative th the dll ?
10:08linkmauve: I’m not sure, perhaps the __cdecl/__stdcall difference?
10:09linkmauve: All of my symbols must be mangled to _func@bytes instead of func.
10:10linkmauve: Also, I guess it is expected, but d3d9-nine.dll.fake doesn’t expose its symbols in the exports section of the PE file, how else are applications supposed to obtain them?
10:14adavy: The call convention sure complicates things
10:14adavy: You'll notice that mesa implements all its externally visible functions using the win32 calling convention
10:14adavy: for none
10:15adavy: It's possible to not do that, and instead have the dll wrap all the mesa calls inside functions with the win32 calling convention
10:15adavy: but that means you need to wrap all calls and replace the vtable at all object creation
10:16adavy: We have done that for the 'nine for l4d2', etc but in reverse (basically the wrapper replaces with linux calls, haha)
10:16linkmauve: Hmm, I hadn’t noticed no, in the Mesa part I used the normal Linux/C/amd64 calling convention, which… might actually be an issue if I want to run an i686 Windows game. :-°
10:23linkmauve: Although this will make it harder for native Linux games to use it, since they’ll have to be recompiled against __stdcall which is completely foreign on Linux.
10:23adavy: Well if that's your objective you should handle the win32 wrapping in the wine dll
10:24adavy: This is how it is done the reverse way (for l4d2)
10:25linkmauve: I haven’t found a single native Linux game using this API though, aside from programs I’ve compiled myself. :-°
10:25linkmauve: Thanks. :)