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

Re: winhlp32 implementation

by Frank Richter

On 02.11.2006 22:04, Eric Pouech wrote: > Kirill K. Smirnov wrote: > >> Eric, >> there is a mess in winhelp and winhlp32 in "Context" and "Topic" concept: >> what winhelp calls "topic", winhlp32 calls "context", and what winhelp >> calls "Context" winhlp32 calls "Topic without CNT section". >> So, the buttons are messed too. >> >> I suspect there are other "features". >> >> We couldn't implement winhlp32 and winhelp in one box. >> >> > well, this still could be possible, even if it's a bit more complex to > handle > IMO, the differences are, in most of the cases, cosmetics (name of > buttons, positions of menu), but also in MS way, new features only in > winhlp32 > so I was calling for a unified tool that would be doing what the two > original programs were doing, even if the user interface doesn't match > everything perfectly FWIW, winhelp.exe is a 16-bit executable in Win XP. If I had to guess why, I'd say it's for compatibility: iirc you can call DLL functions from help files; so the 16-bit winhelp is kept to allow 16-bit .hlp files using DLLs to continue to work. -f.r.

Nov. 2, 2006

Re: Patch for opengl32.dll.so

by Bertrand Coconnier

Roderick Colenbrander wrote : > Hi, > > I think that the patch which I just sent titled 'X11DRV: opengl init fix' should fix the issues. The patch makes sure that opengl is initialized when x11drv wgl functions are called. > > Regards, > Roderick Your patch works OK for me. It fixes the crash when lauching WoW in OpenGL mode. Thanks, Bertrand.

Nov. 2, 2006

Re: Patch for opengl32.dll.so

by Roderick Colenbrander

> Roderick Colenbrander wrote: > >> Roderick Colenbrander wrote : > >> > >>>> On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> The last release of Wine 0.9.24 contains an error in the code of > >>>>> > >>>> opengl32.dll.so > >>>> > >>>>> under X11 : Wine tries to get the address of "wglGetIntegerv" (line > >>>>> > >> 608 > >> > >>>> of > >>>> > >>>>> dlls/opengl32/wgl.c) before the extensions of WGL have actually been > >>>>> > >>>> loaded > >>>> > >>>>> (i.e. before X11DRV_WineGL_LoadExtensions() is called). The reading > of > >>>>> > >>>> the > >>>> > >>>>> wglGetIntegerv address fails and afterwards, whenever > >>>>> > >>>> internal_glGetIntegerv() > >>>> > >>>>> is called, wine_wgl.p_wglGetIntegerv is NULL and a Fatal Exception > is > >>>>> > >>>> raised. > >>>> > >>>> > >>>> This is probably already fixed in the git tree. See the commit: > >>>> winex11.drv: Fixed the prototype of many OpenGL functions. > >>>> > >>>> Jesse > >>>> > >>> Else if the problem still happens something strange is going as the > >>> > >> extensions are registered at x11drv startup. > >> > >>> Roderick > >>> > >> Yes, the problem still happens because the function process_attach() > (line > >> 582 > >> of dlls/opengl32/wgl.c) is called before the x11drv startup. The > comment > >> of > >> process_attach is very clear : "/* This is for brain-dead applications > >> that use > >> OpenGL functions before even creating a rendering context.... */". It > is > >> clear > >> that process_attach is a workaround for *brain-dead* apps :) and among > >> other > >> things it gets the address of wglGetIntegerv. This operation used to > >> succeed as > >> long as GetProcAddress() was used but now since x11drv is needed to > upload > >> the > >> wglGetIntegerv address there is some kind of race condition and the > >> operation > >> fails hence the bug. > >> > >> Bertrand. > >> > > > > Compared to 0.9.23 I changed the way wglGetIntegerv is loaded before it > was directly loaded using GetProcAddress from winex11.drv now it is still > loaded from winex11.drv but then using wglGetProcAddress from gdi32. At wine > startup (I'm not sure at which stage but I believe directly when you use > gdi stuff or perhaps even earlier) winex11.drv is initialized and during > this initialization my opengl code is initialized aswell. I wonder what causes > the race as I haven't seen it happening for other users yet. I want to > avoid a patch like yours as I plan to do similar things for some other > functions. > > > > Perhaps something goes wrong in wglGetProcAddress itself. Try running > wine using: WINEDEBUG=+wgl,+opengl wine wow.exe -opengl &> log. If it is > correct you'll see some opengl information (gl version, loading of extensions) > before stuff happens in opengl32.dll. > > > > Roderick > > > Hi Roderick, do you have a patch for this problem, since 0.23 a number > of wow users seem to be getting a crash at startup that didn't happen > before 0.23 or 0.22, can't remember which, only some users not all. > > I just wondered if this is the fix for it, if we could try it out ? > > Regards > Nick > Hi, I think that the patch which I just sent titled 'X11DRV: opengl init fix' should fix the issues. The patch makes sure that opengl is initialized when x11drv wgl functions are called. Regards, Roderick -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

Nov. 2, 2006

Re: winhlp32 implementation

by Eric Pouech

Kirill K. Smirnov wrote: > Eric, >there is a mess in winhelp and winhlp32 in "Context" and "Topic" concept: >what winhelp calls "topic", winhlp32 calls "context", and what winhelp >calls "Context" winhlp32 calls "Topic without CNT section". > So, the buttons are messed too. > >I suspect there are other "features". > >We couldn't implement winhlp32 and winhelp in one box. > > well, this still could be possible, even if it's a bit more complex to handle IMO, the differences are, in most of the cases, cosmetics (name of buttons, positions of menu), but also in MS way, new features only in winhlp32 so I was calling for a unified tool that would be doing what the two original programs were doing, even if the user interface doesn't match everything perfectly >I suggest to at least get rid of old winhelp interface in favor of winhlp32, >and create symlink winhelp->winhlp32 in windows directory. >Does it save the day? > > > >>IMO, we don't need two apps but we could make most apps believe both >>winhelp & winhlp32 are present and put all effort into a single application >>we should also reimplement winhelp based on richedit for the rendering >>A+ >> >> > >richedit sound very good - select/copy very easy! (but riched32 is not >complete yet) > > yes, but we would kill two birds with one stone: - winhelp/winhlp32 requests a good rtf renderer (lots of layout stuff is still missing from winhelp), so this needs some work - richedit is a rtf renderer/editor so it's easier to add the missing stuff to richedit rather than reinventing the wheel in winhelp A+

Nov. 2, 2006

Re: comctl32: Don't free user32 objects with a gdi32 function in imagelist test.

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Use DestroyIcon for releasing the resources associated with created icons. That's probably correct, but it causes the test to fail: ../../../tools/runtest -q -P wine -M comctl32.dll -T ../../.. -p comctl32_test.exe.so imagelist.c && touch imagelist.ok imagelist.c:344: Test failed: icon 1 wasn't deleted imagelist.c:345: Test failed: icon 2 wasn't deleted imagelist.c:346: Test failed: icon 3 wasn't deleted imagelist.c:380: Test failed: icon 1 wasn't deleted imagelist.c:381: Test failed: icon 2 wasn't deleted imagelist.c:382: Test failed: icon 3 wasn't deleted make[2]: *** [imagelist.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

Nov. 2, 2006

Re: Patch for opengl32.dll.so

by Bertrand Coconnier

Roderick Colenbrander wrote : > Compared to 0.9.23 I changed the way wglGetIntegerv is loaded before it was directly loaded using GetProcAddress from winex11.drv now it is still loaded from winex11.drv but then using wglGetProcAddress from gdi32. At wine startup (I'm not sure at which stage but I believe directly when you use gdi stuff or perhaps even earlier) winex11.drv is initialized and during this initialization my opengl code is initialized aswell. I wonder what causes the race as I haven't seen it happening for other users yet. I want to avoid a patch like yours as I plan to do similar things for some other functions. > > Perhaps something goes wrong in wglGetProcAddress itself. Try running wine using: WINEDEBUG=+wgl,+opengl wine wow.exe -opengl &> log. If it is correct you'll see some opengl information (gl version, loading of extensions) before stuff happens in opengl32.dll. I have attached the log file that you have requested. I think it makes everything clear : the cause of the failure appears at the very beginning (line 2), X11DRV_wglGetProcAddress fails to load 'wglGetIntegerv'. This error is generated by process_attach(). The log file also shows that the OpenGL initialization occurs *after* process_attach() is called. The sequence is : 1. process_attach() is called => X11DRV_wglGetProcAddress() returns NULL since OpenGL has not been initialized (error on line 2 of the log file) 2. X11DRV is initialized 3. internal_glGetIntegerv is called and fails since wine_wgl.p_wglGetIntegerv is NULL. So internal_glGetIntegerv() is called after X11DRV startup (which is the expected behaviour) but it uses a pointer that has been set *before* X11DRV startup, hence the failure. Bertrand.

Nov. 2, 2006

Re: Patch for opengl32.dll.so

by Christoph Frick

On Thu, Nov 02, 2006 at 02:25:33PM +0100, Roderick Colenbrander wrote: > Hmm, if that is indeed the case this patch could work for them. The > whole issue is new for me, I'll see what I can do about it. Right now > there's some GLX code in opengl32 which creates an opengl context. I > was planning to replace it with WGL code, that might help too (if I > load the function pointers afterwards). Perhaps Alexandre has an idea > how to correctly fight the race condition. just for the files: the glGetIntegerv is also the last thing that the java stacktrace of IL2 shows up. i will try this patch against all the games, that are no longer working on my end. -- cu

Nov. 2, 2006

Re: ntdll: Add a stub implementation for RtlDllShutdownInProgress.

by Robert Shearman

Mike McCormack wrote: > +NTSTATUS WINAPI RtlDllShutdownInProgress(void) > +{ > + FIXME("\n"); > + return STATUS_SUCCESS; > +} For undocumented functions like this, you should add a test case. -- Rob Shearman

Nov. 2, 2006

Re: Patch for opengl32.dll.so

by Roderick Colenbrander

> Roderick Colenbrander wrote: > >> Roderick Colenbrander wrote : > >> > >>>> On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> The last release of Wine 0.9.24 contains an error in the code of > >>>>> > >>>> opengl32.dll.so > >>>> > >>>>> under X11 : Wine tries to get the address of "wglGetIntegerv" (line > >>>>> > >> 608 > >> > >>>> of > >>>> > >>>>> dlls/opengl32/wgl.c) before the extensions of WGL have actually been > >>>>> > >>>> loaded > >>>> > >>>>> (i.e. before X11DRV_WineGL_LoadExtensions() is called). The reading > of > >>>>> > >>>> the > >>>> > >>>>> wglGetIntegerv address fails and afterwards, whenever > >>>>> > >>>> internal_glGetIntegerv() > >>>> > >>>>> is called, wine_wgl.p_wglGetIntegerv is NULL and a Fatal Exception > is > >>>>> > >>>> raised. > >>>> > >>>> > >>>> This is probably already fixed in the git tree. See the commit: > >>>> winex11.drv: Fixed the prototype of many OpenGL functions. > >>>> > >>>> Jesse > >>>> > >>> Else if the problem still happens something strange is going as the > >>> > >> extensions are registered at x11drv startup. > >> > >>> Roderick > >>> > >> Yes, the problem still happens because the function process_attach() > (line > >> 582 > >> of dlls/opengl32/wgl.c) is called before the x11drv startup. The > comment > >> of > >> process_attach is very clear : "/* This is for brain-dead applications > >> that use > >> OpenGL functions before even creating a rendering context.... */". It > is > >> clear > >> that process_attach is a workaround for *brain-dead* apps :) and among > >> other > >> things it gets the address of wglGetIntegerv. This operation used to > >> succeed as > >> long as GetProcAddress() was used but now since x11drv is needed to > upload > >> the > >> wglGetIntegerv address there is some kind of race condition and the > >> operation > >> fails hence the bug. > >> > >> Bertrand. > >> > > > > Compared to 0.9.23 I changed the way wglGetIntegerv is loaded before it > was directly loaded using GetProcAddress from winex11.drv now it is still > loaded from winex11.drv but then using wglGetProcAddress from gdi32. At wine > startup (I'm not sure at which stage but I believe directly when you use > gdi stuff or perhaps even earlier) winex11.drv is initialized and during > this initialization my opengl code is initialized aswell. I wonder what causes > the race as I haven't seen it happening for other users yet. I want to > avoid a patch like yours as I plan to do similar things for some other > functions. > > > > Perhaps something goes wrong in wglGetProcAddress itself. Try running > wine using: WINEDEBUG=+wgl,+opengl wine wow.exe -opengl &> log. If it is > correct you'll see some opengl information (gl version, loading of extensions) > before stuff happens in opengl32.dll. > > > > Roderick > > > Hi Roderick, do you have a patch for this problem, since 0.23 a number > of wow users seem to be getting a crash at startup that didn't happen > before 0.23 or 0.22, can't remember which, only some users not all. > > I just wondered if this is the fix for it, if we could try it out ? > > Regards > Nick Hmm, if that is indeed the case this patch could work for them. The whole issue is new for me, I'll see what I can do about it. Right now there's some GLX code in opengl32 which creates an opengl context. I was planning to replace it with WGL code, that might help too (if I load the function pointers afterwards). Perhaps Alexandre has an idea how to correctly fight the race condition. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Nov. 2, 2006

Re: Patch for opengl32.dll.so

by Nick Law

Roderick Colenbrander wrote: >> Roderick Colenbrander wrote : >> >>>> On 11/1/06, Bertrand Coconnier <bcoconni(a)club-internet.fr> wrote: >>>> >>>>> Hi, >>>>> >>>>> The last release of Wine 0.9.24 contains an error in the code of >>>>> >>>> opengl32.dll.so >>>> >>>>> under X11 : Wine tries to get the address of "wglGetIntegerv" (line >>>>> >> 608 >> >>>> of >>>> >>>>> dlls/opengl32/wgl.c) before the extensions of WGL have actually been >>>>> >>>> loaded >>>> >>>>> (i.e. before X11DRV_WineGL_LoadExtensions() is called). The reading of >>>>> >>>> the >>>> >>>>> wglGetIntegerv address fails and afterwards, whenever >>>>> >>>> internal_glGetIntegerv() >>>> >>>>> is called, wine_wgl.p_wglGetIntegerv is NULL and a Fatal Exception is >>>>> >>>> raised. >>>> >>>> >>>> This is probably already fixed in the git tree. See the commit: >>>> winex11.drv: Fixed the prototype of many OpenGL functions. >>>> >>>> Jesse >>>> >>> Else if the problem still happens something strange is going as the >>> >> extensions are registered at x11drv startup. >> >>> Roderick >>> >> Yes, the problem still happens because the function process_attach() (line >> 582 >> of dlls/opengl32/wgl.c) is called before the x11drv startup. The comment >> of >> process_attach is very clear : "/* This is for brain-dead applications >> that use >> OpenGL functions before even creating a rendering context.... */". It is >> clear >> that process_attach is a workaround for *brain-dead* apps :) and among >> other >> things it gets the address of wglGetIntegerv. This operation used to >> succeed as >> long as GetProcAddress() was used but now since x11drv is needed to upload >> the >> wglGetIntegerv address there is some kind of race condition and the >> operation >> fails hence the bug. >> >> Bertrand. >> > > Compared to 0.9.23 I changed the way wglGetIntegerv is loaded before it was directly loaded using GetProcAddress from winex11.drv now it is still loaded from winex11.drv but then using wglGetProcAddress from gdi32. At wine startup (I'm not sure at which stage but I believe directly when you use gdi stuff or perhaps even earlier) winex11.drv is initialized and during this initialization my opengl code is initialized aswell. I wonder what causes the race as I haven't seen it happening for other users yet. I want to avoid a patch like yours as I plan to do similar things for some other functions. > > Perhaps something goes wrong in wglGetProcAddress itself. Try running wine using: WINEDEBUG=+wgl,+opengl wine wow.exe -opengl &> log. If it is correct you'll see some opengl information (gl version, loading of extensions) before stuff happens in opengl32.dll. > > Roderick > Hi Roderick, do you have a patch for this problem, since 0.23 a number of wow users seem to be getting a crash at startup that didn't happen before 0.23 or 0.22, can't remember which, only some users not all. I just wondered if this is the fix for it, if we could try it out ? Regards Nick

Nov. 2, 2006