wine-devel September 2015

wine-devel@winehq.org

73 participants
180 discussions

Re: [PATCH] opengl32: use thunks for glDebugMessageCallback
by Matteo Bruni 28 Sep '15

28 Sep '15

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/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.

1 0

How to add the Signed-off-by field in the git patch
by Dmitry Timoshkov 28 Sep '15

28 Sep '15

Hi all, since I personally asked that question and investigated a bit the subject, here is some information that could be probably useful to someone else: http://stackoverflow.com/questions/13457203/how-to-add-the-signed-off-by-fi… http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… http://stackoverflow.com/questions/15015894/git-add-signed-off-by-line-usin… http://git-scm.com/docs/git-format-patch (CONFIGURATION section) Personally I've chosen to add [format] signOff = true to git.config file. -- Dmitry.

5 4

Re: [PATCH] gdi32/freetype: Handle fonts with broken usWinDescent values
by Marvin 28 Sep '15

28 Sep '15

2 1

Help building a DLL at run-time
by Hugh McMaster 28 Sep '15

28 Sep '15

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. 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?

1 0

Re: [PATCH v2] comctl32: Fix sizing of edit window for listview icon view
by Nikolay Sivov 27 Sep '15

27 Sep '15

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.

1 0

Re: user32/tests: Allow tracing in menu test
by Dmitry Timoshkov 26 Sep '15

26 Sep '15

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) by if (1) in the personal build if you really need to see the traces. -- Dmitry.

4 4

prelink (needed to compile wine) missing on Fedora 23
by Zhenbo Li 26 Sep '15

26 Sep '15

Hello, I installed Fedora 23 Alpha to my computer, and tried to compile wine today. After running "./configure", I got this in my terminal configure: WARNING: prelink not found, base address of core dlls won't be set correctly. The reason is that prelink has been obsoleted since Fedora 23[1] There is a successful build for wine on Fedora23[2], and it seems that that package has been affected by missing prelink too.[3] Is this a critical problem? Should I ignore this WARNING, or try to fix it? Thank you [1]: https://admin.fedoraproject.org/pkgdb/package/prelink/ [2]: http://koji.fedoraproject.org/koji/buildinfo?buildID=683683 [3]: https://kojipkgs.fedoraproject.org//packages/wine/1.7.51/1.fc23/data/logs/x… -- Have a nice day! Zhenbo Li

3 4

Re: ntdll: Fix for 64-bit builds (at least on OSX)
by Charles Davis 25 Sep '15

25 Sep '15

Hang on; I have a better patch. (I wanted to send it earlier, but the SMTP connection kept unexpectedly closing.) Chip

2 2

Re: [PATCH] usp10/tests: Catch case where enumerated font name is too long
by Marvin 25 Sep '15

25 Sep '15

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 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)

1 0

Dropping support for win2k in tests
by Jacek Caban 25 Sep '15

25 Sep '15

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 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

1 0

← Newer
1
2
3
4
5
6
7
...
18
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2015