2015-09-27 21:00 GMT+02:00 Marcus Meissner <marcus(a)jet.franken.de>:
> Also regenerated opengl files, to exclude the glDebugMessageCallback functions.
>
> Signed-off-by: Marcus Meissner <marcus(a)jet.franken.de>
> ---
> dlls/opengl32/make_opengl | 6 +
> dlls/opengl32/opengl_ext.c | 343 +++++++++++++++++++++++++++++++++++++++----
> dlls/opengl32/opengl_ext.h | 5 +
> dlls/opengl32/opengl_norm.c | 90 +++++++++++-
> dlls/opengl32/tests/…
[View More]opengl.c | 96 +++++++++++-
> dlls/opengl32/wgl.c | 52 +++++++
> include/wine/wgl.h | 100 +++++++++++++
> include/wine/wgl_driver.h | 47 +++++-
> include/winternl.h | 5 +-
> 9 files changed, 708 insertions(+), 36 deletions(-)
> diff --git a/include/winternl.h b/include/winternl.h
> index 2fe2a2d..8e85eb4 100644
> --- a/include/winternl.h
> +++ b/include/winternl.h
> @@ -341,7 +341,10 @@ typedef struct _TEB
> PVOID GdiThreadLocaleInfo; /* 6fc/0870 */
> ULONG UserReserved[5]; /* 700/0878 */
> PVOID glDispachTable[280]; /* 714/0890 */
> - PVOID glReserved1[26]; /* b74/1150 */
> + PVOID glDebugCallback; /* b74/1150 */
> + PVOID glDebugCallbackAMD; /* b78/1158 */
> + PVOID glDebugCallbackARB; /* b7c/1160 */
> + PVOID glReserved1[23]; /* b80/1164 */
> PVOID glReserved2; /* bdc/1220 */
> PVOID glSectionInfo; /* be0/1228 */
> PVOID glSection; /* be4/1230 */
The callbacks should be per-GL context, that's why I mentioned the
struct opengl_context as a possibly suitable place to store the
application-provided callbacks.
The test should actually test something. You probably need to create a
debug context (the extension specifies that "For performance reasons
it is recommended, but not required, that implementations restrict
supporting this extension only to contexts created using the debug
flag as provided by WGL_create_context or GLX_create_context") and
enable the DEBUG_OUTPUT_SYNCHRONOUS_ARB flag. Also it would be
definitely nicer if the test is implemented in a separate function,
instead of stuffing it into START_TEST(opengl).
For the records, you can find the relevant extension spec at
https://www.opengl.org/registry/specs/ARB/debug_output.txt.
GL_KHR_debug specifies some further related bits but I think you can
mostly ignore that for this patch.
[View Less]
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=16891
Your paranoid android.
=== wvistau64 (32 bit font) ===
Failure running script in VM: network read timed out (Connect:AgentVersion.h:0/9)
Does anyone know a way to build DLLs at runtime?
Testing regsvr32.exe requires one or more DLLs, so I compiled a test DLL for use with the tests.
Apparently, the tests should be self-contained, meaning the DLL is produced at run-time. I'm assuming this is done for anyone using the winetest program.
I thought I could write the DLL manually, using IMAGE_NT_HEADERS and other structures. Unfortunately, I'm unable to write the required functions to the file. For one thing, functions have no size.
…
[View More]
Another method would be to build the DLL and use the linker to convert the DLL to an object file, link the binary in, and then output it at run-time.
Alternatively, I can leave the tests out of the source tree.
Opinions?
[View Less]
On 26.09.2015 22:11, Barrett Karish wrote:
> Test Program: https://bugs.winehq.org/attachment.cgi?id=35473
> ---
By test I meant a test integrated into wine tests, in this case it
should go to comctl32/tests/listview.c. Test should basically create
Listview of particular style, enable item text edit control and check
its style.
I think I tried that long time ago and test didn't confirm what appeared
to be obvious fix, but I might be wrong.
André Hentschel <nerv(a)dawncrow.de> wrote:
> + if (winetest_debug > 1)
> + trace("item #%u: fType %04x, fState %04x, wID %u, hSubMenu %p\n",
> + i, mii.fType, mii.fState, mii.wID, mii.hSubMenu);
Please use 4 spaces for indentation after 'if ()', not 8.
Also, what's the reason of this patch? There are several other similar
disabled debug traces in that file, anything special about this one?
And I'd suggest to simply replace if (0) …
[View More]by if (1) in the personal build
if you really need to see the traces.
--
Dmitry.
[View Less]
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://testbot.winehq.org/JobDetails.pl?Key=16855
Your paranoid android.
=== w1064 (32 bit usp10) ===
usp10.c:1244: Test failed: 0: uJustification incorrect (0)
usp10.c:1244: Test failed: 1: uJustification incorrect (0)
usp10.c:1244: Test failed: 2: uJustification …
[View More]incorrect (0)
usp10.c:1244: Test failed: 3: uJustification incorrect (0)
usp10.c:1244: Test failed: 4: uJustification incorrect (0)
usp10.c:1244: Test failed: 5: uJustification incorrect (0)
usp10.c:1244: Test failed: 6: uJustification incorrect (0)
usp10.c:1244: Test failed: 7: uJustification incorrect (0)
usp10.c:1244: Test failed: 8: uJustification incorrect (0)
usp10.c:1244: Test failed: 9: uJustification incorrect (0)
usp10.c:1260: Test failed: 3: uJustification incorrect (0)
usp10.c:1260: Test failed: 5: fDiacritic incorrect (1)
usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1)
usp10.c:1260: Test failed: 15: fDiacritic incorrect (1)
usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)
=== w1064 (64 bit usp10) ===
usp10.c:1244: Test failed: 0: uJustification incorrect (0)
usp10.c:1244: Test failed: 1: uJustification incorrect (0)
usp10.c:1244: Test failed: 2: uJustification incorrect (0)
usp10.c:1244: Test failed: 3: uJustification incorrect (0)
usp10.c:1244: Test failed: 4: uJustification incorrect (0)
usp10.c:1244: Test failed: 5: uJustification incorrect (0)
usp10.c:1244: Test failed: 6: uJustification incorrect (0)
usp10.c:1244: Test failed: 7: uJustification incorrect (0)
usp10.c:1244: Test failed: 8: uJustification incorrect (0)
usp10.c:1244: Test failed: 9: uJustification incorrect (0)
usp10.c:1260: Test failed: 3: uJustification incorrect (0)
usp10.c:1260: Test failed: 5: fDiacritic incorrect (1)
usp10.c:1260: Test failed: 5: fZeroWidth incorrect (1)
usp10.c:1260: Test failed: 15: fDiacritic incorrect (1)
usp10.c:1260: Test failed: 15: fZeroWidth incorrect (1)
[View Less]
Hi all,
I mentioned the concern on WineConf already and we quickly decided to
not care about win2k during WineConf test session. But there is more to
that: do we want to drop win2k support in our tests.
I think we do. We have extra code to handle it all over tests codebase.
Those are mostly skip()s + broken()s because, well, we don't care about
win2k results. And if we don't care, then what's the point to bother and
do the extra work.
Stefan mentioned that ddraw has differences between win2k …
[View More]and newer
version. That's true for other libraries as well. I don't think that's
enough for the reason to keep win2k supported. A real case where test
results on win2k was useful lately would be. Do we have an example of a
real (not theoretical) use of win2k tests in recent Wine development?
Thanks,
Jacek
[View Less]