Re: Warn users who attempt to use native DirectDraw
There is another category of users who doesn't like message boxes, perhaps an option between them which defaults to message boxes ? / Lars Segerlund. On Tue, 22 Mar 2005 23:58:15 + Mike Hearn <[EMAIL PROTECTED]> wrote: > On Tue, 22 Mar 2005 12:54:15 -0600, Robert Shearman wrote: > > I agree. Not everyone looks at to their console for messages when > > running apps. > > There are a whole class of messages like that which *should* be message > boxes but aren't for whatever reason. In this case we'd have to > LoadLibrary/GetProcAddress user32. We can do this, if Alexandre thinks > it'd be preferable - AJ? > >
Re: Warn users who attempt to use native DirectDraw
Mike Hearn <[EMAIL PROTECTED]> writes: > There are a whole class of messages like that which *should* be message > boxes but aren't for whatever reason. In this case we'd have to > LoadLibrary/GetProcAddress user32. We can do this, if Alexandre thinks > it'd be preferable - AJ? Messages that the user needs to see have to be a message box, yes. But really if we are doing things right there shouldn't be any need for such messages. In this specific case I'd suggest letting winecfg take care of it, by not offering the ddraw dlls in the load order config, and/or issuing a warning when they are set to native. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Warn users who attempt to use native DirectDraw
On Wed, 23 Mar 2005 11:15:04 +0100, Alexandre Julliard wrote: > Messages that the user needs to see have to be a message box, yes. But > really if we are doing things right there shouldn't be any need for > such messages. In this specific case I'd suggest letting winecfg take > care of it, by not offering the ddraw dlls in the load order config, > and/or issuing a warning when they are set to native. Maybe we should just extend the blacklist in the code, some DLLs will never work as native like ntdll so we just never try and load them. Probably that'd be better from a usability POV than any warning. thanks -mike
Native stack overlapping system heap base address on some systems
Hi, Bug #2741 comes from a user who was able to grab a dump of the VM mappings when the following error occurred: HEAP_CreateSystemHeap system heap base address 0x8000 not available I know people have been seeing this intermittently for a while now, we have a few CodeWeavers support tickets with this problem too. The issue seems to be that the Linux native (main thread) stack was allocated here: 7fffb000 20K rwx--[ stack ] Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x8000 Unfortunately I lack enough knowledge about the kernels VM algorithms to say why it's being allocated here. For comparison on my Fedora Core 3 machine: fef0d000 16K rwx--[ stack ] One other thing I don't understand. It seems the stack and the system heap overlap by exactly 1 byte, otherwise the mmap would not fail. But, this area is (theoretically) being protected by the preloader: so how can this be? There is something I'm missing here, I suspect an off-by-one error in my arithmetic. thanks -mike
Re: Attempt to make buttons themed
On 22.03.2005 17:00, Alexandre Julliard wrote: Then the first thing to do is to figure out exactly how Windows does it, and do it the same way. Most interesting is probably to find out how the standard controls from user32 are themed. Poking a bit around in comctl32 6.0, it seems that it actually just registers the standard classes with RegisterClassW, nothing more. AFAIK you can't register a class when the class name is already used, so it would be interesting to know why comctl32.dll can get away with it. -f.r.
Re: registry TODO
Hi, On Tue, Mar 22, 2005 at 03:43:40PM -0800, Steven Edwards wrote about 'Re: registry TODO': > --- Boaz Harrosh <[EMAIL PROTECTED]> wrote: > > How is ReactOS's current (future) system? > I think ReactOS's registry is binary compatible with NT4. It and the windows > 2000 format was > documented/reversed for samba and the linux ntchpwd bootdisk projects. If I > remeber right Eirc > Kohl offered to release some of his work to Wine for the binary format so you > might want to ping > him about the implementation details. Samba currently only has read-only support for NT4 registry files. I'm still trying to figure out how to do writes (i.e. how to do memory management in the hbin blocks). Does ReactOS support such a thing? Cheers, Jelmer -- Jelmer Vernooij <[EMAIL PROTECTED]> - http://jelmer.vernstok.nl/ signature.asc Description: Digital signature
Re: Warn users who attempt to use native DirectDraw
Mike Hearn <[EMAIL PROTECTED]> writes: > Maybe we should just extend the blacklist in the code, some DLLs will > never work as native like ntdll so we just never try and load them. > Probably that'd be better from a usability POV than any warning. That's not what the blacklist does, it just provides defaults, so you still need a warning. I don't think we want to completely disable the possibility of changing the loadorder of system dlls, we just want to make it clear that it's a bad idea if you don't know what you are doing. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Native stack overlapping system heap base address on some systems
Mike Hearn <[EMAIL PROTECTED]> writes: > I know people have been seeing this intermittently for a while now, we > have a few CodeWeavers support tickets with this problem too. The issue > seems to be that the Linux native (main thread) stack was allocated here: > >7fffb000 20K rwx--[ stack ] > > Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x8000 > > Unfortunately I lack enough knowledge about the kernels VM algorithms to > say why it's being allocated here. For comparison on my Fedora Core 3 > machine: > >fef0d000 16K rwx--[ stack ] > > One other thing I don't understand. It seems the stack and the system heap > overlap by exactly 1 byte, otherwise the mmap would not fail. No it doesn't overlap, a 20K mapping at 7fffb000 ends at 7fff. Most likely that kernel is configured for a 2Gb virtual address space. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Attempt to make buttons themed
Frank Richter wrote: Most interesting is probably to find out how the standard controls from user32 are themed. Poking a bit around in comctl32 6.0, it seems that it actually just registers the standard classes with RegisterClassW, nothing more. AFAIK you can't register a class when the class name is already used, so it would be interesting to know why comctl32.dll can get away with it. Maybe it only register as per Process, which makes sense. And it does that before any window is displayed. Actually I know when. (A bug I had) it does it in the InitCommonControlsEx call. Not even in the DLLMain. An app that needs theming needs 3 things. 1. Link to comctl32 2. call InitCommonControlsEx and 3. a manifest. Right? So I guess you have it. I'm not 100% but I think there is no need for duplicate code. All comctl32 needs to do is chain to the user32 classes, only overriding PAINT messages and some mouse events. So you don't have to reinvent the wheel. Do you need lots of themed controls WM_PAINT code? Check out codeproject.com GUILIB project. They owner draw all windows controls with themes support. Free Life Boaz
Re: Attempt to make buttons themed
On 23.03.2005 13:04, Boaz Harrosh wrote: Maybe it only register as per Process, which makes sense. And it does that before any window is displayed. Actually I know when. (A bug I had) it does it in the InitCommonControlsEx call. Not even in the DLLMain. An app that needs theming needs 3 things. 1. Link to comctl32 2. call InitCommonControlsEx and 3. a manifest. Right? So I guess you have it. Sounds plausible. Reading a bit up on window classes on MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windowclasses/aboutwindow.asp) indicates that overrideability of the default system classes is actually intended. I'm not 100% but I think there is no need for duplicate code. All comctl32 needs to do is chain to the user32 classes, only overriding PAINT messages and some mouse events. So you don't have to reinvent the wheel. Sounds feasible to me. -f.r.
Re: lostwages/templates/en contributing.template j ...
I submitted a patch for all casts I could find with that little grep: find . -name "*.[ch]" | xargs egrep "\) *Heap(Re)?Alloc" Jeremy Newman wrote: ChangeSet ID: 16817 CVSROOT:/opt/cvs-commit Module name:lostwages Changes by: [EMAIL PROTECTED] 2005/03/23 08:56:08 Modified files: templates/en : contributing.template janitorial.template resources.template sending_patches.template status.template Log message: Mike McCormack <[EMAIL PROTECTED]> * suggest janitoral project * other updates and W3 fixes Patch: http://cvs.winehq.org/patch.py?id=16817 Old revision New revision Changes Path 1.24 1.25 +3 -3 lostwages/templates/en/contributing.template 1.73 1.74 +17 -7 lostwages/templates/en/janitorial.template 1.11 1.12 +1 -1 lostwages/templates/en/resources.template 1.11 1.12 +2 -0 lostwages/templates/en/sending_patches.template 1.33 1.34 +1 -1 lostwages/templates/en/status.template
Re: Attempt to make buttons themed
Boaz Harrosh wrote: I'm not 100% but I think there is no need for duplicate code. All comctl32 needs to do is chain to the user32 classes, only overriding PAINT messages and some mouse events. So you don't have to reinvent the wheel. Erm, it's not just the painting that needs to be overridden. The controls often need to be able to calculate their size Do you need lots of themed controls WM_PAINT code? Check out codeproject.com GUILIB project. They owner draw all windows controls with themes support. The interface to UxTheme is fairly straight-forward. The SDK sample "ThemeExplorer" is probably worth looking at. Rob
Re: Native stack overlapping system heap base address on some systems
Hi, --- Alexandre Julliard <[EMAIL PROTECTED]> wrote: > > Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x8000 This looks like what I have seen on some users systems running Suse 9.2. Some users see errors like this err:virtual:NtMapViewOfSection map_file_into_view 0x8000 100 0 failed err:heap:HEAP_CreateSystemHeap system heap base address 0x8000 not available > No it doesn't overlap, a 20K mapping at 7fffb000 ends at > 7fff. Most likely that kernel is configured for a 2Gb virtual > address space. I will recompile a kernel with 2GB and see what happens. Thanks Steven __ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
Re: Attempt to make buttons themed
ok, further to what I mentioned before about RegisterUserApiHooks (and poking around in uxtheme.dll), I see the following things being hooked by uxtheme (at least it seems to be the complete list) GetScrollInfo SetScrollInfo EnableScrollBar SetWindowRgn DefWindowProcW DefWindowProcA PreWndProc (probobly stuff that happens internally before the window procedure gets called) PostWndProc (probobly stuff that happens internally after the window procedure gets called) PreDefDlgProc (probobly connected to dialog boxes) PostDefDlgProc (probobly connected to dialog boxes) GetSystemMetrics SystemParametersInfoA SystemParametersInfoW DrawFrameControl DrawCaption MDIRedrawFrame (probobly related to MDI frame windows) Best guess is that RegisterUserApiHook and UnregisterUserApiHook are specifically provided so that uxtheme can override/hook code in user32.dll but at the same time if the themes service is disabled, none of the theming code kicks in. What probobly happens is that uxtheme.dll is loaded into every process (since even apps that know nothing about theming still get themed non-client areas etc AFAIK) which then hooks the user32 APIs to draw the themeing for the non-client areas. Then, theme-aware apps provide a manifest and link to the comctl32.dll 6.0 and from there get proper theming for all their standard (and common) controls. Ordinal 34 (not given any external name by MS) in uxtheme.dll is what installs the user API hooks (what calls it I have no idea, probobly some system component, mabie the Theme service)
World of Warcraft
Sorry to keep bugging you guys about this, but a recent patch broke the opengl mode of World of Warcraft again. It simply fails to start, similar to the d3d mode (except for the fact that I know why d3d mode doesn't work as of now). I was scanning through the traces and saw no errors though. Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure what to look for anyway. If anyone wants me to send a any sort of debug log (if, for instance, you don't have copy of WoW to test on), let me know (include what you'd want to see as well, if you don't mind). Thanks in advance, Darckness
Re: DDRAW: Surface locking patch, take 2
Matthew Mastracci wrote: This patch (correctly) fixes the locking problems in SimCity 3000. We now check to see if the blit src and dest are the same surface and, if so, we make sure to lock the surface only once and, in the case of BltFast, re-adjust the surface pointers. This patch also makes sure the surfaces are correctly unlocked if a bad rectangle is passed. ChangeLog Correctly lock and unlock surface for a single-surface Blt() and BltFast() call. Is there anything wrong with this patch. http://www.winehq.org/hypermail/wine-patches/2005/03/0113.html It works fine for me (and SimCity). and I was wondering why it was not applied. -- Tony Lambregts
Re: World of Warcraft
On Wed, 23 Mar 2005 16:15:18 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Sorry to keep bugging you guys about this, but a recent patch broke the > opengl mode of World of Warcraft again. It simply fails to start, similar to > the d3d mode (except for the fact that I know why d3d mode doesn't work as of > now). I was scanning through the traces and saw no errors though. Seemed > odd to me, but I'm not a wine programmer so I'm not exactly sure what to look > for anyway. If anyone wants me to send a any sort of debug log (if, for > instance, you don't have copy of WoW to test on), let me know (include what > you'd want to see as well, if you don't mind). Which patch specifically broke WoW? If you don't know, can you do a regression test? http://www.winehq.org/site/docs/wine-devel/x1318 -- James Hawkins
World of Warcraft
What I meant to say in the previous message was something along the lines of "Here's an opengl trace; let me know if you need any others." Unfortunately, it seemed to come out in some other language which I am not familiar in. So here's the opengl trace. Darcknesstrace:opengl:X11DRV_OpenGL_Init GLX is up and running error_base = 64 trace:opengl:X11DRV_OpenGL_Init GLX is up and running error_base = 64 trace:opengl:wgl_ext_initialize_extensions GL version : "1.5.3 NVIDIA 71.67". trace:opengl:wgl_ext_initialize_extensions GL version : "1.5.3 NVIDIA 71.67". trace:opengl:wgl_ext_initialize_extensions GL exts : "GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_bo" trace:opengl:wgl_ext_initialize_extensions GLX exts: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address ". trace:opengl:wgl_ext_initialize_extensions Server GLX exts : "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer ". trace:opengl:wgl_ext_initialize_extensions Client GLX exts : "GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_SGI_video_sync GLX_NV_swap_group GLX_NV_video_out GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_swap_control GLX_NV_float_buffer ". fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67" fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address " trace:opengl:wgl_ext_initialize_extensions GL exts : "GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_bo" trace:opengl:wgl_ext_initialize_extensions GLX exts: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address ". trace:opengl:wgl_ext_initialize_extensions Server GLX exts : "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer ". trace:opengl:wgl_ext_initialize_extensions Client GLX exts : "GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_SGI_video_sync GLX_NV_swap_group GLX_NV_video_out GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_swap_control GLX_NV_float_buffer ". fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67" fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address " fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67" fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67" fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address " fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address " trace:opengl:wgl_ext_initialize_extensions Supporting following WGL extensions : "WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_ARB_pbuffer WGL_ARB_pixel_format". trace:opengl:wgl_ext_initialize_extensions Supporting following WGL extensions : "WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_ARB_pbuffer WGL_ARB_pixel_format". fixme:advapi:SetSecurityInfo stub fixme:advapi:SetSecurityInfo stub fixme:user:EnumDisplayDevicesA ((nil),0,0x3b12f6bc,0x), stub! fixme:user:EnumDisplayDevicesA ((nil),0,0x3b12f6bc,0x), stub! fixme:user:EnumDisplayDevicesA ((nil),0,0x3b12f4d8,0x), stub! fixme:user:EnumDisplayDevicesA ((nil),0,0x3b12f4d8,0x), stub! fixme:user:EnumDisplayDevicesA ((nil),0,0x3b12fa78,0x), stub! fixme:user:EnumDisplayDevicesA ((nil),0,0x3b12fa78,0x), stub! fixme:user:EnumDisplayDevicesA
Re: Segfault in X11DRV_DIB_BuildColorTable (DIB_PAL_COLORS)
> I am experiencing a crash during startup of an application (The
> Rosetta Stone 2.0.7a) under Wine. I reported this earlier on
> wine-users and after some debugging was advised to move to this list.
> I am using the latest Wine I built from CVS, after first encountering
> this problem in the 20050111 and 20050310 Gentoo ebuilds. I have a
> Linux 2.6.11 system with glibc 2.3.4 20040808 (including nptl),
> Xorg-x11 6.8.2-rc2 (Trident Cyberblade/i1 "trident_drv.o") @1024x768
> 16bpp. Also tried kernels 2.6.9 & 2.6.10 and 800x600 24bpp
> mode. Would appreciate any advice on how to proceed.
I have attached a patch below which may fix the problem. Index is a
WORD but yet we only have 256 entries in the palette that we get from
GetPaletteEntries - if any of the values is more, we jump past the end
of pal_ents. I've modified the function to allow access to all 65536
colour values and adjust for values that are beyond the range of valid
palette indexes. The patch is completely untested but let me know if
it fixes the issue.
Glenn.
Index: dlls/x11drv/dib.c
===
RCS file: /home/wine/wine/dlls/x11drv/dib.c,v
retrieving revision 1.23
diff -u -r1.23 dib.c
--- dlls/x11drv/dib.c 1 Mar 2005 10:43:19 - 1.23
+++ dlls/x11drv/dib.c 23 Mar 2005 21:16:18 -
@@ -415,18 +415,25 @@
else
{
HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL);
-PALETTEENTRY pal_ents[256];
+ PALETTEOBJ * palPtr = GDI_GetObjPtr( hpal, PALETTE_MAGIC );
WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize);
+ int entry;
-GetPaletteEntries(hpal, 0, 256, pal_ents);
+ if( !palPtr ) return 0;
for(i = 0; i < colors; i++, index++)
{
-colorTable[i].rgbRed = pal_ents[*index].peRed;
-colorTable[i].rgbGreen = pal_ents[*index].peGreen;
-colorTable[i].rgbBlue = pal_ents[*index].peBlue;
+ if( *index > palPtr->logpalette.palNumEntries )
+ entry = palPtr->logpalette.palNumEntries;
+ else
+ entry = *index;
+
+colorTable[i].rgbRed = palPtr->logpalette.palPalEntry[entry].peRed;
+colorTable[i].rgbGreen =
palPtr->logpalette.palPalEntry[entry].peGreen;
+colorTable[i].rgbBlue =
palPtr->logpalette.palPalEntry[entry].peBlue;
colorTable[i].rgbReserved = 0;
}
+ GDI_ReleaseObj( hpal );
}
return colorTable;
}
[AppDB] Application queue: Getting ahead of me.
I will be unable to tend to the application queue for the next week and as a matter of fact I am already behind maintaining it. (sorry). If one of you good souls (with administrative rights) could take could take care of it for the next week I would really appreciate it. Thanks. -- Tony Lambregts
Re: World of Warcraft
On Wed, 23 Mar 2005 15:22:46 -0600 James Hawkins <[EMAIL PROTECTED]> wrote: > On Wed, 23 Mar 2005 16:15:18 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > Sorry to keep bugging you guys about this, but a recent patch broke the > > opengl mode of World of Warcraft again. It simply fails to start, similar > > to the d3d mode (except for the fact that I know why d3d mode doesn't work > > as of now). I was scanning through the traces and saw no errors though. > > Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure > > what to look for anyway. If anyone wants me to send a any sort of debug > > log (if, for instance, you don't have copy of WoW to test on), let me know > > (include what you'd want to see as well, if you don't mind). > > Which patch specifically broke WoW? If you don't know, can you do a > regression test? > http://www.winehq.org/site/docs/wine-devel/x1318 > > -- > James Hawkins My mistake. I meant that a World of Warcraft patch from Blizzard broke it, not that a wine patch broke it.
Re: Segfault in X11DRV_DIB_BuildColorTable (DIB_PAL_COLORS)
The patch worked like a charm. I guess it's true about arrays being evil :) Thanks, Jesse Z. > I have attached a patch below which may fix the problem. Index is a > WORD but yet we only have 256 entries in the palette that we get from > GetPaletteEntries - if any of the values is more, we jump past the end > of pal_ents. I've modified the function to allow access to all 65536 > colour values and adjust for values that are beyond the range of valid > palette indexes. The patch is completely untested but let me know if > it fixes the issue.
Re: World of Warcraft
On Wednesday 23 March 2005 22:15, [EMAIL PROTECTED] wrote:
> Sorry to keep bugging you guys about this, but a recent patch broke the
> opengl mode of World of Warcraft again. It simply fails to start, similar
> to the d3d mode (except for the fact that I know why d3d mode doesn't work
> as of now). I was scanning through the traces and saw no errors though.
> Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure
> what to look for anyway. If anyone wants me to send a any sort of debug
> log (if, for instance, you don't have copy of WoW to test on), let me know
> (include what you'd want to see as well, if you don't mind).
>
> Thanks in advance,
> Darckness
Hi,
can you try with this patch ?
Regards,
Raphael
Index: wgl_ext.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
retrieving revision 1.4
diff -u -r1.4 wgl_ext.c
--- wgl_ext.c 10 Mar 2005 11:13:33 - 1.4
+++ wgl_ext.c 23 Mar 2005 22:35:50 -
@@ -31,6 +31,7 @@
#include "winuser.h"
#include "winerror.h"
+#include "gdi.h"
#include "wgl.h"
#include "wgl_ext.h"
#include "opengl_ext.h"
@@ -133,6 +134,18 @@
return bTest;
}
+int (*p_glXSwapIntervalSGI)(int);
+BOOL query_function_swap_control(glXGetProcAddressARB_t proc, const char *gl_version, const char *gl_extensions,
+ const char* glx_version, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+ BOOL bTest = (0 <= strcmp("1.3", glx_version) || NULL != strstr(glx_extensions, "GLX_SGIX_swap_group"));
+ if (bTest) {
+p_glXSwapIntervalSGI = proc("glXSwapIntervalSGI");
+bTest = (NULL != p_glXSwapIntervalSGI);
+ }
+ return bTest;
+}
/***
* wglGetExtensionsStringEXT(OPENGL32.@)
*/
@@ -157,18 +170,21 @@
* wglSwapIntervalEXT(OPENGL32.@)
*/
BOOL WINAPI wglSwapIntervalEXT(int interval) {
-FIXME("(%d),stub!\n", interval);
-
-swap_interval = interval;
-return TRUE;
+ TRACE("(%d)\n", interval);
+ swap_interval = interval;
+ if (NULL != p_glXSwapIntervalSGI) {
+return 0 == p_glXSwapIntervalSGI(interval);
+ }
+ WARN("(): GLX_SGI_swap_control extension seems not supported \n");
+ return TRUE;
}
/***
* wglGetSwapIntervalEXT(OPENGL32.@)
*/
int WINAPI wglGetSwapIntervalEXT(VOID) {
-FIXME("(),stub!\n");
-return swap_interval;
+ TRACE("() returns %d\n", swap_interval);
+ return swap_interval;
}
typedef struct wine_glpbuffer {
@@ -226,9 +242,9 @@
#define WGL_STENCIL_BITS_ARB 0x2023
#define WGL_AUX_BUFFERS_ARB 0x2024
-#define WGL_PBUFFER_WIDTH_ARB0x2034
-#define WGL_PBUFFER_HEIGHT_ARB 0x2035
-#define WGL_PBUFFER_LOST_ARB 0x2036
+#define WGL_PBUFFER_WIDTH_ARB 0x2034
+#define WGL_PBUFFER_HEIGHT_ARB 0x2035
+#define WGL_PBUFFER_LOST_ARB0x2036
#if 0 /* not used yet */
static unsigned ConvertAttribGLXtoWGL(const int* iWGLAttr, int* oGLXAttr) {
@@ -273,6 +289,7 @@
case WGL_SAMPLES_ARB:
*/
default:
+ FIXME("unsupported %x WGL Attribute\n", iWGLAttr[cur]);
break;
}
++cur;
@@ -282,14 +299,108 @@
GLboolean WINAPI wglGetPixelFormatAttribivARB(HDC hdc, int iPixelFormat, int iLayerPlane, UINT nAttributes, const int *piAttributes, int *piValues)
{
-TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane, nAttributes, piAttributes, piValues);
-return GL_TRUE;
+ Display* display = get_display( hdc );
+ UINT i;
+ GLXFBConfig* cfgs = NULL;
+ GLXFBConfig curCfg = NULL;
+ int nCfgs = 0;
+ int hTest;
+ int tmp;
+ int curGLXAttr = 0;
+
+ TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane, nAttributes, piAttributes, piValues);
+
+ if (0 < iLayerPlane) {
+FIXME("unsupported iLayerPlane(%d) > 0, returns FALSE\n", iLayerPlane);
+return GL_FALSE;
+ }
+
+ cfgs = glXGetFBConfigs(display, DefaultScreen(display), &nCfgs);
+ if (NULL == cfgs) {
+ERR("no FB Configs found for display(%p)\n", display);
+return GL_FALSE;
+ }
+
+ for (i = 0; i < nAttributes; ++i) {
+const int curWGLAttr = piAttributes[i];
+
+switch (curWGLAttr) {
+case WGL_NUMBER_PIXEL_FORMATS_ARB:
+ piValues[i] = nCfgs;
+ continue ;
+
+case WGL_SUPPORT_OPENGL_ARB:
+ piValues[i] = GL_TRUE;
+ continue ;
+
+case WGL_TRANSPARENT_ARB:
+ curGLXAttr = GLX_TRANSPARENT_TYPE;
+ if (nCfgs < iPixelFormat) goto pix_error;
+ curCfg = cfgs[iPixelFormat];
+ hTest = glXGetFBConfigAttrib(display, curCfg, curGLXAttr, &tmp);
+ if (hTest) goto get_error;
+ piValues[i] = GL_FALSE;
+ if (GLX_NONE != tmp) piValues[i] = GL_TRUE;
+ continue ;
+
+case WGL_COLOR_BITS_ARB:
+ curGLXAttr = GLX_BUFFER_
Re: World of Warcraft
On Wed, 23 Mar 2005 23:37:49 +0100 Raphael <[EMAIL PROTECTED]> wrote: > On Wednesday 23 March 2005 22:15, [EMAIL PROTECTED] wrote: > > Sorry to keep bugging you guys about this, but a recent patch broke the > > opengl mode of World of Warcraft again. It simply fails to start, similar > > to the d3d mode (except for the fact that I know why d3d mode doesn't work > > as of now). I was scanning through the traces and saw no errors though. > > Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure > > what to look for anyway. If anyone wants me to send a any sort of debug > > log (if, for instance, you don't have copy of WoW to test on), let me know > > (include what you'd want to see as well, if you don't mind). > > > > Thanks in advance, > > Darckness > > Hi, > > can you try with this patch ? > > Regards, > Raphael > Still doesn't work. I attached another opengl trace in case you can pick out something that's changed though. Darcknesstrace:opengl:X11DRV_OpenGL_Init GLX is up and running error_base = 64 trace:opengl:X11DRV_OpenGL_Init GLX is up and running error_base = 64 trace:opengl:wgl_ext_initialize_extensions GL version : "1.5.3 NVIDIA 71.67". trace:opengl:wgl_ext_initialize_extensions GL version : "1.5.3 NVIDIA 71.67". trace:opengl:wgl_ext_initialize_extensions GL exts : "GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_bo" trace:opengl:wgl_ext_initialize_extensions GLX exts: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address ". trace:opengl:wgl_ext_initialize_extensions Server GLX exts : "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer ". trace:opengl:wgl_ext_initialize_extensions Client GLX exts : "GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_SGI_video_sync GLX_NV_swap_group GLX_NV_video_out GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_swap_control GLX_NV_float_buffer ". fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67" fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address " trace:opengl:wgl_ext_initialize_extensions GL exts : "GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_imaging GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_texture_bo" trace:opengl:wgl_ext_initialize_extensions GLX exts: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address ". trace:opengl:wgl_ext_initialize_extensions Server GLX exts : "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer ". trace:opengl:wgl_ext_initialize_extensions Client GLX exts : "GLX_ARB_get_proc_address GLX_ARB_multisample GLX_EXT_visual_info GLX_EXT_visual_rating GLX_EXT_import_context GLX_SGI_video_sync GLX_NV_swap_group GLX_NV_video_out GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_swap_control GLX_NV_float_buffer ". fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67" fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address " fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67" fixme:opengl:query_function_pbuffer gl_version is: "1.5.3 NVIDIA 71.67" fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address " fixme:opengl:query_function_pbuffer glx_exts is: "GLX_EXT_visual_info GLX_EXT_visual_rating GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGI_video_sync GLX_SGI_swap_control GLX_ARB_multisample GLX_NV_float_buffer GLX_ARB_get_proc_address " trace:opengl:wgl_ext_initialize_extensions Supporting following WGL extensions : "WGL_ARB_extensions_string WGL_EXT_extensions_string WGL_ARB_pbuffer WGL_ARB_pix
Re: Attempt to make buttons themed
On Wednesday 23 March 2005 07:04 am, Boaz Harrosh wrote: > Maybe it only register as per Process, which makes sense. And it does > that before any window is displayed. Actually I know when. (A bug I had) > it does it in the InitCommonControlsEx call. Not even in the DLLMain. An > app that needs theming needs 3 things. 1. Link to comctl32 2. call > InitCommonControlsEx and 3. a manifest. Right? So I guess you have it. Part if the initialization happens for each process in InitCommonControlsEx However, the theme functions still do not work 100% in windows until after at least one window is created There is also a "Themes" service that IIRC caches the theme data itself to share between processes and initialize some system-wide hooks
Re: World of Warcraft
Hi again,
> > Hi,
> >
> > can you try with this patch ?
> >
> > Regards,
> > Raphael
>
> Still doesn't work. I attached another opengl trace in case you can pick
> out something that's changed though.
>
> Darckness
Thx, intersesting :)
And this one ?
Regards,
Raphael
Index: wgl_ext.c
===
RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v
retrieving revision 1.4
diff -u -r1.4 wgl_ext.c
--- wgl_ext.c 10 Mar 2005 11:13:33 - 1.4
+++ wgl_ext.c 23 Mar 2005 23:51:05 -
@@ -31,6 +31,7 @@
#include "winuser.h"
#include "winerror.h"
+#include "gdi.h"
#include "wgl.h"
#include "wgl_ext.h"
#include "opengl_ext.h"
@@ -133,6 +134,18 @@
return bTest;
}
+int (*p_glXSwapIntervalSGI)(int);
+BOOL query_function_swap_control(glXGetProcAddressARB_t proc, const char *gl_version, const char *gl_extensions,
+ const char* glx_version, const char *glx_extensions,
+ const char *server_glx_extensions, const char *client_glx_extensions)
+{
+ BOOL bTest = (0 <= strcmp("1.3", glx_version) || NULL != strstr(glx_extensions, "GLX_SGIX_swap_group"));
+ if (bTest) {
+p_glXSwapIntervalSGI = proc("glXSwapIntervalSGI");
+bTest = (NULL != p_glXSwapIntervalSGI);
+ }
+ return bTest;
+}
/***
* wglGetExtensionsStringEXT(OPENGL32.@)
*/
@@ -157,18 +170,21 @@
* wglSwapIntervalEXT(OPENGL32.@)
*/
BOOL WINAPI wglSwapIntervalEXT(int interval) {
-FIXME("(%d),stub!\n", interval);
-
-swap_interval = interval;
-return TRUE;
+ TRACE("(%d)\n", interval);
+ swap_interval = interval;
+ if (NULL != p_glXSwapIntervalSGI) {
+return 0 == p_glXSwapIntervalSGI(interval);
+ }
+ WARN("(): GLX_SGI_swap_control extension seems not supported \n");
+ return TRUE;
}
/***
* wglGetSwapIntervalEXT(OPENGL32.@)
*/
int WINAPI wglGetSwapIntervalEXT(VOID) {
-FIXME("(),stub!\n");
-return swap_interval;
+ TRACE("() returns %d\n", swap_interval);
+ return swap_interval;
}
typedef struct wine_glpbuffer {
@@ -226,9 +242,12 @@
#define WGL_STENCIL_BITS_ARB 0x2023
#define WGL_AUX_BUFFERS_ARB 0x2024
-#define WGL_PBUFFER_WIDTH_ARB0x2034
-#define WGL_PBUFFER_HEIGHT_ARB 0x2035
-#define WGL_PBUFFER_LOST_ARB 0x2036
+#define WGL_PBUFFER_WIDTH_ARB 0x2034
+#define WGL_PBUFFER_HEIGHT_ARB 0x2035
+#define WGL_PBUFFER_LOST_ARB0x2036
+
+#define WGL_TYPE_RGBA_ARB 0x202B
+#define WGL_TYPE_COLORINDEX_ARB 0x202C
#if 0 /* not used yet */
static unsigned ConvertAttribGLXtoWGL(const int* iWGLAttr, int* oGLXAttr) {
@@ -249,6 +268,18 @@
pop = iWGLAttr[++cur];
PUSH2(oGLXAttr, GLX_BUFFER_SIZE, pop);
break;
+case WGL_BLUE_BITS_ARB:
+ pop = iWGLAttr[++cur];
+ PUSH2(oGLXAttr, GLX_BLUE_SIZE, pop);
+ break;
+case WGL_RED_BITS_ARB:
+ pop = iWGLAttr[++cur];
+ PUSH2(oGLXAttr, GLX_RED_SIZE, pop);
+ break;
+case WGL_GREEN_BITS_ARB:
+ pop = iWGLAttr[++cur];
+ PUSH2(oGLXAttr, GLX_GREEN_SIZE, pop);
+ break;
case WGL_ALPHA_BITS_ARB:
pop = iWGLAttr[++cur];
PUSH2(oGLXAttr, GLX_ALPHA_SIZE, pop);
@@ -265,14 +296,34 @@
pop = iWGLAttr[++cur];
PUSH2(oGLXAttr, GLX_DOUBLEBUFFER, pop);
break;
+
+case WGL_PIXEL_TYPE_ARB:
+ pop = iWGLAttr[++cur];
+ switch (pop) {
+ case WGL_TYPE_RGBA_ARB: pop = GLX_RGBA_BIT; break ;
+ case WGL_TYPE_COLORINDEX_ARB: pop = GLX_COLOR_INDEX_BIT; break ;
+ default:
+ ERR("unexpected PixelType(%x)\n", pop);
+ pop = 0;
+ }
+ PUSH2(oGLXAttr,GLX_RENDER_TYPE, pop);
+ break;
+
case WGL_DRAW_TO_WINDOW_ARB:
-case WGL_SUPPORT_OPENGL_ARB:
+case WGL_DRAW_TO_BITMAP_ARB:
+case WGL_SUPPORT_GDI_ARB:
+ pop = iWGLAttr[++cur];
+ PUSH2(oGLXAttr, GLX_X_RENDERABLE, pop);
+ break;
+
case WGL_ACCELERATION_ARB:
-/*
-case WGL_SAMPLE_BUFFERS_ARB:
-case WGL_SAMPLES_ARB:
-*/
+case WGL_SUPPORT_OPENGL_ARB:
+ pop = iWGLAttr[++cur];
+ /** nothing to do, if we are here, supposing support Accelerated OpenGL */
+ break;
+
default:
+ FIXME("unsupported %x WGL Attribute\n", iWGLAttr[cur]);
break;
}
++cur;
@@ -282,14 +333,118 @@
GLboolean WINAPI wglGetPixelFormatAttribivARB(HDC hdc, int iPixelFormat, int iLayerPlane, UINT nAttributes, const int *piAttributes, int *piValues)
{
-TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat, iLayerPlane, nAttributes, piAttributes, piValues);
-return GL_TRUE;
+ Display* display = get_display( hdc );
+ UINT i;
+ GLXFBConfig* cfgs = NULL;
+ GLXFBConfig curCfg = NULL;
+ int nCfgs = 0;
+ int hTest;
+ int tmp;
+ int curGLXAttr = 0;
+
+ TRACE("(%p, %d, %d, %d, %p, %p)\n", hdc, iPixelFormat,
Re: World of Warcraft
On Thu, 24 Mar 2005 00:52:24 +0100 Raphael <[EMAIL PROTECTED]> wrote: > Hi again, > > > > Hi, > > > > > > can you try with this patch ? > > > > > > Regards, > > > Raphael > > > > Still doesn't work. I attached another opengl trace in case you can pick > > out something that's changed though. > > > > Darckness > > Thx, intersesting :) > > And this one ? > > Regards, > Raphael I sent another message earlier, but it had a bz2 opengl log which seems to have gotten held up somewhere. So I'll send this one (without a log) in the hopes that it will get through and you'll be able to do something. First email: >I've got good news and bad news. The good news is that the World of Warcraft >loads now, which is excellent. The bad news twofold: the performance is >AWFUL, and it crashes out in the same place as before (when wine was missing >pbuffer support). But it loads! Darckness
I think I know how uxtheme works...
What I strongly suspect happens is this: 1.The themes service is always loaded and running and holds the theme data (and it contains details of which .msstyles file to use) 2.At some point (either at startup if the changes are global or when an app loads if the changes are app specific, I cant find where this bit happens but I suspect the themes service does this) control passes to ordinal 34 in uxtheme.dll (aka ThemeHooksInstall acording to uxtheme.pdb). This function calls an undocumented function in user32 called RegisterUserApiHooks (which appears to be taylor made for uxtheme to do what it needs to do). The function hooks: GetScrollInfo SetScrollInfo EnableScrollBar SetWindowRgn DefWindowProcW DefWindowProcA PreWndProc (probobly stuff that happens internally before the window procedure gets called) PostWndProc (probobly stuff that happens internally after the window procedure gets called) PreDefDlgProc (probobly connected to dialog boxes) PostDefDlgProc (probobly connected to dialog boxes) GetSystemMetrics SystemParametersInfoA SystemParametersInfoW DrawFrameControl DrawCaption MDIRedrawFrame (probobly related to MDI frame windows) This is what causes all apps (including non-theme-aware ones) to get themed non-client areas (window borders etc) 3.Apps that are theme aware have a manifest, load comctl32.dll 6.0 and probobly have to call InitCommonControlsEx (although I think some of the code in the dllmain for comctl32.dll 6.0 may also end up calling InitCommonControlsEx). This causes new versions of the stock classes (button, list box, edit, combo box etc etc etc) to be created and registered. A cursory examination of some of these classes shows that they dont seem to "pull code" from the stock implementation in user32.dll (i.e. anything they dont themselves handle goes back to DefWindowProc). In particular, it doesnt appear as though they have any knowledge of the classes or window procedures contained in user32.dll. then 4.Apps that need to do something extra call into functions exported by uxtheme.dll to do whatever they need to do. user32.dll seems to have no knowledge whatsoever about themeing and uxtheme. All that user32 has is RegisterUserApiHooks (and the matching UnregisterUserApiHooks) that uxtheme uses to hook into user32.dll and do stuff. Exactly how the theme service and theme engine works "under the hood" doesnt matter. But for ReactOS and WINE purposes, I suggest we implement the following: 1.A function similar to RegisterUserApiHooks/UnregisterUserApiHooks (either reverse engineer the MS function or write our own). This will allow uxtheme to hook into the global drawing for things like window borders without user32 needing to care about uxtheme and what uxtheme does (just like how MS hooks into user32 that way) 2.Whatver code is necessary to get the hooks installed right so that all apps get the "global" theming like on real windows 3.Support to read the manifest and load a new comctl32.dll that would be like the version 6 from microsoft (and would contain complete theme-aware implementations of the stock controls just like MS comctl32.dll 6.0 does) and 4.All the needed uxtheme exports to make stuff run This would be the same way Microsoft does things. User32.dll would have no idea whatsoever about uxtheme and theming All apps would get non-client-area themeing like on windows. And only theme aware apps would get themed controls etc (the rest would get "stock" windows controls) Oh and btw, if this "reverse engineering" is not "clean room" enough for WINE and ReactOS, let me know and I will stop posting it :)
Re: [ros-dev] I think I know how uxtheme works...
Also related to this (as pointed out in IRC) is Activation Contexts/SxS stuff), we need this to make sure the correct window classes are used at the correct time.
Re: I think I know how uxtheme works...
Jonathan Wilson wrote: Exactly how the theme service and theme engine works "under the hood" doesnt matter. But for ReactOS and WINE purposes, I suggest we implement the following: 1.A function similar to RegisterUserApiHooks/UnregisterUserApiHooks (either reverse engineer the MS function or write our own). This will I really don't like the way you're going about figuring these things out. It seems to me like you're disassembling and reading assembly the Microsoft DLLs, as you've done in the past (your cards.dll "implementation"). This bars you from them reimplementing them, IMO. Please don't post stuff like this to wine-devel. Reading descriptions on MSDN and writing test programs should be sufficient for figuring out how Windows works. Mike
[RFC] Pager: why do we implement WM_NCPAINT instead of WM_PAINT?
Hi folks, Does anyone know why the Pager common control (dlls/comctl32/pager.c) implements WM_NCPAINT instead of WM_PAINT? It is the only exception to the rule, all other controls implement WM_PAINT. -- Dimi.
Re: [RFC] Pager: why do we implement WM_NCPAINT instead of WM_PAINT?
Dimitrie O. Paun wrote: Hi folks, Does anyone know why the Pager common control (dlls/comctl32/pager.c) implements WM_NCPAINT instead of WM_PAINT? It is the only exception to the rule, all other controls implement WM_PAINT. We need to scroll a child window. In order to do this we move the child window in the controls client area, using the clipping region that is automatically set around the client area. As the entire client area now consists of the child window, we must allocate space (WM_NCCALCSIZE) for the buttons and draw them as a non-client area (WM_NCPAINT). This is all off the top of my head. I hope it makes sense. Rob
