[PATCH 1/4] dx8vb: Add stubs for D3DX8 interface

Stefan Dösinger stefandoesinger at gmail.com
Tue Oct 31 15:53:55 CDT 2017


Hi Fabian,

I'm not Henri, but I'll try to answer your questions:

Am 2017-10-31 um 20:48 schrieb Fabian Maurer:

>> Please don't typedef structures just to save keystrokes.
> 
> Mind explaining the reason for this? It's like this in a lot of other places, 
> and I'm curious to why you prefer it to not be a typedef.
Here I can mostly refer to the other d3d libraries (e.g. d3d8) that do
not use typedefs for structs. We had a discussion about this on
wine-devel a while ago that I could not find in the archive, but here's
e.g. the kernel's guide on this:
https://www.kernel.org/doc/html/v4.10/process/coding-style.html#typedefs .

I don't think we have an official policy, and as you correctly point out
a lot of Wine code (and Microsoft's headers) use typedefs. But since
Henri is the d3d maintainer his word counts here.

(It certainly isn't helpful that
https://wiki.winehq.org/Wine_Developer%27s_Guide/COM_in_Wine#Implementing_a_COM_interface.
contains loads of old suggestions)

>>> +static HRESULT WINAPI d3dx8_QueryInterface(ID3DX8 *iface, REFIID riid,
>>> void **ppv) +{
>>> +    d3dx8 *This = impl_from_ID3DX8(iface);
>>
>> Please use lowercase variable names.
> 
> Again, it's like this in 95% of all other cases. I'll change it if you want, I 
> just wanted it to remain consistent with the existing code.
Similarly I can only refer to ddraw/d3d8/9/10/11 here, but other places
in Wine certainly differ.

> Mind explaining why? The wiki states that "Messages in this class are meant to 
> signal unimplemented features, known bugs, etc. They serve as a constant and 
> active reminder of what needs to be done." This sounds fitting for me.
It's largely because some applications query various (sometimes even
app-internal) interfaces and expect a failure, e.g. as a way to detect
what kind of object they got out of their internal data structures.
Printing a FIXME in QueryInterface is just as likely to mislead a user
or developer into thinking the interface should be supported as it is to
point out a bug.

If you know an interface should be supported, e.g. through tests or
because the documentation says so, but you don't implement it, that
would be a case for a FIXME.

>>> +static HRESULT WINAPI d3dx8_CreateFont(ID3DX8 *iface, Direct3DDevice8
>>> *device, +          LONG hFont, D3DXFont **retFont)
>>
>> Please use lowercase parameter names, and avoid the stray 'h'.
> 
> I mostly just took the official names, want me to edit all of them? Wouldn't 
> be an issue for me, just need to know.
Yeah, we try to keep a distance from Microsoft's formatting as far as
possible without breaking compatibility. Renaming a parameter keeps the
code compatible to Microsoft's headers, but e.g. renaming a struct
member would break things.

This is mostly an issue for writing our own headers because it is
technically possible (but not allowed) to copypaste them from
Microsoft's headers.

> Maybe, I'm not good with trace formatting. Is there a list for which type I 
> should use what? I'd really appreciate that, maybe in the wiki? I didn't find 
> anything.
Flags are ORed bits. so %#x is the canonical way to print them. You'll
get output like 0x105 and see that there are flags 0x100, 0x004 and
0x001 set. With %i you get "261", which is much harder to read (256 | 4
| 1). (the # prints "0x105" instead of "105", which makes it clear that
it is a hexadecimal number)




More information about the wine-devel mailing list