Re: Debugging winelib apps in Eclipse
Michael Ost wrote: Does anyone know how to set up Eclipse to debug winelib applications? I tried just replacing 'gdb' with 'winedbg' on the "Debugger" tab on the "Debug" window. After Eclipse says "Launching..." there is an error that says "Process terminated." After reviewing the winelib debug docs, I found that there is a --gdb switch to winedbg so I added that as a "C/C++ Program Argument" on the "Arguments" tab of the same window... a long shot, and it didn't work. This is on Fedora Core 4, with Eclipse 3.1 (yum updated from the 3.1M6 version that comes with FC4), and with the wine 0.99.2 FC4 rpm. Any leads? Thanks ... mo I'd rather set the debugger name to winedbg --gdb instead of winedbg. If you use the C++ pgm args, the final command line will be: winedbg myapp.exe --gdb instead of winedbg --gdb myapp.exe HTH -- Eric Pouech
Re: Debugging winelib apps in Eclipse
On 12/2/05, Michael Ost <[EMAIL PROTECTED]> wrote: > Does anyone know how to set up Eclipse to debug winelib applications? > > I tried just replacing 'gdb' with 'winedbg' on the "Debugger" tab on the > "Debug" window. After Eclipse says "Launching..." there is an error that > says "Process terminated." > You're probably going to have to find a way to make Eclipse run wine-pthread directly instead of the wine binary. -- James Hawkins
Re: CVSROOT/. loginfo
On 12/2/05, Alexandre Julliard <[EMAIL PROTECTED]> wrote: > Ron Jensen <[EMAIL PROTECTED]> writes: > > > Alexandre, > > > > Can we get the Module name and/or modified files added back to the > > subject line for CVS? IHMO, this is much more useful than knowing who > > submitted the patch. > > Well, I think having some description of what the patch is about is > more useful than a truncated file list, but if the general feeling is > that the file list is better I can put this back. > One vote for patch description instead of file list here. The only thing I would like to see that the file list provided is the area affected by the patch. Say one of Rob's OLE patches is committed, then it would be nice to see OLE in the subject somewhere, though it's not essential. -- James Hawkins
Re: wglGetPixelFormatAttribivARB unexpected RenderType(100)
Hi, Unfortunately, now Q2E cannot detects any valid pixel format. Here is the Q2E output from wine-0.9.2 == Initializing OpenGL driver ...getting DC: succeeded ...getting gamma ramp: failed fixme:opengl:wglMakeCurrent (0x398,0x47c91210) fixme:opengl:wglMakeCurrent created a delayed OpenGL context (0x7c3108d8) for 0x7c310740 fixme:opengl:wglMakeCurrent make current for dis 0x7c021e68, drawable 0x342, ctx 0x7c3 108d8 fixme:opengl:wglMakeCurrent returning True ...19 pixel formats found ...PIXELFORMAT 2 rejected, improper flags ...PIXELFORMAT 3 rejected, insufficient stencil bits (0 < 8) ...PIXELFORMAT 4 rejected, improper flags ...PIXELFORMAT 6 rejected, improper flags ...PIXELFORMAT 7 rejected, insufficient stencil bits (0 < 8) ...PIXELFORMAT 8 rejected, improper flags ...PIXELFORMAT 10 rejected, improper flags ...PIXELFORMAT 11 rejected, insufficient stencil bits (0 < 8) ...PIXELFORMAT 12 rejected, improper flags ...PIXELFORMAT 14 rejected, improper flags ...PIXELFORMAT 15 rejected, insufficient stencil bits (0 < 8) ...PIXELFORMAT 16 rejected, improper flags ...PIXELFORMAT 17 rejected, software emulation err:opengl:wglGetPixelFormatAttribivARB unexpected RenderType(100) ...PIXELFORMAT 18 rejected, software emulation err:opengl:wglGetPixelFormatAttribivARB unexpected RenderType(100) ...PIXELFORMAT 19 rejected, software emulation fixme:opengl:wglMakeCurrent ((nil),(nil)) fixme:opengl:wglMakeCurrent returning True ...hardware acceleration found ...PIXELFORMAT 1 selected ...creating GL context: succeeded And here is the output from winecvs + your patch: Initializing OpenGL driver ...getting DC: succeeded ...getting gamma ramp: failed ...19 pixel formats found ...PIXELFORMAT 1 rejected, insufficient color bits (1 < 32) ...PIXELFORMAT 2 rejected, improper flags ...PIXELFORMAT 3 rejected, insufficient color bits (1 < 32) ...PIXELFORMAT 4 rejected, improper flags ...PIXELFORMAT 5 rejected, insufficient color bits (1 < 32) ...PIXELFORMAT 6 rejected, improper flags ...PIXELFORMAT 7 rejected, insufficient color bits (1 < 32) ...PIXELFORMAT 8 rejected, improper flags ...PIXELFORMAT 9 rejected, insufficient color bits (1 < 32) ...PIXELFORMAT 10 rejected, improper flags ...PIXELFORMAT 11 rejected, insufficient color bits (1 < 32) ...PIXELFORMAT 12 rejected, improper flags ...PIXELFORMAT 13 rejected, insufficient color bits (1 < 32) ...PIXELFORMAT 14 rejected, improper flags ...PIXELFORMAT 15 rejected, insufficient color bits (1 < 32) ...PIXELFORMAT 16 rejected, improper flags ...PIXELFORMAT 17 rejected, software emulation ...PIXELFORMAT 18 rejected, software emulation ...PIXELFORMAT 19 rejected, software emulation ...no hardware acceleration found ...failed to find an appropriate PIXELFORMAT ...destroying window VID_AppActivate( 0 ) ...restoring display settings ...shutting down QGL == I can send you the source file of Q2E where OpenGL is initialized if you want. Bests, Toan On 12/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Message d'origine > >Date: Fri, 2 Dec 2005 14:07:24 -0800 > >De: Toan T Nguyen <[EMAIL PROTECTED]> > >A: wine-devel@winehq.org > >Sujet: wglGetPixelFormatAttribivARB unexpected RenderType(100) > > > >Hi, > > > >I compile and run Quake2Evolved in linux using winelib. Although every > >seems fine, there's this error printed out when Q2E scans for the best > >pixel format: > > > > err:opengl:wglGetPixelFormatAttribivARB unexpected RenderType(100) > > > >I look up my /usr/include/GL/glxATI.h and found these lines: > > > >#ifndef GLX_ATI_pixel_format_float > >#define GLX_ATI_pixel_format_float 1 > > > >#define GLX_RGBA_FLOAT_ATI_BIT 0x0100 > > > >#endif // GLX_ATI_pixel_format_float > > > > > >Bests, > > > >Toan > > > > Hi > > Interesting and fun extension :) > Try attached patch if it works (and it should) forward it to wine-patches > > Regards, > Raphael > > > >
Debugging winelib apps in Eclipse
Does anyone know how to set up Eclipse to debug winelib applications? I tried just replacing 'gdb' with 'winedbg' on the "Debugger" tab on the "Debug" window. After Eclipse says "Launching..." there is an error that says "Process terminated." After reviewing the winelib debug docs, I found that there is a --gdb switch to winedbg so I added that as a "C/C++ Program Argument" on the "Arguments" tab of the same window... a long shot, and it didn't work. This is on Fedora Core 4, with Eclipse 3.1 (yum updated from the 3.1M6 version that comes with FC4), and with the wine 0.99.2 FC4 rpm. Any leads? Thanks ... mo
Re: wglGetPixelFormatAttribivARB unexpected RenderType(100)
Message d'origine >Date: Fri, 2 Dec 2005 14:07:24 -0800 >De: Toan T Nguyen <[EMAIL PROTECTED]> >A: wine-devel@winehq.org >Sujet: wglGetPixelFormatAttribivARB unexpected RenderType(100) > >Hi, > >I compile and run Quake2Evolved in linux using winelib. Although every >seems fine, there's this error printed out when Q2E scans for the best >pixel format: > > err:opengl:wglGetPixelFormatAttribivARB unexpected RenderType(100) > >I look up my /usr/include/GL/glxATI.h and found these lines: > >#ifndef GLX_ATI_pixel_format_float >#define GLX_ATI_pixel_format_float 1 > >#define GLX_RGBA_FLOAT_ATI_BIT 0x0100 > >#endif // GLX_ATI_pixel_format_float > > >Bests, > >Toan > Hi Interesting and fun extension :) Try attached patch if it works (and it should) forward it to wine-patches Regards, Raphael Index: wgl_ext.c === RCS file: /home/wine/wine/dlls/opengl32/wgl_ext.c,v retrieving revision 1.13 diff -u -r1.13 wgl_ext.c --- wgl_ext.c 24 Nov 2005 18:45:12 - 1.13 +++ wgl_ext.c 2 Dec 2005 23:53:42 - @@ -328,6 +328,16 @@ #define WGL_AUX8_ARB0x208F #define WGL_AUX9_ARB0x2090 +/** + * WGL_ATI_pixel_format_float + */ +#define WGL_TYPE_RGBA_FLOAT_ATI 0x21A0 +#define GL_TYPE_RGBA_FLOAT_ATI 0x8820 +#define GL_COLOR_CLEAR_UNCLAMPED_VALUE_ATI 0x8835 +/** GLX_ATI_pixel_format_float */ +#define GLX_RGBA_FLOAT_ATI_BIT 0x0100 + + #if 0 /* not used yet */ static unsigned ConvertAttribGLXtoWGL(const int* iWGLAttr, int* oGLXAttr) { unsigned nAttribs = 0; @@ -392,8 +402,9 @@ 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; isColor = 1; break ; + case WGL_TYPE_RGBA_ARB: pop = GLX_RGBA_BIT; break ; + case WGL_TYPE_RGBA_FLOAT_ATI: pop = GLX_RGBA_FLOAT_ATI_BIT; break ; default: ERR("unexpected PixelType(%x)\n", pop); pop = 0; @@ -559,8 +570,9 @@ hTest = glXGetFBConfigAttrib(display, curCfg, curGLXAttr, &tmp); if (hTest) goto get_error; switch (tmp) { - case GLX_RGBA_BIT: piValues[i] = WGL_TYPE_RGBA_ARB; break; case GLX_COLOR_INDEX_BIT: piValues[i] = WGL_TYPE_COLORINDEX_ARB; break ; + case GLX_RGBA_BIT: piValues[i] = WGL_TYPE_RGBA_ARB; break; + case GLX_RGBA_FLOAT_ATI_BIT: piValues[i] = WGL_TYPE_RGBA_FLOAT_ATI; break ; default: ERR("unexpected RenderType(%x)\n", tmp); piValues[i] = WGL_TYPE_RGBA_ARB;
Re: [OLE #155] Fix Invoking dispinterface Functions
Robert Shearman wrote: ChangeLog: Fix invoking dispinterface functions by using the internal representation of the function, not the one returned to applications. I've just noticed that this function now has some duplicated code, so don't use this patch. I'll send a replacement one with a correction. -- Rob Shearman
wglGetPixelFormatAttribivARB unexpected RenderType(100)
Hi, I compile and run Quake2Evolved in linux using winelib. Although every seems fine, there's this error printed out when Q2E scans for the best pixel format: err:opengl:wglGetPixelFormatAttribivARB unexpected RenderType(100) I look up my /usr/include/GL/glxATI.h and found these lines: #ifndef GLX_ATI_pixel_format_float #define GLX_ATI_pixel_format_float 1 #define GLX_RGBA_FLOAT_ATI_BIT 0x0100 #endif // GLX_ATI_pixel_format_float Bests, Toan
Re: CVSROOT/. loginfo
Ron Jensen <[EMAIL PROTECTED]> writes: > Alexandre, > > Can we get the Module name and/or modified files added back to the > subject line for CVS? IHMO, this is much more useful than knowing who > submitted the patch. Well, I think having some description of what the patch is about is more useful than a truncated file list, but if the general feeling is that the file list is better I can put this back. -- Alexandre Julliard [EMAIL PROTECTED]
Re: CVSROOT/. loginfo
Alexandre, Can we get the Module name and/or modified files added back to the subject line for CVS? IHMO, this is much more useful than knowing who submitted the patch. Thankyou, Ron Jensen On Fri, 2005-12-02 at 09:43 -0600, Alexandre Julliard wrote: > ChangeSet ID: 21634 > CVSROOT: /opt/cvs-commit > Module name: CVSROOT > Changes by: [EMAIL PROTECTED] 2005/12/02 09:43:52 > > Modified files: > . : loginfo > > Log message: > Don't send mail to wine-cvs for the wine module, this will be done > from the git repository. > > Patch: http://cvs.winehq.org/patch.py?id=21634 > > Old revision New revision Changes Path > 1.50 1.51 +2 -1 CVSROOT/loginfo > > Index: CVSROOT/loginfo > diff -u -p CVSROOT/loginfo:1.50 CVSROOT/loginfo:1.51 > --- CVSROOT/loginfo:1.50 2 Dec 2005 15:43:52 - > +++ CVSROOT/loginfo 2 Dec 2005 15:43:52 - > @@ -28,7 +28,8 @@ > # Use this for testing > ^test /usr/bin/perl $CVSROOT/CVSROOT/log_accum -m [EMAIL PROTECTED] -f > $CVSROOT/CVSROOT/commitlog -S -s %p %s > > +^wine /usr/bin/perl $CVSROOT/CVSROOT/log_accum -f $CVSROOT/CVSROOT/commitlog > -S -s %p %s > + > # All others go to wine-cvs > -^wine /usr/bin/perl $CVSROOT/CVSROOT/log_accum -m [EMAIL PROTECTED] -f > $CVSROOT/CVSROOT/commitlog -L 200 -p -S -s %p %s > DEFAULT /usr/bin/perl $CVSROOT/CVSROOT/log_accum -m [EMAIL PROTECTED] -f > $CVSROOT/CVSROOT/commitlog -P winehq -L 200 -p -c -S -s %p %s > > >
Re: DBGRID32.OCX fix - RFC
Alex Villacís Lasso wrote: Robert Shearman wrote: What hRefType is passed to the function? I don't think the above is quite correct. Can you try changing the if statement to something like this: if (hRefType == -1 && (This->TypeAttr.typekind == TKIND_DISPATCH) && (This->TypeAttr.wTypeFlags & (TYPEFLAG_FDUAL|TYPEFLAG_FDISPATCHABLE))) That would not keep the app from crashing. For the case of DBGRID32.OCX, hRefType is systematically == 19, and it says so in the ERR message just before the crash. However, on a second look, maybe the problem is not that the function performs the wrong action, but that it returns the wrong value (E_FAIL, should be TYPE_E_ELEMENTNOTFOUND). I have to check this alternate theory on my home machine. Alex Villacís Lasso More information: if the flag dumping portion of the patch is applied, but the condition portion is not, and a dump of the available references is added, the following is the result when trying to load DBGRID32.OCX: fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x0640 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x0190 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x03e8 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x0031 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x0708 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x0258 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x00c8 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x003d fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x0578 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x07d0 fixme:ole:ITypeInfo_fnGetRefTypeInfopRefType->reference == 0x fixme:ole:ITypeInfo_fnGetRefTypeInfo Can't find pRefType for ref 19 fixme:ole:ITypeInfo_fnGetRefTypeInfotypekind is TKIND_DISPATCH fixme:ole:ITypeInfo_fnGetRefTypeInfowTypeFlags are: TYPEFLAG_FHIDDEN TYPEFLAG_FNONEXTENSIBLE TYPEFLAG_FDISPATCHABLE wine: Unhandled page fault on read access to 0x0010 at address 0x230f4f31 (thread 0009), starting debugger... BTW, no luck on the bad-return-value theory, the app keeps crashing. Alex Villacís Lasso
Re: ddraw: make some driver info not const
Friday, December 2, 2005, 11:46:39 AM, Rein Klazes wrote: > Hi, [skip] > Making this information not const makes the application proceed further. > Changelog: > dlls/ddraw: ddraw_hal.c, ddraw_user.c > Make some driver info not const, some applications want to modify it. This is wrong. No user program should modify our internal data. I think you need to copy this data into heap before passing it to the app. You should make simple test to check if the data returned on windows is within heap or not. Vitaliy
Re: DBGRID32.OCX fix - RFC
Robert Shearman wrote: What hRefType is passed to the function? I don't think the above is quite correct. Can you try changing the if statement to something like this: if (hRefType == -1 && (This->TypeAttr.typekind == TKIND_DISPATCH) && (This->TypeAttr.wTypeFlags & (TYPEFLAG_FDUAL|TYPEFLAG_FDISPATCHABLE))) That would not keep the app from crashing. For the case of DBGRID32.OCX, hRefType is systematically == 19, and it says so in the ERR message just before the crash. However, on a second look, maybe the problem is not that the function performs the wrong action, but that it returns the wrong value (E_FAIL, should be TYPE_E_ELEMENTNOTFOUND). I have to check this alternate theory on my home machine. Alex Villacís Lasso
Re: DBGRID32.OCX fix - RFC
Alex Villacís Lasso wrote: I would like to know if the attached patch (which prevents DBGRID32.OCX from crashing, as well as adding additional debugging information when a reference is not found) would step on anybody's toes (especially Robert Shearman, since he is sending several oleaut32 patches himself). As of 2005-12-01 CVS, any VisualBasic application that tries to use DBGRID32.OCX will systematically crash unless the patch is applied. However, since Robert Shearman is sending oleaut32 fixes, I think he might implement some functionality that will, as a side effect, fix the DBGRID32.OCX bug. No, I have no plans to change anything that should affect this. ITypeInfoImpl *This = (ITypeInfoImpl *)iface; HRESULT result = E_FAIL; -if (hRefType == -1 && - (((ITypeInfoImpl*) This)->TypeAttr.typekind == TKIND_DISPATCH) && - (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & TYPEFLAG_FDUAL)) +if ( +( +hRefType == -1 && +(This->TypeAttr.typekind == TKIND_DISPATCH) && +(This->TypeAttr.wTypeFlags & TYPEFLAG_FDUAL) +) +|| +( +(This->TypeAttr.typekind == TKIND_DISPATCH) && +(This->TypeAttr.wTypeFlags & TYPEFLAG_FDISPATCHABLE) + ) + ) { What hRefType is passed to the function? I don't think the above is quite correct. Can you try changing the if statement to something like this: if (hRefType == -1 && (This->TypeAttr.typekind == TKIND_DISPATCH) && (This->TypeAttr.wTypeFlags & (TYPEFLAG_FDUAL|TYPEFLAG_FDISPATCHABLE))) -- Rob Shearman
DBGRID32.OCX fix - RFC
I would like to know if the attached patch (which prevents DBGRID32.OCX from crashing, as well as adding additional debugging information when a reference is not found) would step on anybody's toes (especially Robert Shearman, since he is sending several oleaut32 patches himself). As of 2005-12-01 CVS, any VisualBasic application that tries to use DBGRID32.OCX will systematically crash unless the patch is applied. However, since Robert Shearman is sending oleaut32 fixes, I think he might implement some functionality that will, as a side effect, fix the DBGRID32.OCX bug. Alex Villacís Lasso --- wine-0.9.2-cvs/dlls/oleaut32/typelib.c 2005-12-01 10:15:14.0 -0500 +++ wine-0.9.2-cvs-patch/dlls/oleaut32/typelib.c 2005-12-02 11:48:11.0 -0500 @@ -5520,9 +5520,18 @@ ITypeInfoImpl *This = (ITypeInfoImpl *)iface; HRESULT result = E_FAIL; -if (hRefType == -1 && - (((ITypeInfoImpl*) This)->TypeAttr.typekind == TKIND_DISPATCH) && - (((ITypeInfoImpl*) This)->TypeAttr.wTypeFlags & TYPEFLAG_FDUAL)) +if ( +( +hRefType == -1 && +(This->TypeAttr.typekind == TKIND_DISPATCH) && +(This->TypeAttr.wTypeFlags & TYPEFLAG_FDUAL) +) +|| +( +(This->TypeAttr.typekind == TKIND_DISPATCH) && +(This->TypeAttr.wTypeFlags & TYPEFLAG_FDISPATCHABLE) + ) + ) { /* when we meet a DUAL dispinterface, we must create the interface * version of it. @@ -5551,8 +5560,47 @@ if(pRefType->reference == hRefType) break; } - if(!pRefType) - FIXME("Can't find pRefType for ref %lx\n", hRefType); + if(!pRefType) { +static const char * descTKIND[TKIND_MAX] = { +"TKIND_ENUM", +"TKIND_RECORD", +"TKIND_MODULE", +"TKIND_INTERFACE", +"TKIND_DISPATCH", +"TKIND_COCLASS", +"TKIND_ALIAS", +"TKIND_UNION", +}; +static const char * descTypeFlags[15] = { +"TYPEFLAG_FAPPOBJECT", +"TYPEFLAG_FCANCREATE", +"TYPEFLAG_FLICENSED", +"TYPEFLAG_FPREDECLID", +"TYPEFLAG_FHIDDEN", +"TYPEFLAG_FCONTROL", +"TYPEFLAG_FDUAL", +"TYPEFLAG_FNONEXTENSIBLE", +"TYPEFLAG_FOLEAUTOMATION", +"TYPEFLAG_FRESTRICTED", +"TYPEFLAG_FAGGREGATABLE", +"TYPEFLAG_FREPLACEABLE", +"TYPEFLAG_FDISPATCHABLE", +"TYPEFLAG_FREVERSEBIND", +"TYPEFLAG_FPROXY", +}; +int i; + +FIXME("Can't find pRefType for ref %lx\n", hRefType); +FIXME("\ttypekind is %s\n", descTKIND[This->TypeAttr.typekind]); +FIXME("\twTypeFlags are:"); +for (i = 0; i < 15; i++) { +if (This->TypeAttr.wTypeFlags & (1 << i)) +FIXME(" %s", descTypeFlags[i]); +} +if (This->TypeAttr.wTypeFlags & 0x8000) +FIXME(" %08x", This->TypeAttr.wTypeFlags & 0x8000); +FIXME("\n"); + } if(pRefType && hRefType != -1) { ITypeLib *pTLib = NULL;
Re: opengl support in wine
> My approach is: > ... I can't comment on the technical details, because I am not an OpenGL expert at all. But I'd like to test it when you're finished. There may be a workaround for the glReadPixels slowlyness. I've seen that both mplayer and xine can draw a 2D movie fast onto an OpenGL texture, as long as the player window isn't overlapped too much. At least they pretend to use OpenGL to render the video. Once the window is overlapped, it becomes slow as hell( 1 fps, if not less). > One note though, just one week ago I've had a nVidia 6800 on a 8x AGP > bus. And I still could get ~500MB/s readback using glReadPixels(), that > makes ~100 fps. This 1fps glReadPixels() is clearly an ATI issue. That's > also why I would never buy an ATI card, because, honestly, they suck > (I've had one, and it sucked badly, their drivers crashed the whole > computer hardly when I've tried to play World of Warcraft). Sure it's an ATI driver bug. But I can't change my notebooks graphics chip ;) To be fair: The ATI driver is constantly improving, and it's really useable now. The only thing that bothers me right now, is the recent regression on old cards introduced with fglrx 8.19.10. I really hope they fix it. How is the nvidia driver doing recently? Does it have acpi suspend support? How is the speed compared to the Windows drivers? Stefan
Re: Steam regression of the day
Stefan Dösinger wrote: Hello, The relevant bugzilla is here: http://bugs.winehq.org/show_bug.cgi?id=2926 I'm just curious if this patch has been forgotten, or if this issue is just too difficult to fix at this time. The problem Steam shows is common to all boarderless Apps which don't specify the WS_EX_APPWINDOW flag. Fixing it is quite tricky, Ok, so maybe I should stop asking about it then :) Just making sure it isn't forgotten... The other problem I mentioned, by the way, (invisible fonts) has been fixed, and Steam now appears to work (you still have to re-try 10 or so times to get past the memory assertion bug...). I'm downloading HL2 quickly, before it breaks again!
Re: [RESEND] riched20: register ListBox & ComboBox classes
Cihan Altinay <[EMAIL PROTECTED]> writes: > It seems this patch was ignored and I would appreciate some comments because > I haven't done much wine development yet (and probably made a lot of > mistakes). > Basically, I did some reverse engineering to see what is going on under > Windows > and implemented the (de)registration of the two classes accordingly. The > effect > of the patch can be seen in the attached screenshots which is the Options > dialog of MS PowerPoint 2003. The bit about the magic flag values is quite ugly, you should use one boolean variable for each registered class instead. -- Alexandre Julliard [EMAIL PROTECTED]
Re: msvidc32: Remove unused DllMain() function
"Francois Gouget" <[EMAIL PROTECTED]> wrote: > msvideo1.c defines a DllMain() function but: > * it is not exported in the spec file > * it is not referenced in any way anywhere else > * the native dll does not export a DllMain function either DllMain does not need to be exported to define an entry point of the DLL. Moreover, DllMain of msvidc32 initializes MSVIDC32_hModule which is used later on. -- Dmitry.
Unnormal slowness in Heroes 4 (X11DRV_BitBlt?)
See http://bugs.winehq.org/show_bug.cgi?id=3902 Hey guys, a bit of help here! I did the following changes: -added member to X_PHYSBITMAP: XRectangle modified_rect; -added 2 functions: /*** * X11DRV_SetBoundRect */ void X11DRV_SetBoundRect(X_PHYSBITMAP *physBitmap, INT x, INT y, INT width, INT height) { XRectangle *t; INT xMin,yMin,xMax,yMax; if (!physBitmap) return; t = &(physBitmap->modified_rect); if ( t->width && t->height && /*already a valid rect inside*/ width && height ) /*not trying to invalidate rect*/ { //calculate the union of the two rectangles xMin = ((t->x < x)?t->x:x); yMin = ((t->y < y)?t->y:y); xMax = ((t->x + t->width > x + width)?(t->x + t->width):(x + width)); yMax = ((t->y + t->height > y + height)?(t->y + t->height):(y + height)); t->x = xMin; t->y = yMin; t->width = xMax - xMin; t->height = yMax - yMin; } else { t->x = x; t->y = y; t->width = width; t->height = height; } TRACE("(%p,%d,%d,%d,%d)\n", physBitmap->hbitmap, t->x, t->y, t->width, t->height); } /*** * X11DRV_GetBoundRect */ UINT X11DRV_GetBoundRect(X_PHYSBITMAP *physBitmap, INT *x, INT *y, INT *width, INT *height) { DIBSECTION dib; XRectangle *t; if (!physBitmap || GetObjectW( physBitmap->hbitmap, sizeof(dib), &dib ) != sizeof(dib)) { ERR("called for non-DIBSection!?\n"); return 1; } t = &(physBitmap->modified_rect); /* we should check for oversize values */ if ( (t->width > 0) && (t->height > 0) && (t->x < dib.dsBm.bmWidth) && (t->y < dib.dsBm.bmHeight) ) { *x = t->x; *y = t->y; if (t->x + t->width > dib.dsBm.bmWidth) *width = dib.dsBm.bmWidth - t->x; else *width = t->width; if (t->y + t->height > dib.dsBm.bmHeight) *height = dib.dsBm.bmHeight - t->y; else *height = t->height; } else { *x = 0; *y = 0; *width = dib.dsBm.bmWidth; *height = dib.dsBm.bmHeight; } TRACE("(%p,%d,%d,%d,%d)\n", physBitmap->hbitmap, *x, *y, *width, *height); return 0; } -changed X11DRV_DIB_DoUpdateDIBSection like this: static void X11DRV_DIB_DoUpdateDIBSection(X_PHYSBITMAP *physBitmap, BOOL toDIB) { INT x,y,width,height; if ( X11DRV_GetBoundRect(physBitmap,&x,&y,&width,&height) ) return; /*invalidate bound rect*/ X11DRV_SetBoundRect(physBitmap,0,0,0,0); X11DRV_DIB_DoCopyDIBSection(physBitmap, toDIB, physBitmap->colorMap, physBitmap->nColorMap, physBitmap->pixmap, x, y, x, y, width, height); } - and finally, a GDI function calls it like this (for example bitblt): X11DRV_SetBoundRect(physDevDst->bitmap,xDst,yDst,width,height); X11DRV_CoerceDIBSection( physDevDst, DIB_Status_GdiMod, FALSE ); if (physDevDst != physDevSrc) { X11DRV_SetBoundRect(physDevSrc->bitmap,xSrc,ySrc,width,height); X11DRV_CoerceDIBSection( physDevSrc, DIB_Status_GdiMod, FALSE ); } result = BITBLT_InternalStretchBlt( physDevDst, xDst, yDst, width, height, physDevSrc, xSrc, ySrc, width, height, rop ); END: if (physDevDst != physDevSrc) X11DRV_UnlockDIBSection( physDevSrc, FALSE ); X11DRV_UnlockDIBSection( physDevDst, TRUE ); What am i doing wrong, i mean is my logic correct ?
Re: [msxml] libuuid
On Thu, Dec 01, 2005 at 10:52:07PM +0100, Raphael wrote: > On Thursday 01 December 2005 22:43, Huw D M Davies wrote: > > On Thu, Dec 01, 2005 at 10:02:25PM +0100, Raphael wrote: > > > Hi, > > > > > > Changelog: > > > - add needed uuid generation > > > > I don't think libuuid should contain the msxml2 uuids; at least the > > version I have doesn't. > > > > Huw. > > ?? its only an archive > Only msxml >= 3 uuids seems to need to be redeclared It becomes a problem if we use those uuids in a test suite and then try to compile that test with msvc. Huw.
D3D7 & WineD3D success
I've posted the message below to wine-users earlier, but I guess it's more appropriate here. Switched to wine-0.9.2 meanwhile, but Tomb Raider 4 behaves just the same. +++quote Hi! I've just installed wine-0.9.1 on my Fedora Core 3 system (Radeon 9600XT - fglrx-8.19.10). While TR3(demo) setup & gameplay runs okay, TR4 breaks and gives me this error output after the setup screen is thru: ALSA lib seq_hw.c:446:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or dir ectory err:int:INSTR_EmulateInstruction mov cr4,eax at 0x0048da53 err:int:INSTR_EmulateInstruction mov cr4,eax at 0x0048da64 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >((nil),004d) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >(0x10022,0015) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) fixme:ddraw:Main_DirectDraw_CreateSurface failed surface creation with code 0x8876007 8 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >(0x10022,0008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >(0x10022,0015) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) fixme:ddraw:Main_DirectDraw_CreateSurface failed surface creation with code 0x8876007 8 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >(0x10022,0008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >((nil),0008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >((nil),004d) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >(0x10022,0015) err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (00 0a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (000 b) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (000c) value : 000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK ( 000d) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL ( 0010) value : 0001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (0 01e) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS ( 0028) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (0030) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (00 8a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (00 97) value : ! fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >(0x10022,0008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >(0x10022,0015) err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (00 0a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (000 b) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (000c) value : 000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANEMASK ( 000d) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTPIXEL ( 0010) value : 0001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISIBLE (0 01e) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEANTIALIAS ( 0028) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_RANGEFOGENABLE (0030) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EXTENTS (00 8a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_VERTEXBLEND (00 97) value : ! fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >(0x10022,0008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef1a18)- >((nil),0008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fef21a0)- >(0x10022,0813) err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LINEPATTERN (00 0a) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_MONOENABLE (000 b) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ROP2 (000c) value : 000d ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_PLANE 000d) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_LASTP 0010) value : 0001 ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_ZVISI 01e) value : ! err:ddraw:set_render_state Unhandled dwRenderStateType D3DRENDERSTATE_EDGEA 0028) value : ! err:ddraw:set_render_state Un
Re: state of wine on amd64 with ia32
On Fri, Dec 02, 2005 at 10:54:03AM +0100, Christoph Frick wrote: > On Thu, Dec 01, 2005 at 07:01:24PM +0100, Alexandre Julliard wrote: > > > > can someone enlightenme, what the current state of this is? i run a > > > dual opteron with ubuntu linux on it. after some symlinking with the > > > ia32-libs and a change in wine (SYS_sigaction -> SYS_rt_sigaction > > > (read this in a very old post from 2004 or so) it finally compiled > > > (using gcc-4.0 -m32). > > If you need to change wine it means your 32-bit build environment is > > broken, you are not using the correct 32-bit kernel headers. > > thanks Marcus & Alexandre for the info - i will try my best to find out > whats missing. The distributor needs to setup a correct 32bit enviroment... In your case it is likely missing the 2 /usr/include/asm-XXX/ directories, seperated by WORDSIZE #ifs in /usr/include/asm/ wrappers. (a glibc problem). Also 32bit development and runtime libraries must correctly be setup. Ciao, Marcus
Re: state of wine on amd64 with ia32
On Thu, Dec 01, 2005 at 07:01:24PM +0100, Alexandre Julliard wrote: > > can someone enlightenme, what the current state of this is? i run a > > dual opteron with ubuntu linux on it. after some symlinking with the > > ia32-libs and a change in wine (SYS_sigaction -> SYS_rt_sigaction > > (read this in a very old post from 2004 or so) it finally compiled > > (using gcc-4.0 -m32). > If you need to change wine it means your 32-bit build environment is > broken, you are not using the correct 32-bit kernel headers. thanks Marcus & Alexandre for the info - i will try my best to find out whats missing. -- cu pgpAeWg5uLf3I.pgp Description: PGP signature
Re: [dib.c] 3. Remove identity colormap changing for monochrome bitmaps
I have to read my emails four times before sending :-) So what I meant: I did not find exactly the solution for the problem with failed tests (which keeps my second path in the game), but completely different approach by removing pixmap_depth=1 (and also my second patch that is unneeded then). Regards, Oldrich.
Re: [dib.c] 3. Remove identity colormap changing for monochrome bitmaps
Hi again, I did not find the problem, but I found different solution - for consideration: There is problem that with pixmap_depth we loose the color information - there can be workaround found for this (what I suggested in the second patch). I removed now all the pixmap_depth stuff (just to test it) and received what I expected - tests are running correctly (and some todos passed) and the game Neighbours from Hell is also working correctly - I know that this doesn't mean that it is the correct way to do it. So there are two ways: * Find a solution with monochrome bitmaps * Change monochrome bitmaps to use pixmap_depth=screen as other DIBs Any hint - which way to go? I think I do not have time during the weekend, so I will probably look at it next week on Monday. Used patch for "colored" monochrome bitmaps is attached. Cheers, Oldrich. Dne Thursday 01 of December 2005 18:37 Alexandre Julliard napsal(a): > Oldrich Jedlicka <[EMAIL PROTECTED]> writes: > > This fixes colors in monochrome bitmaps that were overwritten by identity > > colormap every time. > > > > Changelog: > > > > * Remove the identity color map overwriting on all monochrome bitmaps > > This breaks the tests: > > bitmap.c:399: Test failed: lower left pixel is 00ff00ff > bitmap.c:400: Test failed: bottom but one, left pixel is ff00 Index: dlls/x11drv/dib.c === RCS file: /home/wine/wine/dlls/x11drv/dib.c,v retrieving revision 1.47 diff -u -r1.47 dib.c --- dlls/x11drv/dib.c 1 Dec 2005 17:15:21 - 1.47 +++ dlls/x11drv/dib.c 2 Dec 2005 08:22:08 - @@ -290,29 +290,19 @@ { const RGBQUAD * rgb = (const RGBQUAD *)colorPtr; -if (depth == 1) /* Monochrome */ -for (i = start; i < end; i++, rgb++) -colorMapping[i] = (rgb->rgbRed + rgb->rgbGreen + - rgb->rgbBlue > 255*3/2); -else -for (i = start; i < end; i++, rgb++) -colorMapping[i] = X11DRV_PALETTE_ToPhysical( physDev, RGB(rgb->rgbRed, -rgb->rgbGreen, -rgb->rgbBlue)); +for (i = start; i < end; i++, rgb++) +colorMapping[i] = X11DRV_PALETTE_ToPhysical( physDev, RGB(rgb->rgbRed, +rgb->rgbGreen, +rgb->rgbBlue)); } else { const RGBTRIPLE * rgb = (const RGBTRIPLE *)colorPtr; -if (depth == 1) /* Monochrome */ -for (i = start; i < end; i++, rgb++) -colorMapping[i] = (rgb->rgbtRed + rgb->rgbtGreen + - rgb->rgbtBlue > 255*3/2); -else -for (i = start; i < end; i++, rgb++) -colorMapping[i] = X11DRV_PALETTE_ToPhysical( physDev, RGB(rgb->rgbtRed, - rgb->rgbtGreen, - rgb->rgbtBlue)); +for (i = start; i < end; i++, rgb++) +colorMapping[i] = X11DRV_PALETTE_ToPhysical( physDev, RGB(rgb->rgbtRed, + rgb->rgbtGreen, + rgb->rgbtBlue)); } } else /* DIB_PAL_COLORS */ @@ -896,26 +885,19 @@ notsupported: { BYTE* dstbyte; -BYTE neg = 0; unsigned long white = (1 << bmpImage->bits_per_pixel) - 1; /* any bmp format -> pal 1 dib */ -if ((unsigned)colors[0].rgbRed+colors[0].rgbGreen+colors[0].rgbBlue >= -(unsigned)colors[1].rgbRed+colors[1].rgbGreen+colors[1].rgbBlue ) -neg = 1; - -WARN("from unknown %d bit bitmap (%lx,%lx,%lx) to 1 bit DIB, " - "%s color mapping\n", +WARN("from unknown %d bit bitmap (%lx,%lx,%lx) to 1 bit DIB\n", bmpImage->bits_per_pixel, bmpImage->red_mask, - bmpImage->green_mask, bmpImage->blue_mask, - neg?"negative":"direct" ); + bmpImage->green_mask, bmpImage->blue_mask); for (h=lines-1; h>=0; h--) { BYTE dstval; dstbyte=dstbits; dstval=0; for (x=0; x= white) ^ neg) << (7 - (x&7)); +dstval|=(XGetPixel( bmpImage, x, h) >= white) << (7 - (x&7)); if ((x&7)==7) { *dstbyte++=dstval; dstval=0; @@ -4159,7 +4141,6 @@ { DIBSECTION dibSection; X11DRV_DIB_IMAGEBITS_DESCR descr; - int identity[2] = {0,1}; if (!GetObjectW( physBitmap->hbitmap, siz