Re: [dib.c] 3. Remove identity colormap changing for monochrome bitmaps

2005-12-02 Thread Oldrich Jedlicka
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; xwidth; x++) {
-dstval|=((XGetPixel( bmpImage, x, h) = white) ^ neg)  (7 - (x7));
+dstval|=(XGetPixel( bmpImage, x, h) = white)  (7 - (x7));
 if ((x7)==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, 

Re: [dib.c] 3. Remove identity colormap changing for monochrome bitmaps

2005-12-02 Thread Oldrich Jedlicka
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: state of wine on amd64 with ia32

2005-12-02 Thread Christoph Frick
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: state of wine on amd64 with ia32

2005-12-02 Thread Marcus Meissner
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




D3D7 WineD3D success

2005-12-02 Thread Juergen Wieczorek
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 Unhandled 

Re: [msxml] libuuid

2005-12-02 Thread Huw D M Davies
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.




Unnormal slowness in Heroes 4 (X11DRV_BitBlt?)

2005-12-02 Thread Marinescu-Ghetau Iulian

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: msvidc32: Remove unused DllMain() function

2005-12-02 Thread Dmitry Timoshkov
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.





Re: [RESEND] riched20: register ListBox ComboBox classes

2005-12-02 Thread Alexandre Julliard
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: Steam regression of the day

2005-12-02 Thread Ivan Gyurdiev

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: opengl support in wine

2005-12-02 Thread Stefan Dösinger
 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




DBGRID32.OCX fix - RFC

2005-12-02 Thread Alex Villací­s Lasso
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: DBGRID32.OCX fix - RFC

2005-12-02 Thread Robert Shearman

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





Re: DBGRID32.OCX fix - RFC

2005-12-02 Thread Alex Villací­s Lasso

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: ddraw: make some driver info not const

2005-12-02 Thread Vitaliy Margolen
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

2005-12-02 Thread Alex Villací­s Lasso

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: CVSROOT/. loginfo

2005-12-02 Thread Ron Jensen
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: CVSROOT/. loginfo

2005-12-02 Thread Alexandre Julliard
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]




wglGetPixelFormatAttribivARB unexpected RenderType(100)

2005-12-02 Thread Toan T Nguyen
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: [OLE #155] Fix Invoking dispinterface Functions

2005-12-02 Thread Robert Shearman

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





Re: wglGetPixelFormatAttribivARB unexpected RenderType(100)

2005-12-02 Thread fenix
 
 
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;



Debugging winelib apps in Eclipse

2005-12-02 Thread Michael Ost
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)

2005-12-02 Thread Toan T Nguyen
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








Re: CVSROOT/. loginfo

2005-12-02 Thread James Hawkins
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: Debugging winelib apps in Eclipse

2005-12-02 Thread James Hawkins
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: Debugging winelib apps in Eclipse

2005-12-02 Thread Eric Pouech

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