[PATCH] Revert "include: Use the ARRAY_SIZE() macro in debug.h."

[Axel Davy]

On 18/11/2018 22:32, Henri Verbeet wrote:
> On Mon, 19 Nov 2018 at 00:12, Andre Heider <a.heider at gmail.com> wrote:
>>>> Apart from the debug channels, we use these too: toupperW() (unicode.h)
>>>> wine_dlopen() (library.h), and I guess a few more.
>>>>
>>> Again, what are you doing exactly that you need those?
>>>
>>>> Are the specific reasons to not expose those useful functions to
>>>> external projects?
>>>>
>>> I'm sure we'd consider it if there was a demand for them. As it is
>>> though, there's no guarantee those won't go away between releases, or
>>> change in incompatible ways, etc. Depending on what you're using them
>>> for, chances are that you should either be using the official Win32
>>> APIs, or just be defining __WINESRC__. Perhaps you're doing something
>>> unusual enough that neither of those is an option, but in that case
>>> we'd be curious to learn more details.
>> The result hopefully won't be unusual ;) This is about Gallium Nine. As
>> you might know, it's currently distributed as patches on top on wine. I
>> extracted the relevant code pieces into its own repository to make it a
>> standalone project, independent of wine - but built as a winelib project.
>>
>> That's why there're various uses of wine specific headers and functions.
>> But you made me dig up the reason for using those (it's not my code
>> base) - and I don't see one, heh. I could replace all the minor stuff
>> with either win32 or libc alternatives. The only thing left now is the
>> debug channel stuff.
>>
>> It would be nice if I could just use that too, but it shouldn't be too
>> much work to use something different. Maybe just plain old
>> OutputDebugString()?
>>
> It would probably make most sense to use the Mesa/Nine debug
> functions, although for something like Nine, I don't think simply
> defining __WINESRC__ would be all that bad. I think things like using
> ExtEscape() to get at winex11 internals are more problematic. (I
> suspect that could be avoided, but historically I don't think the Nine
> developers have been very excited to discuss that particular aspect;
> perhaps that has changed.)
>
>
Hi,


Rest assured, we don't use ExtEscape to get winex11's dc_rect (which 
required specific patches indeed) since sometime around "7 Jan 2017" 
(date of the patch I can find in the log, but we may have had earlier 
patches).

We do still use it of course to get the X drawable because we need to 
present to the screen somehow, and it would be quite inefficient to 
trigger a copy via opengl for that, while we have support for the X 
Present interface enabling fine vsync behaviour. I doubt you would be 
interested we merge our work to winex11, but I may be wrong ?

Fortunately getting the X drawable doesn't require to patch wine, which 
means we can add nine on top of any wine installation.


Yours,


Axel Davy