November 2015 - Wine-Devel - list.winehq.org

Re: Revert "opengl32: Return a NULL pointer for functions requiring unsupported or disabled extensions.".

by Alex Henrie

2015-11-27 0:54 GMT-07:00 Alexandre Julliard <julliard(a)winehq.org>: > Sebastian Lackner <sebastian(a)fds-team.de> writes: > >> @Alexandre: Just to make sure I tested it in practice, and it indeed solves >> the bug. It would be acceptable but 1.8, but wouldn't solve >> https://bugs.winehq.org/show_bug.cgi?id=39563 for example. I am aware that >> its technically not a Wine bug, but it could still be solved by being less >> strict with extension filtering. Both MESA and NVIDIA return valid valid >> function pointers in this case. > > Actually I would argue that it is a Wine bug. If you can get a valid > function on Windows even when the extension is missing, you should get > one on Wine. Conversely, if you get a NULL pointer on Windows for a > missing function, you should get NULL on Wine too. > > This means that we have a responsibility to properly remap functions and > extensions between the Windows and the Unix side. We can't simply > forward to the Unix driver and hope that it happens to follow the > Windows semantics. After giving it some thought, I think this could work. As long as we're sure that suffixed functions behave identically to their unsuffixed counterparts, we should be able to return a function pointer to a suffixed function even though a unsuffixed function was requested (as long as the suffixed function is advertised in the extension list). This would match both: - Windows returning function pointers for unsuffixed functions even though the rest of the OpenGL version is not available - GLX providing no guarantee that calling a function not defined in the GL version or extension list won't crash the program, even though an unsuffixed equivalent could work fine And it would cleanly resolve bugs 38480 and 39563. -Alex

Nov. 27, 2015

Re: mshtml: Add IHTMLXMLHttpRequest::responseXML() method implementation. (try 2)

by Zhenbo Li

2015-11-14 17:33 GMT+08:00 Zhenbo Li <litimetal(a)gmail.com>: > > Also, I found that there was a hidden bug: > As we will test these urls for responseXML: > static const char xml_url[] = "http://test.winehq.org/tests/xmltest.xml"; > static const char large_page_url[] = > "http://test.winehq.org/tests/data.php"; > > char large_page_url is not a valid xml file, but native mshtml.dll can > handle it properly. It shows we can't just past the responseText to > msxml3.dll. I'll check it more carefully it later. Hi, sorry for my late reply. I tested it on testbot, and found that Windows mshtml.dll would return an empty xml object -- Have a nice day! Zhenbo Li

Nov. 27, 2015

Re: Revert "opengl32: Return a NULL pointer for functions requiring unsupported or disabled extensions.".

by Henri Verbeet

On 27 November 2015 at 08:18, Sebastian Lackner <sebastian(a)fds-team.de> wrote: > @Henri: Thanks for the explanation about the difference of wglGetProcAddress > and glXGetProcAddress, I wasn't aware that the Windows version works more > reliable, which explains why you would like to keep this part. Do you see > any other chance to implement a more general detection which functions are > available, than to rely on the extension string? Analyzing thunk wrappers, > or doing a test call with exception handler would probably work, but sounds > a bit too ugly. :/ > Nothing that's reliable. E.g. that a function doesn't crash when you call it doesn't mean it will actually work. And in the general case you would somehow need to construct a set of valid parameters.

Nov. 27, 2015

Re: winedbg: suppress bogus clone() frames in backtrace

by Alexandre Julliard

Daniel Santos <daniel.santos(a)pobox.com> writes: > Signed-off-by: Daniel Santos <daniel.santos(a)pobox.com> > --- > programs/winedbg/stack.c | 27 ++++++++++++++++++++++----- > 1 file changed, 22 insertions(+), 5 deletions(-) This is only hiding the bug. -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2015

Re: winedbg: suppress bogus clone() frames in backtrace

by Ralf Habacker

Am 26.11.2015 um 09:25 schrieb Daniel Santos: > Signed-off-by: Daniel Santos <daniel.santos(a)pobox.com> > --- > programs/winedbg/stack.c | 27 ++++++++++++++++++++++----- > 1 file changed, 22 insertions(+), 5 deletions(-) > > diff --git a/programs/winedbg/stack.c b/programs/winedbg/stack.c > index f49480a..8ef2dbc 100644 > --- a/programs/winedbg/stack.c > +++ b/programs/winedbg/stack.c > @@ -307,6 +307,11 @@ static void stack_print_addr_and_args(int nf) > im.ModuleName, (DWORD_PTR)(ihsf.InstructionOffset - im.BaseOfImage)); > } > > +static int addr_is_nonzero(const ADDRESS64 *addr) > +{ > + return addr->Offset && (addr->Mode != AddrModeFlat || addr->Segment); > +} > + > /****************************************************************** > * backtrace > * > @@ -322,12 +327,24 @@ static void backtrace(void) > dbg_curr_thread->curr_frame < dbg_curr_thread->num_frames; > dbg_curr_thread->curr_frame++) > { > - dbg_printf("%s%d ", > - (cf == dbg_curr_thread->curr_frame ? "=>" : " "), > - dbg_curr_thread->curr_frame); > - stack_print_addr_and_args(dbg_curr_thread->curr_frame); > + const unsigned nf = dbg_curr_thread->curr_frame; > + const ADDRESS64 *addr = &dbg_curr_thread->frames[nf].addr_frame; > + > + /* suppress bogus clone() frames from repeating */ Hi, any idea if the mentioned bug have the same reason https://bugs.winehq.org/show_bug.cgi?id=39606 Regards Ralf

Nov. 27, 2015

Re: Revert "opengl32: Return a NULL pointer for functions requiring unsupported or disabled extensions.".

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @Alexandre: Just to make sure I tested it in practice, and it indeed solves > the bug. It would be acceptable but 1.8, but wouldn't solve > https://bugs.winehq.org/show_bug.cgi?id=39563 for example. I am aware that > its technically not a Wine bug, but it could still be solved by being less > strict with extension filtering. Both MESA and NVIDIA return valid valid > function pointers in this case. Actually I would argue that it is a Wine bug. If you can get a valid function on Windows even when the extension is missing, you should get one on Wine. Conversely, if you get a NULL pointer on Windows for a missing function, you should get NULL on Wine too. This means that we have a responsibility to properly remap functions and extensions between the Windows and the Unix side. We can't simply forward to the Unix driver and hope that it happens to follow the Windows semantics. -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2015

Re: Revert "opengl32: Return a NULL pointer for functions requiring unsupported or disabled extensions.".

by Sebastian Lackner

On 27.11.2015 06:21, Alexandre Julliard wrote: > Henri Verbeet <hverbeet(a)gmail.com> writes: > >> Essentially, I think the number of affected users doesn't outweigh >> doing the correct thing in this case. > > Correct me if I'm wrong, but isn't this simply a matter of returning > glCopyTexSubImage3D if glCopyTexSubImage3DEXT is missing? That seems a > better solution than relying on quirks of the Nvidia driver. > > Could someone please give this a try so that we can solve this > regression for 1.8? > @Henri: Thanks for the explanation about the difference of wglGetProcAddress and glXGetProcAddress, I wasn't aware that the Windows version works more reliable, which explains why you would like to keep this part. Do you see any other chance to implement a more general detection which functions are available, than to rely on the extension string? Analyzing thunk wrappers, or doing a test call with exception handler would probably work, but sounds a bit too ugly. :/ @Alexandre: Just to make sure I tested it in practice, and it indeed solves the bug. It would be acceptable but 1.8, but wouldn't solve https://bugs.winehq.org/show_bug.cgi?id=39563 for example. I am aware that its technically not a Wine bug, but it could still be solved by being less strict with extension filtering. Both MESA and NVIDIA return valid valid function pointers in this case. Regards, Sebastian

Nov. 27, 2015

Re: Revert "opengl32: Return a NULL pointer for functions requiring unsupported or disabled extensions.".

by Henri Verbeet

On 27 November 2015 at 06:21, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Essentially, I think the number of affected users doesn't outweigh >> doing the correct thing in this case. > > Correct me if I'm wrong, but isn't this simply a matter of returning > glCopyTexSubImage3D if glCopyTexSubImage3DEXT is missing? That seems a > better solution than relying on quirks of the Nvidia driver. > I think so, yeah.

Nov. 27, 2015

Re: Revert "opengl32: Return a NULL pointer for functions requiring unsupported or disabled extensions.".

by Alexandre Julliard

Henri Verbeet <hverbeet(a)gmail.com> writes: > Essentially, I think the number of affected users doesn't outweigh > doing the correct thing in this case. Correct me if I'm wrong, but isn't this simply a matter of returning glCopyTexSubImage3D if glCopyTexSubImage3DEXT is missing? That seems a better solution than relying on quirks of the Nvidia driver. Could someone please give this a try so that we can solve this regression for 1.8? -- Alexandre Julliard julliard(a)winehq.org

Nov. 27, 2015

Re: Simplified local IP reordering patch for default routes

by Bruno Jesus

On Friday, November 27, 2015, Jamie Taylor <Jamie.Taylor(a)pobox.com> wrote: > On Thu, Nov 26, 2015 at 08:11:20PM +0800, Bruno Jesus wrote: > > Hi, Jamie and Joachim and list. This is a short version of a long > > patch I'm working on, it orders the IP list with the default routes on > > top and it supports more than one default route. It fixes the problem > > on Linux and FreeBSD, could anyone also test it on OSX, please? > > I am away from my test setup until next week due to the Thanksgiving > holiday in the USA, but I will do a test on OSX when I get back to it, > unless someone else has already reported results. Based on my reading > of the patch, I expect it will work to solve the problem of the magic > loopback address being returned as the first entry. Thanks for the feedback. I'll wait your or someone else tests. > Based on the results of the tests that Joachim shared with us, > I suspect a more correct approach (i.e., one that more closely matches > the results from Windows) may involve using GetIpAddrTable rather > than iterating over the IP forwarding table (except to figure out which > are the default routes) or using GetAdaptersInfo. Of course, the wine > implementation of GetIpAddrTable may also not match the behavior of > Windows when there are no adapters configured, but that may be a > problem whether or not WS_get_local_ips works correctly. > (I recognize that you are working on a larger patch which may address > this concern.) > The complete version of the patch solves the loopback issues by ignoring the loopback routes. The loopback is only added if it is the only IP found as in Windows. > Oh, and as for the reason the magic loopback address exists in the first > place, the best information that I could find was this thread on the list > from 2008, regarding the patch where it was introduced: > https://www.winehq.org/pipermail/wine-devel/2008-April/064835.html > and specifically this post: > https://www.winehq.org/pipermail/wine-devel/2008-April/ > <https://www.winehq.org/pipermail/wine-devel/2008-April/064850.html> > 064850.html > But now we won't return the loopback anymore so the first IP returned will be a valid network IP so this will no longer be necessary as far as I can see. Hope this helps, > Jamie > Best wishes, Bruno

Nov. 27, 2015