Re: Executing wine over make segfaults.
> > I recently tried 2.6.18.1 kernel and wine stoped working. Then I > > downgraded to 2.6.16.18 and wine working fine now. > > I'm using a custom built 2.6.18.1 on Debian Unstable/AMD64 now, and Wine > works fine for me, so this is unlikely to be a Wine problem. I compiled 2.6.18.1 with same .config. As expected, Wine stoped working. I don't know yet why exactly this happens but fact is that with same configuration under 2.6.18.1 kernel Wine doesn't work. As you said you have 2.6.18.1 and working Wine. So please tell your compiler, X server versions and compilation options for Wine. Also I very appreciate if you send me your .config file so I can try it on my system (I use Debian testing amd64 distribution). I have errors like these ones when I try to launch something with Wine: fixme:seh:check_no_exec No-exec fault triggered at 0x401000, enabling work-around fixme:seh:check_no_exec No-exec fault triggered at 0x4c8ad4, enabling work-around err:seh:setup_exception stack overflow 40 bytes in thread 0009 eip f7c9e9ff esp 00230fd8 stack 0x231000-0x34 Some applications even open window but soon after these messages crash. Factually, all my Windows apps crash! Only exceptions that I found are winecfg and notepad, but everything else including all my games, viewers, players and editors crash. Under 2.6.16.18 Wine works perfectly. P.S. I use gcc 4.0.2 and Wine compiled by following commands: LDFLAGS="-L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" ./configure \ --x-libraries=/emul/ia32-linux/usr/X11R6/lib/ --x-includes=/emul/ia32-linux/usr/X11R6/include --with-x && \ make depend && \ make all && \ sudo make install;
Re: msvfw32: Cast-qual warning fix
"Andrew Talbot" <[EMAIL PROTECTED]> wrote: The last formal argument of MCIWndCreate() is not const-qualified in the SDK. It is in my version of the PSDK headers, but it is not in the PSDK docs. -- Dmitry.
Re: Cast-qual warning fix
"Andrew Talbot" <[EMAIL PROTECTED]> wrote: -typedef void *MSIITERHANDLE; +typedef void*MSIITERHANDLE; +typedef const void *MSICITERHANDLE; Personally I don't like MSICITERHANDLE typedef at all. It' not obvious that 'C' in the name marks constness of the object. Using 'const' explicitly such as 'const MSIITERHANDLE *handle' is much more clear and readable IMO. -- Dmitry.
Re: Executing wine over make segfaults.
L. Rahyen wrote: The system is gentoo linux (2.6.18-gentoo-r1) I recently tried 2.6.18.1 kernel and wine stoped working. Then I downgraded to 2.6.16.18 and wine working fine now. I'm using a custom built 2.6.18.1 on Debian Unstable/AMD64 now, and Wine works fine for me, so this is unlikely to be a Wine problem. Mike
Re: Executing wine over make segfaults.
> The system is gentoo linux (2.6.18-gentoo-r1) I recently tried 2.6.18.1 kernel and wine stoped working. Then I downgraded to 2.6.16.18 and wine working fine now. After doing some important work, I will recompile 2.6.18.1 again with same .config and will see what happens. But because difference of .config between my 2.6.16.18 and 2.6.18.1 wasn't very big I think this is Wine problem (probably not Linux problem because everything works perfectly with new kernel). But I must try exactly same .config to be sure (only some deprecated options will be automatically excluded by "make menuconfig"). > I could try installing an older version of gcc or an older kernel and see if that helps. If downloading 39M isn't big problem for you then please try kernel 2.6.16.18. You can download it here: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.16.18.tar.bz2
Re: Executing wine over make segfaults.
# wine --version Works! But: Makefile - test: wine --version - Then run: #make test Wine will segfault! I am having the same problem. I use wine to run a compiler from a Makefile. A few months ago, it worked fine, but recently it stopped working. I even downgraded to versions that had worked before, but without success. I have a few older systems that rarely get updated and are working fine, so I was not too concerned about it, but when I saw that 0.9.24 worked, I thought I was back in business except it doesn't work from make. The system is gentoo linux (2.6.18-gentoo-r1) wine compiled like this: ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --sysconfdir=/etc/wine --without-curses --without-opengl --with-x --disable-trace --disable-debug --build=i686-pc-linux-gnu Do you have any special kernel compile options in use? It's gentoo, so everything is custom compiled, but I try to keep it pretty vanilla. I don't think I have stack-protector on unless that is the default for gcc-4.1.1 I could try installing an older version of gcc or an older kernel and see if that helps. Any other ideas? Thanks for your time. _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
Re: When will ie6 registry key be added?
On 04.11.2006 19:35, Jaap Stolk wrote: > On 11/4/06, Louis. Lenders <[EMAIL PROTECTED]> wrote: >> Hi, subject says it: When will ie6 registry key be added? > > Adding registry keys will not fix all of these problems. Some > installers also check the version info of the (stub) dll's in wine. > (in my case, Autocad 2004) > > In cases where a faked registry key does help, a single key is often > sufficient, so it's not very difficult to do by hand. I think it would > be best to mention this in the appdb for the applications that need > this, and maybe in the wine wiki. (it probably already is) I wonder if there's a good reason against adding those registry keys via e.g. wine.inf, so affected installers will work out of the box? -f.r.
Re: Patch for opengl32.dll.so
On Fri, Nov 03, 2006 at 01:57:33PM +0100, Roderick Colenbrander wrote: > > one of the patches from 2006-10-31 fixed my problems as it seems. > > IL2 now crashed out 1 of 4 starts but with another error. the > > remaining stuff is fine - although NASCAR 2003 is very slow now. > Regarding the slowness of nascar2003 is it caused by the recent > patches a none of them have really changed the code. The patches I > have sent have mainly changed the location of the code (location in > opengl32.dll/gdi32.dll/winex11.drv). The only change that could have > had performance implications was the pixel format of august/september. i will go and bisect for it... -- cu pgpze1F73jr69.pgp Description: PGP signature
Re: When will ie6 registry key be added?
On 11/4/06, Louis. Lenders <[EMAIL PROTECTED]> wrote: Hi, subject says it: When will ie6 registry key be added? Adding registry keys will not fix all of these problems. Some installers also check the version info of the (stub) dll's in wine. (in my case, Autocad 2004) In cases where a faked registry key does help, a single key is often sufficient, so it's not very difficult to do by hand. I think it would be best to mention this in the appdb for the applications that need this, and maybe in the wine wiki. (it probably already is)
Re: Flickering bug for World of Warcraft
Roderick Colenbrander wrote : Could you check if the attached patch works? It does more or less what I explained in the last email. If it works I'll clean it up as right now it is a bit hacky. I hope to find some apps to test it on. Regards, Roderick Your patch fixes everything : WoW does not flicker any more, the DC type of the Pbuffer is OBJ_DC and the Pbuffer's DC is not the same than the window's DC. Regards, Bertrand.
Re: Flickering bug for World of Warcraft
> > Roderick Colenbrander wrote :
> > >> Roderick Colenbrander wrote :
> > >>
> > >>> Or perhaps a testcase isn't needed at all. I think the use of
> > >> CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to
> > MSDN this
> > >> function creates a memory device context. Perhaps something like this
> > works:
> > >>> HDC hdc = CreateDC(...);
> > >>> int format_orig = GetPixelFormat(hdc_orig);
> > >>> SetPixelFormat(hdc, format_orig);
> > >>> return hdc;
> > >> Thanks to your hints I could make the attached patch. It fixes the
> > issue
> > >> on my
> > >> side : wglGetPbufferDCARB returns a DC which type is OBJ_DC and WoW
> > does
> > >> not
> > >> flicker any more.
> > >>
> > >> Regards,
> > >>
> > >> Bertrand.
> > >
> > > @@ -1869,16 +1869,18 @@ static HDC WINAPI X11DRV_wglGetPbufferDC
> > > {
> > > Wine_GLPBuffer* object = (Wine_GLPBuffer*) hPbuffer;
> > > HDC hDC;
> > > +int iPixelFormat;
> > > +PIXELFORMATDESCRIPTOR pfd;
> > > if (NULL == object) {
> > > SetLastError(ERROR_INVALID_HANDLE);
> > > return NULL;
> > > }
> > > -hDC = CreateCompatibleDC(object->hdc);
> > >
> > > -/* The function wglGetPbufferDCARB returns a DC to which the
> > pbuffer can be connected.
> > > - * We only support one onscreen rendering format (the one from
> the
> > main visual), so use that. */
> > > -SetPixelFormat(hDC, 1, NULL);
> > > -set_drawable(hDC, object->drawable); /* works ?? */
> > > +hDC = CreateDCA("DISPLAY", NULL, NULL, NULL);
> > > +iPixelFormat = GetPixelFormat(object->hdc);
> > > +DescribePixelFormat(hDC, iPixelFormat,
> > sizeof(PIXELFORMATDESCRIPTOR), &pfd);
> > > +SetPixelFormat(hDC, iPixelFormat, &pfd);
> > > +
> > > TRACE("(%p)->(%p)\n", hPbuffer, hDC);
> > > return hDC;
> > > }
> > >
> > > I'm not sure if this is correct for all programs. Some more testing
> > needs to be done in other programs that use pbuffers. The set_drawable
> line
> > must have a purpose (though I like to get rid of it or atleast implement
> it
> > without ExtEscape). And I'm also not sure if we need to retrieve the
> > pixelformat of the 'parent hdc' as it is allways 1 though retrieving it
> is nicer.
> > >
> > > Roderick
> >
> > The patch fixes the bug whether the set_drawable is included or not. So
> I
> > guess
> > it does not hurt. I also dug in the wine-patches mailing list and it
> > appeared
> > that you included this line in your original patch (see
> > http://www.winehq.org/pipermail/wine-patches/2006-September/030335.html)
> > but
> > infortunately you did not give any detail at the time about the reason
> of
> > its
> > inclusion. Yet it seems logical that the DC returned by
> wglGetPbufferDCARB
> > is
> > linked to the Pbuffer drawable rather than the window drawable.
> >
> > About the retrival of the pixel format of the 'parent hdc', I agree that
> > it is a
> > bit overkill but once again it does not hurt and it may prevent bugs to
> > occur if
> > one day Wine will use more than one pixel format.
> >
> > So what about this patch ?
> >
> > @@ -1869,16 +1869,18 @@ static HDC WINAPI X11DRV_wglGetPbufferDC
> > {
> > Wine_GLPBuffer* object = (Wine_GLPBuffer*) hPbuffer;
> > HDC hDC;
> > +int iPixelFormat;
> > +PIXELFORMATDESCRIPTOR pfd;
> > if (NULL == object) {
> > SetLastError(ERROR_INVALID_HANDLE);
> > return NULL;
> > }
> > -hDC = CreateCompatibleDC(object->hdc);
> >
> > -/* The function wglGetPbufferDCARB returns a DC to which the
> pbuffer
> > can be
> > connected.
> > - * We only support one onscreen rendering format (the one from the
> > main
> > visual), so use that. */
> > -SetPixelFormat(hDC, 1, NULL);
> > +hDC = CreateDCA("DISPLAY", NULL, NULL, NULL);
> > +iPixelFormat = GetPixelFormat(object->hdc);
> > +DescribePixelFormat(hDC, iPixelFormat,
> sizeof(PIXELFORMATDESCRIPTOR),
> > &pfd);
> > +SetPixelFormat(hDC, iPixelFormat, &pfd);
> > set_drawable(hDC, object->drawable); /* works ?? */
> > +
> > TRACE("(%p)->(%p)\n", hPbuffer, hDC);
> > return hDC;
> > }
> >
> > About testing, I don't have an app other than WoW that uses OpenGL (not
> to
> > mention Pbuffers) so if some people out there could give this patch a
> > try...
> >
> > Bertrand.
>
> The main issue I still have with the patch which isn't something you have
> done wrong is set_drawable. Before I started moving the original opengl32
> code to winex11.drv (I didn't write the WGL code), there was a need to get
> access to X11 data inside opengl32. For this purpose 'ExtEscape' got used.
> This isn't a nice mechanism and Alexandre wants to get rid of it as much as
> possible.
>
> The set_drawable call uses ExtEscape too. I think I'm going to move a part
> of wglGetCurrentDCARB to gdi32.dll in which we can do CreateDCA. Then we
> can pass the HDC and pbuffer to the other part of wglGetCurrentDCARB which
> will be in wi
Re: preloader: Setup a fake thread-local storage block pointed to by %gs. breaks RH9
Robert Reif <[EMAIL PROTECTED]> writes: > This last commit: > http://www.winehq.org/pipermail/wine-cvs/2006-November/027508.html > totally breaks wine on Red Hat 9. How is it broken? > Red Hat 9 has been partially broken since 2.4 kernel support has been > dropped a while back but this patch makes it totally unusable. > > It is unfortunate that 2.4 kernel support has been removed from wine > because in "The Real World" (large enterprise and dedicated or > embedded systems) users don't have the option of upgrading the OS to > the latest and greatest. Some systems will never be upgraded once > deployed. Dropping 2.4 support is a regression. 2.4 support is not dropped at all, it still works fine. What doesn't work is using a recent glibc on a kernel that doesn't support NPTL; that's not something we can do anything about. If you use an old glibc with an old kernel everything should still work fine. -- Alexandre Julliard [EMAIL PROTECTED]
preloader: Setup a fake thread-local storage block pointed to by %gs. breaks RH9
This last commit: http://www.winehq.org/pipermail/wine-cvs/2006-November/027508.html totally breaks wine on Red Hat 9. Red Hat 9 has been partially broken since 2.4 kernel support has been dropped a while back but this patch makes it totally unusable. It is unfortunate that 2.4 kernel support has been removed from wine because in "The Real World" (large enterprise and dedicated or embedded systems) users don't have the option of upgrading the OS to the latest and greatest. Some systems will never be upgraded once deployed. Dropping 2.4 support is a regression.
Re: Flickering bug for World of Warcraft
> Roderick Colenbrander wrote :
> >> Roderick Colenbrander wrote :
> >>
> >>> Or perhaps a testcase isn't needed at all. I think the use of
> >> CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to
> MSDN this
> >> function creates a memory device context. Perhaps something like this
> works:
> >>> HDC hdc = CreateDC(...);
> >>> int format_orig = GetPixelFormat(hdc_orig);
> >>> SetPixelFormat(hdc, format_orig);
> >>> return hdc;
> >> Thanks to your hints I could make the attached patch. It fixes the
> issue
> >> on my
> >> side : wglGetPbufferDCARB returns a DC which type is OBJ_DC and WoW
> does
> >> not
> >> flicker any more.
> >>
> >> Regards,
> >>
> >> Bertrand.
> >
> > @@ -1869,16 +1869,18 @@ static HDC WINAPI X11DRV_wglGetPbufferDC
> > {
> > Wine_GLPBuffer* object = (Wine_GLPBuffer*) hPbuffer;
> > HDC hDC;
> > +int iPixelFormat;
> > +PIXELFORMATDESCRIPTOR pfd;
> > if (NULL == object) {
> > SetLastError(ERROR_INVALID_HANDLE);
> > return NULL;
> > }
> > -hDC = CreateCompatibleDC(object->hdc);
> >
> > -/* The function wglGetPbufferDCARB returns a DC to which the
> pbuffer can be connected.
> > - * We only support one onscreen rendering format (the one from the
> main visual), so use that. */
> > -SetPixelFormat(hDC, 1, NULL);
> > -set_drawable(hDC, object->drawable); /* works ?? */
> > +hDC = CreateDCA("DISPLAY", NULL, NULL, NULL);
> > +iPixelFormat = GetPixelFormat(object->hdc);
> > +DescribePixelFormat(hDC, iPixelFormat,
> sizeof(PIXELFORMATDESCRIPTOR), &pfd);
> > +SetPixelFormat(hDC, iPixelFormat, &pfd);
> > +
> > TRACE("(%p)->(%p)\n", hPbuffer, hDC);
> > return hDC;
> > }
> >
> > I'm not sure if this is correct for all programs. Some more testing
> needs to be done in other programs that use pbuffers. The set_drawable line
> must have a purpose (though I like to get rid of it or atleast implement it
> without ExtEscape). And I'm also not sure if we need to retrieve the
> pixelformat of the 'parent hdc' as it is allways 1 though retrieving it is
> nicer.
> >
> > Roderick
>
> The patch fixes the bug whether the set_drawable is included or not. So I
> guess
> it does not hurt. I also dug in the wine-patches mailing list and it
> appeared
> that you included this line in your original patch (see
> http://www.winehq.org/pipermail/wine-patches/2006-September/030335.html)
> but
> infortunately you did not give any detail at the time about the reason of
> its
> inclusion. Yet it seems logical that the DC returned by wglGetPbufferDCARB
> is
> linked to the Pbuffer drawable rather than the window drawable.
>
> About the retrival of the pixel format of the 'parent hdc', I agree that
> it is a
> bit overkill but once again it does not hurt and it may prevent bugs to
> occur if
> one day Wine will use more than one pixel format.
>
> So what about this patch ?
>
> @@ -1869,16 +1869,18 @@ static HDC WINAPI X11DRV_wglGetPbufferDC
> {
> Wine_GLPBuffer* object = (Wine_GLPBuffer*) hPbuffer;
> HDC hDC;
> +int iPixelFormat;
> +PIXELFORMATDESCRIPTOR pfd;
> if (NULL == object) {
> SetLastError(ERROR_INVALID_HANDLE);
> return NULL;
> }
> -hDC = CreateCompatibleDC(object->hdc);
>
> -/* The function wglGetPbufferDCARB returns a DC to which the pbuffer
> can be
> connected.
> - * We only support one onscreen rendering format (the one from the
> main
> visual), so use that. */
> -SetPixelFormat(hDC, 1, NULL);
> +hDC = CreateDCA("DISPLAY", NULL, NULL, NULL);
> +iPixelFormat = GetPixelFormat(object->hdc);
> +DescribePixelFormat(hDC, iPixelFormat, sizeof(PIXELFORMATDESCRIPTOR),
> &pfd);
> +SetPixelFormat(hDC, iPixelFormat, &pfd);
> set_drawable(hDC, object->drawable); /* works ?? */
> +
> TRACE("(%p)->(%p)\n", hPbuffer, hDC);
> return hDC;
> }
>
> About testing, I don't have an app other than WoW that uses OpenGL (not to
> mention Pbuffers) so if some people out there could give this patch a
> try...
>
> Bertrand.
The main issue I still have with the patch which isn't something you have done
wrong is set_drawable. Before I started moving the original opengl32 code to
winex11.drv (I didn't write the WGL code), there was a need to get access to
X11 data inside opengl32. For this purpose 'ExtEscape' got used. This isn't a
nice mechanism and Alexandre wants to get rid of it as much as possible.
The set_drawable call uses ExtEscape too. I think I'm going to move a part of
wglGetCurrentDCARB to gdi32.dll in which we can do CreateDCA. Then we can pass
the HDC and pbuffer to the other part of wglGetCurrentDCARB which will be in
winex11.drv. The winex11.drv version can then just set the drawable in a
X11DRV_PDEVICE (x11drv version of a hdc).
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
Re: Flickering bug for World of Warcraft
Roderick Colenbrander wrote :
Roderick Colenbrander wrote :
Or perhaps a testcase isn't needed at all. I think the use of
CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to MSDN this
function creates a memory device context. Perhaps something like this works:
HDC hdc = CreateDC(...);
int format_orig = GetPixelFormat(hdc_orig);
SetPixelFormat(hdc, format_orig);
return hdc;
Thanks to your hints I could make the attached patch. It fixes the issue
on my
side : wglGetPbufferDCARB returns a DC which type is OBJ_DC and WoW does
not
flicker any more.
Regards,
Bertrand.
@@ -1869,16 +1869,18 @@ static HDC WINAPI X11DRV_wglGetPbufferDC
{
Wine_GLPBuffer* object = (Wine_GLPBuffer*) hPbuffer;
HDC hDC;
+int iPixelFormat;
+PIXELFORMATDESCRIPTOR pfd;
if (NULL == object) {
SetLastError(ERROR_INVALID_HANDLE);
return NULL;
}
-hDC = CreateCompatibleDC(object->hdc);
-/* The function wglGetPbufferDCARB returns a DC to which the pbuffer can be connected.
- * We only support one onscreen rendering format (the one from the main
visual), so use that. */
-SetPixelFormat(hDC, 1, NULL);
-set_drawable(hDC, object->drawable); /* works ?? */
+hDC = CreateDCA("DISPLAY", NULL, NULL, NULL);
+iPixelFormat = GetPixelFormat(object->hdc);
+DescribePixelFormat(hDC, iPixelFormat, sizeof(PIXELFORMATDESCRIPTOR),
&pfd);
+SetPixelFormat(hDC, iPixelFormat, &pfd);
+
TRACE("(%p)->(%p)\n", hPbuffer, hDC);
return hDC;
}
I'm not sure if this is correct for all programs. Some more testing needs to be
done in other programs that use pbuffers. The set_drawable line must have a
purpose (though I like to get rid of it or atleast implement it without
ExtEscape). And I'm also not sure if we need to retrieve the pixelformat of the
'parent hdc' as it is allways 1 though retrieving it is nicer.
Roderick
The patch fixes the bug whether the set_drawable is included or not. So I guess
it does not hurt. I also dug in the wine-patches mailing list and it appeared
that you included this line in your original patch (see
http://www.winehq.org/pipermail/wine-patches/2006-September/030335.html) but
infortunately you did not give any detail at the time about the reason of its
inclusion. Yet it seems logical that the DC returned by wglGetPbufferDCARB is
linked to the Pbuffer drawable rather than the window drawable.
About the retrival of the pixel format of the 'parent hdc', I agree that it is a
bit overkill but once again it does not hurt and it may prevent bugs to occur if
one day Wine will use more than one pixel format.
So what about this patch ?
@@ -1869,16 +1869,18 @@ static HDC WINAPI X11DRV_wglGetPbufferDC
{
Wine_GLPBuffer* object = (Wine_GLPBuffer*) hPbuffer;
HDC hDC;
+int iPixelFormat;
+PIXELFORMATDESCRIPTOR pfd;
if (NULL == object) {
SetLastError(ERROR_INVALID_HANDLE);
return NULL;
}
-hDC = CreateCompatibleDC(object->hdc);
-/* The function wglGetPbufferDCARB returns a DC to which the pbuffer can be
connected.
- * We only support one onscreen rendering format (the one from the main
visual), so use that. */
-SetPixelFormat(hDC, 1, NULL);
+hDC = CreateDCA("DISPLAY", NULL, NULL, NULL);
+iPixelFormat = GetPixelFormat(object->hdc);
+DescribePixelFormat(hDC, iPixelFormat, sizeof(PIXELFORMATDESCRIPTOR),
&pfd);
+SetPixelFormat(hDC, iPixelFormat, &pfd);
set_drawable(hDC, object->drawable); /* works ?? */
+
TRACE("(%p)->(%p)\n", hPbuffer, hDC);
return hDC;
}
About testing, I don't have an app other than WoW that uses OpenGL (not to
mention Pbuffers) so if some people out there could give this patch a try...
Bertrand.
Re: Flickering bug for World of Warcraft
> Roderick Colenbrander wrote :
>
> > Or perhaps a testcase isn't needed at all. I think the use of
> CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to MSDN this
> function creates a memory device context. Perhaps something like this works:
> > HDC hdc = CreateDC(...);
> > int format_orig = GetPixelFormat(hdc_orig);
> > SetPixelFormat(hdc, format_orig);
> > return hdc;
>
> Thanks to your hints I could make the attached patch. It fixes the issue
> on my
> side : wglGetPbufferDCARB returns a DC which type is OBJ_DC and WoW does
> not
> flicker any more.
>
> Regards,
>
> Bertrand.
@@ -1869,16 +1869,18 @@ static HDC WINAPI X11DRV_wglGetPbufferDC
{
Wine_GLPBuffer* object = (Wine_GLPBuffer*) hPbuffer;
HDC hDC;
+int iPixelFormat;
+PIXELFORMATDESCRIPTOR pfd;
if (NULL == object) {
SetLastError(ERROR_INVALID_HANDLE);
return NULL;
}
-hDC = CreateCompatibleDC(object->hdc);
-/* The function wglGetPbufferDCARB returns a DC to which the pbuffer can
be connected.
- * We only support one onscreen rendering format (the one from the main
visual), so use that. */
-SetPixelFormat(hDC, 1, NULL);
-set_drawable(hDC, object->drawable); /* works ?? */
+hDC = CreateDCA("DISPLAY", NULL, NULL, NULL);
+iPixelFormat = GetPixelFormat(object->hdc);
+DescribePixelFormat(hDC, iPixelFormat, sizeof(PIXELFORMATDESCRIPTOR),
&pfd);
+SetPixelFormat(hDC, iPixelFormat, &pfd);
+
TRACE("(%p)->(%p)\n", hPbuffer, hDC);
return hDC;
}
I'm not sure if this is correct for all programs. Some more testing needs to be
done in other programs that use pbuffers. The set_drawable line must have a
purpose (though I like to get rid of it or atleast implement it without
ExtEscape). And I'm also not sure if we need to retrieve the pixelformat of the
'parent hdc' as it is allways 1 though retrieving it is nicer.
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
Re: wined3d: Respect ARB_VERTEX_BUFFER_OBJECT in loadVertexData.
Stefan Dösinger wrote: With vertex fixups I'd expect it to give 20-25 fps. You can test what you're likely to get with the attached hack. Gain with Bf1942 is about 20-30%, not bad for a one liner.
Re: Flickering bug for World of Warcraft
Roderick Colenbrander wrote :
Or perhaps a testcase isn't needed at all. I think the use of
CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to MSDN this
function creates a memory device context. Perhaps something like this works:
HDC hdc = CreateDC(...);
int format_orig = GetPixelFormat(hdc_orig);
SetPixelFormat(hdc, format_orig);
return hdc;
Thanks to your hints I could make the attached patch. It fixes the issue on my
side : wglGetPbufferDCARB returns a DC which type is OBJ_DC and WoW does not
flicker any more.
Regards,
Bertrand.
diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
index 962962f..b529f12 100644
--- a/dlls/winex11.drv/opengl.c
+++ b/dlls/winex11.drv/opengl.c
@@ -1869,16 +1869,18 @@ static HDC WINAPI X11DRV_wglGetPbufferDC
{
Wine_GLPBuffer* object = (Wine_GLPBuffer*) hPbuffer;
HDC hDC;
+int iPixelFormat;
+PIXELFORMATDESCRIPTOR pfd;
if (NULL == object) {
SetLastError(ERROR_INVALID_HANDLE);
return NULL;
}
-hDC = CreateCompatibleDC(object->hdc);
-/* The function wglGetPbufferDCARB returns a DC to which the pbuffer can
be connected.
- * We only support one onscreen rendering format (the one from the main
visual), so use that. */
-SetPixelFormat(hDC, 1, NULL);
-set_drawable(hDC, object->drawable); /* works ?? */
+hDC = CreateDCA("DISPLAY", NULL, NULL, NULL);
+iPixelFormat = GetPixelFormat(object->hdc);
+DescribePixelFormat(hDC, iPixelFormat, sizeof(PIXELFORMATDESCRIPTOR),
&pfd);
+SetPixelFormat(hDC, iPixelFormat, &pfd);
+
TRACE("(%p)->(%p)\n", hPbuffer, hDC);
return hDC;
}
Re: WineD3D: Scissor rect corrections
Stefan Dösinger <[EMAIL PROTECTED]> writes: > +GetWindowRect(((IWineD3DSwapChainImpl > *)This->swapchains[0])->win_handle, &windowRect); > +/* Warning: glScissor uses window coordinates, not viewport coordinates, > so our viewport correction does not apply > +* Warning2: Even in windowed mode the coords are relative to the window, > not the screen > +*/ Wouldn't GetClientRect be more appropriate? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Flickering bug for World of Warcraft
> > Roderick Colenbrander wrote : > > >> Hi, > > >> > > >> After investigating a bit in the Wine code, it seems that the > > flickering > > >> bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a > > DC > > >> which type is OBJ_MEMDC while it should return a DC which type is > > >> OBJ_DC. And since in the current git tree, the DC type of a Pbuffer > is > > >> OBJ_MEMDC then the code located in lines 1394-1395 of > > >> dlls/winex11.drv/opengl.c is executed : the Pbuffer is copied to the > > >> screen each time the GL context is made current to the Pbuffer hence > > the > > >> flickering (WoW bounds the GL context alternatively to the screen and > > to > > >> the Pbuffer). The expected behaviour is not to copy the Pbuffer > content > > >> to the screen since WoW does it itself. > > >> > > >> The easiest workaround for this bug would be to make > > >> X11DRV_wglGetPbufferDCARB to return the Pbuffer's object->hdc (this > > >> fixes the flickering bug). However, I have made some tests with > Windows > > >> XP and it appears that wglGetPbufferDCARB returns a HDC different > from > > >> the HDC passed when wglCreatePbufferARB was called. So such a patch > > >> would be a dirty hack not a real fix. > > >> > > >> I am not familiar enough with Wine to submit a patch so I leave the > > >> gurus out there find an elegant solution. > > >> > > >> Attached is the code that I used to perform a few tests about > Pbuffers > > >> on Windows XP (code of interest is located from line 293 to line > 298). > > >> > > >> Regards, > > >> > > >> Bertrand. > > >> > > >> > > >> > > > > > > It is correct that the return of OBJ_MEMDC causes the flickering as it > > turns on the line glDrawBuffer. One of the reasons I started to rewrite > > opengl32 was because of this. Right now most code is inside winex11.drv > in > > which we have much more control over things. > > > > > > The easiest hack I thought about some months ago is to just set a flag > > in the device returned wglGetPbufferDCARB though it would be tricky to > get a > > X11DRV_PDEVICE in a 'legal' (AJ-proof) way. > > > > > > There's also a chance that a hack like this isn't needed at all. > > Originally Huw Davies added the glDrawBuffer code together with > X11DRV_SYNC_PIXMAP > > code to winex11.drv/opengl32 in order to allow windowed opengl rendering > > using DIBs. The glDrawBuffer line was used for emulating single > buffering. > > > > > > Recently Ulrich Czekalla worked on a better fix for the windowed > opengl > > problem using glScissors. For this patch various calls like glViewport, > > glScissor and others need to be patched. It might be possible to get rid > of > > the glDrawBuffer / x11 pixmap rendering code but Huw would need to > answer > > that as he knows for what it was needed and it fully works. > > > > > > I really hope it can be removed when the scissors code is in, it would > > simplify the code and make my work easier. > > > > > > Regards, > > > Roderick > > > > OK such a patch would remove the flickering bug for WoW but what about > the > > wrong > > type of the Pbuffer's DC ? Obviously, Windows XP attaches a DC which > type > > is > > OBJ_DC to the Pbuffers. I don't know if some apps rely on the assumption > > that > > GetObjectType(wglGetPbufferDCARB(...)) == OBJ_DC, but if some do they > > might > > behave wrongly with Wine. > > > > Regards, > > > > Bertrand. > > I didn't have time yet to reply to the other email. This should be > investigated more thoroughly. Second as this would be a 'serious' bug in Wine > we > need to convince Alexandre that this behavior is correct. For this purpose > we need a test case. If you check the wine source you'll see that most dlls > contain test cases using certain APIs. These testcases are used on wine and > different windows versions to test the behavior of a function. Since the > behavior of GetObjectType for this case is badly documented it should be > added. Most likely it should be added to gdi32 and then dynamicly load > opengl32.dll (you likely need to provide the function prototypes yourself if > they > aren't in wingdi.h as we don't have wine opengl headers yet). > > If you could write such a test case in order to convince AJ that would be > very usefull. > > Regards, > Roderick Or perhaps a testcase isn't needed at all. I think the use of CreateCompatibleDC in wglGetPbufferDCARB is incorrect. According to MSDN this function creates a memory device context. Perhaps something like this works: HDC hdc = CreateDC(...); int format_orig = GetPixelFormat(hdc_orig); SetPixelFormat(hdc, format_orig); return hdc; -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: secur32: [4/3]Test and fix DecryptMessage for multiple data buffers.
"Kai Blin" <[EMAIL PROTECTED]> wrote:
--- a/dlls/secur32/ntlm.c
+++ b/dlls/secur32/ntlm.c
@@ -1345,22 +1345,32 @@ static SECURITY_STATUS SEC_ENTRY ntlm_Ve
if(helper->neg_flags & NTLMSSP_NEGOTIATE_SIGN)
{
SecBufferDesc local_desc;
-SecBuffer local_buff[2];
+SecBuffer local_buff[pMessage->cBuffers];
This construct is not portable, you need to use HeapAlloc to dynamically
allocate buffers.
--
Dmitry.
Re: Flickering bug for World of Warcraft
> Roderick Colenbrander wrote : > >> Hi, > >> > >> After investigating a bit in the Wine code, it seems that the > flickering > >> bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a > DC > >> which type is OBJ_MEMDC while it should return a DC which type is > >> OBJ_DC. And since in the current git tree, the DC type of a Pbuffer is > >> OBJ_MEMDC then the code located in lines 1394-1395 of > >> dlls/winex11.drv/opengl.c is executed : the Pbuffer is copied to the > >> screen each time the GL context is made current to the Pbuffer hence > the > >> flickering (WoW bounds the GL context alternatively to the screen and > to > >> the Pbuffer). The expected behaviour is not to copy the Pbuffer content > >> to the screen since WoW does it itself. > >> > >> The easiest workaround for this bug would be to make > >> X11DRV_wglGetPbufferDCARB to return the Pbuffer's object->hdc (this > >> fixes the flickering bug). However, I have made some tests with Windows > >> XP and it appears that wglGetPbufferDCARB returns a HDC different from > >> the HDC passed when wglCreatePbufferARB was called. So such a patch > >> would be a dirty hack not a real fix. > >> > >> I am not familiar enough with Wine to submit a patch so I leave the > >> gurus out there find an elegant solution. > >> > >> Attached is the code that I used to perform a few tests about Pbuffers > >> on Windows XP (code of interest is located from line 293 to line 298). > >> > >> Regards, > >> > >> Bertrand. > >> > >> > >> > > > > It is correct that the return of OBJ_MEMDC causes the flickering as it > turns on the line glDrawBuffer. One of the reasons I started to rewrite > opengl32 was because of this. Right now most code is inside winex11.drv in > which we have much more control over things. > > > > The easiest hack I thought about some months ago is to just set a flag > in the device returned wglGetPbufferDCARB though it would be tricky to get a > X11DRV_PDEVICE in a 'legal' (AJ-proof) way. > > > > There's also a chance that a hack like this isn't needed at all. > Originally Huw Davies added the glDrawBuffer code together with > X11DRV_SYNC_PIXMAP > code to winex11.drv/opengl32 in order to allow windowed opengl rendering > using DIBs. The glDrawBuffer line was used for emulating single buffering. > > > > Recently Ulrich Czekalla worked on a better fix for the windowed opengl > problem using glScissors. For this patch various calls like glViewport, > glScissor and others need to be patched. It might be possible to get rid of > the glDrawBuffer / x11 pixmap rendering code but Huw would need to answer > that as he knows for what it was needed and it fully works. > > > > I really hope it can be removed when the scissors code is in, it would > simplify the code and make my work easier. > > > > Regards, > > Roderick > > OK such a patch would remove the flickering bug for WoW but what about the > wrong > type of the Pbuffer's DC ? Obviously, Windows XP attaches a DC which type > is > OBJ_DC to the Pbuffers. I don't know if some apps rely on the assumption > that > GetObjectType(wglGetPbufferDCARB(...)) == OBJ_DC, but if some do they > might > behave wrongly with Wine. > > Regards, > > Bertrand. I didn't have time yet to reply to the other email. This should be investigated more thoroughly. Second as this would be a 'serious' bug in Wine we need to convince Alexandre that this behavior is correct. For this purpose we need a test case. If you check the wine source you'll see that most dlls contain test cases using certain APIs. These testcases are used on wine and different windows versions to test the behavior of a function. Since the behavior of GetObjectType for this case is badly documented it should be added. Most likely it should be added to gdi32 and then dynamicly load opengl32.dll (you likely need to provide the function prototypes yourself if they aren't in wingdi.h as we don't have wine opengl headers yet). If you could write such a test case in order to convince AJ that would be very usefull. Regards, 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
Re: Flickering bug for World of Warcraft
Roderick Colenbrander wrote : Hi, After investigating a bit in the Wine code, it seems that the flickering bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a DC which type is OBJ_MEMDC while it should return a DC which type is OBJ_DC. And since in the current git tree, the DC type of a Pbuffer is OBJ_MEMDC then the code located in lines 1394-1395 of dlls/winex11.drv/opengl.c is executed : the Pbuffer is copied to the screen each time the GL context is made current to the Pbuffer hence the flickering (WoW bounds the GL context alternatively to the screen and to the Pbuffer). The expected behaviour is not to copy the Pbuffer content to the screen since WoW does it itself. The easiest workaround for this bug would be to make X11DRV_wglGetPbufferDCARB to return the Pbuffer's object->hdc (this fixes the flickering bug). However, I have made some tests with Windows XP and it appears that wglGetPbufferDCARB returns a HDC different from the HDC passed when wglCreatePbufferARB was called. So such a patch would be a dirty hack not a real fix. I am not familiar enough with Wine to submit a patch so I leave the gurus out there find an elegant solution. Attached is the code that I used to perform a few tests about Pbuffers on Windows XP (code of interest is located from line 293 to line 298). Regards, Bertrand. It is correct that the return of OBJ_MEMDC causes the flickering as it turns on the line glDrawBuffer. One of the reasons I started to rewrite opengl32 was because of this. Right now most code is inside winex11.drv in which we have much more control over things. The easiest hack I thought about some months ago is to just set a flag in the device returned wglGetPbufferDCARB though it would be tricky to get a X11DRV_PDEVICE in a 'legal' (AJ-proof) way. There's also a chance that a hack like this isn't needed at all. Originally Huw Davies added the glDrawBuffer code together with X11DRV_SYNC_PIXMAP code to winex11.drv/opengl32 in order to allow windowed opengl rendering using DIBs. The glDrawBuffer line was used for emulating single buffering. Recently Ulrich Czekalla worked on a better fix for the windowed opengl problem using glScissors. For this patch various calls like glViewport, glScissor and others need to be patched. It might be possible to get rid of the glDrawBuffer / x11 pixmap rendering code but Huw would need to answer that as he knows for what it was needed and it fully works. I really hope it can be removed when the scissors code is in, it would simplify the code and make my work easier. Regards, Roderick OK such a patch would remove the flickering bug for WoW but what about the wrong type of the Pbuffer's DC ? Obviously, Windows XP attaches a DC which type is OBJ_DC to the Pbuffers. I don't know if some apps rely on the assumption that GetObjectType(wglGetPbufferDCARB(...)) == OBJ_DC, but if some do they might behave wrongly with Wine. Regards, Bertrand.
Re: Flickering bug for World of Warcraft
> Hi, > > After investigating a bit in the Wine code, it seems that the flickering > bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a DC > which type is OBJ_MEMDC while it should return a DC which type is > OBJ_DC. And since in the current git tree, the DC type of a Pbuffer is > OBJ_MEMDC then the code located in lines 1394-1395 of > dlls/winex11.drv/opengl.c is executed : the Pbuffer is copied to the > screen each time the GL context is made current to the Pbuffer hence the > flickering (WoW bounds the GL context alternatively to the screen and to > the Pbuffer). The expected behaviour is not to copy the Pbuffer content > to the screen since WoW does it itself. > > The easiest workaround for this bug would be to make > X11DRV_wglGetPbufferDCARB to return the Pbuffer's object->hdc (this > fixes the flickering bug). However, I have made some tests with Windows > XP and it appears that wglGetPbufferDCARB returns a HDC different from > the HDC passed when wglCreatePbufferARB was called. So such a patch > would be a dirty hack not a real fix. > > I am not familiar enough with Wine to submit a patch so I leave the > gurus out there find an elegant solution. > > Attached is the code that I used to perform a few tests about Pbuffers > on Windows XP (code of interest is located from line 293 to line 298). > > Regards, > > Bertrand. > > > It is correct that the return of OBJ_MEMDC causes the flickering as it turns on the line glDrawBuffer. One of the reasons I started to rewrite opengl32 was because of this. Right now most code is inside winex11.drv in which we have much more control over things. The easiest hack I thought about some months ago is to just set a flag in the device returned wglGetPbufferDCARB though it would be tricky to get a X11DRV_PDEVICE in a 'legal' (AJ-proof) way. There's also a chance that a hack like this isn't needed at all. Originally Huw Davies added the glDrawBuffer code together with X11DRV_SYNC_PIXMAP code to winex11.drv/opengl32 in order to allow windowed opengl rendering using DIBs. The glDrawBuffer line was used for emulating single buffering. Recently Ulrich Czekalla worked on a better fix for the windowed opengl problem using glScissors. For this patch various calls like glViewport, glScissor and others need to be patched. It might be possible to get rid of the glDrawBuffer / x11 pixmap rendering code but Huw would need to answer that as he knows for what it was needed and it fully works. I really hope it can be removed when the scissors code is in, it would simplify the code and make my work easier. 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
Re: Flickering bug for World of Warcraft
Jesse Allen wrote :
On 11/3/06, Bertrand Coconnier <[EMAIL PROTECTED]> wrote:
Hi,
After investigating a bit in the Wine code, it seems that the flickering
bug of WoW in OpenGL mode is due to wglGetPbufferDCARB that returns a DC
which type is OBJ_MEMDC while it should return a DC which type is
OBJ_DC. And since in the current git tree, the DC type of a Pbuffer is
OBJ_MEMDC then the code located in lines 1394-1395 of
dlls/winex11.drv/opengl.c is executed : the Pbuffer is copied to the
screen each time the GL context is made current to the Pbuffer hence the
flickering (WoW bounds the GL context alternatively to the screen and to
the Pbuffer). The expected behaviour is not to copy the Pbuffer content
to the screen since WoW does it itself.
The easiest workaround for this bug would be to make
X11DRV_wglGetPbufferDCARB to return the Pbuffer's object->hdc (this
fixes the flickering bug). However, I have made some tests with Windows
XP and it appears that wglGetPbufferDCARB returns a HDC different from
the HDC passed when wglCreatePbufferARB was called. So such a patch
would be a dirty hack not a real fix.
http://oss.sgi.com/projects/ogl-sample/registry/ARB/wgl_pbuffer.txt
"To create a device context for the pbuffer, call
HDC wglGetPbufferDCARB(HPBUFFERARB hPbuffer);
where is a handle returned from a previous call to
wglCreatePbufferARB. A device context is returned by
wglGetPbufferDCARB which can be used to associate a rendering
context with the pbuffer. Any rendering context created with
a wglCreateContext that is "compatible" with the may
be used to render into the pbuffer."
So yes, it's supposed to return a new one.
So I can understand better, what are these set to when you run your
program on both windows and linux?
type1 = GetObjectType(hDC);
type2 = GetObjectType(pBufferHDC);
Jesse
Under Windows XP : type1 == OBJ_DC
type2 == OBJ_DC
Under Wine :type1 == OBJ_DC
type2 == OBJ_MEMDC /* should be OBJ_DC since pBuffers are supposed to be
located in Video Memory or whatever its name */
And since device contexts of Wine's pBuffers are OBJ_MEMDC, the following code
in X11DRV_wglMakeCurrent is executed (line 1392 of dlls/winex11.drv/opengl.c) :
if(ret && type == OBJ_MEMDC)
{
ctx->do_escape = TRUE;
pglDrawBuffer(GL_FRONT_LEFT);
}
the content of the Pbuffer's DC is copied to the color buffer by Wine while it
should not (there is no reason for some memory data to be copied to the color
buffer when a GL context is made current to a Pbuffer).
Bertrand.
When will ie6 registry key be added?
Hi, subject says it: When will ie6 registry key be added?People are filing bugs against wine, because installers fail, saying ie6 has to be installed. I guess in most cases, they will rush for ies4linux (which is btw a great script i think, but useless to use other apps then ie6) and end up with a mess because it sets lots of dlls to native.Or is this a wontfix, because real ie6 will never come with wine? Please consider adding the key. Send instant messages to your online friends http://uk.messenger.yahoo.com
