August 2004 - Wine-devel - list.winehq.org

Patch for CreateDIBitmap: Don't create monochrome bitmaps (help wanted)
by Michael Kaufmann 26 Aug '04

26 Aug '04

Hi all, I need some help in fixing a bug in CreateDIBitmap. I've attached a patch, but unfortunately it introduces new bugs. The function CreateDIBitmap creates a monochrome device-dependent bitmap if it's possible. But that's very bad, because BitBlt and StretchBlt handle monochrome bitmaps in a different way than color bitmaps (copied from MSDN): "If *StretchBlt* must convert a monochrome bitmap to a color bitmap, it sets white bits (1) to the background color and black bits (0) to the foreground color. The foreground and background colors of the device context with color are used." So SetTextColor and SetBkColor can change the colors of the (formerly device independent) bitmap, and that's not what we want. The attached patch fixes this bug (don't create monochrome bitmaps anymore), but it seems that other code in WINE depends on the old behavior. The mouse cursor is now completely garbage. Can anybody help me finding the remaining bugs? Test Program (DIB-Testcase.zip): --------------------------------- I've created a test program that shows the problem. It also shows a bug in Windows! It displays two bitmaps, both should be black and white. WINE displays them red on green (I've set these colors with SetTextColor/SetBkColor). The images differ only in a single byte. I've used the program bmpdump ( http://david.tribble.com/programs.html ) to analyze them. In the color table of the bitmaps, the rgbReserved member of a RGBQUAD structure is 0x00 for the left bitmap and 0xFF for the right bitmap. This shouldn't make a difference. But Windows creates a monochrome bitmap for the left one, and a color bitmap for the right one! Does anyone understand this behavior? Regards Michael Index: dlls/gdi/dib.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/dib.c,v retrieving revision 1.3 diff -u -r1.3 dib.c --- dlls/gdi/dib.c 12 Aug 2004 20:02:39 -0000 1.3 +++ dlls/gdi/dib.c 23 Aug 2004 14:45:03 -0000 @@ -779,7 +779,6 @@ UINT coloruse ) { HBITMAP handle; - BOOL fColor; DWORD width; int height; WORD bpp; @@ -789,79 +788,10 @@ if (DIB_GetBitmapInfo( header, &width, &height, &bpp, &compr ) == -1) return 0; if (height < 0) height = -height; - /* Check if we should create a monochrome or color bitmap. */ - /* We create a monochrome bitmap only if it has exactly 2 */ - /* colors, which are black followed by white, nothing else. */ - /* In all other cases, we create a color bitmap. */ - - if (bpp != 1) fColor = TRUE; - else if ((coloruse != DIB_RGB_COLORS) || !data) fColor = FALSE; - else - { - if (data->bmiHeader.biSize == sizeof(BITMAPINFOHEADER)) - { - RGBQUAD *rgb = data->bmiColors; - DWORD col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - - /* Check if the first color of the colormap is black */ - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - /* If the second color is white, create a monochrome bitmap */ - fColor = (col != RGB(0xff,0xff,0xff)); - } - /* Note : If the first color of the colormap is white - followed by black, we have to create a color bitmap. - If we don't the white will be displayed in black later on!*/ - else fColor = TRUE; - } - else if (data->bmiHeader.biSize == sizeof(BITMAPCOREHEADER)) - { - RGBTRIPLE *rgb = ((BITMAPCOREINFO *)data)->bmciColors; - DWORD col = RGB( rgb->rgbtRed, rgb->rgbtGreen, rgb->rgbtBlue ); - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbtRed, rgb->rgbtGreen, rgb->rgbtBlue ); - fColor = (col != RGB(0xff,0xff,0xff)); - } - else fColor = TRUE; - } - else if (data->bmiHeader.biSize == sizeof(BITMAPV4HEADER)) - { /* FIXME: correct ? */ - RGBQUAD *rgb = data->bmiColors; - DWORD col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - - /* Check if the first color of the colormap is black */ - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - /* If the second color is white, create a monochrome bitmap */ - fColor = (col != RGB(0xff,0xff,0xff)); - } - /* Note : If the first color of the colormap is white - followed by black, we have to create a color bitmap. - If we don't the white will be displayed in black later on!*/ - else fColor = TRUE; - } - else - { - ERR("(%ld): wrong/unknown size for data\n", - data->bmiHeader.biSize ); - return 0; - } - } - - /* Now create the bitmap */ - if (!(dc = DC_GetDCPtr( hdc ))) return 0; - if (fColor) - handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), + handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), GetDeviceCaps( hdc, BITSPIXEL ), NULL ); - else handle = CreateBitmap( width, height, 1, 1, NULL ); if (handle) {

2 3

Re: Don
by Ivan Leo Puoti 26 Aug '04

26 Aug '04

>Maybe, yes. How long does it take? I didn't time it but it does take some time. >I think I killed it after about 5 >minutes of constant thrashing. Maybe you should just leave it and see how long it takes. >Possibly it's something to do with using the FC2 kernel instead of a >stock one ? I don't know much about the FC2 kernel, maybe you should try with the real thing www.kernel.org Ivan.

1 0

broken freecell
by gslink 26 Aug '04

26 Aug '04

Has anyone noticed that one of the patches in either the July or August release broke the Microsoft Freecell. It used to be that when the full screen button was pressed the Freecell window expanded to fill the screen. Now the fill is only in the vertical. Dragging appears to work but results in a ghost border when the full screen button in Freecell is pushed and the window snaps back to original size in the horizontal.

2 1

Document dosdevices/unc/
by Tobias Burnus 26 Aug '04

26 Aug '04

Hello, I found an email by Fergal Daly (http://www.mail-archive.com/wine-devel(a)winehq.org/msg08815.html) which kind of patches configuring.sgml to document dosdevices/unc. I transformed it into a proper patch for configuring.sgml Tobias

1 1

notes under wine under qemu with the help of pth
by Rafael Ávila de Espíndola 26 Aug '04

26 Aug '04

I was trying to run lotus notes under wine under qemu. Unfortunately qemu appears to have some trouble with linuxthreads. For example, consider the following program test.c: #include <pthread.h> #include <stdio.h> void * f(void *oie) { printf("tata\n"); pthread_exit(oie); return NULL; } int main() { pthread_t t; int i; pthread_create(&t,NULL,f,&i); printf("blit\n"); pthread_join(t, NULL); return 0; } I can compile and run it natively: $ gcc -Wall -o test -lpthread test.c $ ./test tata blit but qemu (i386 -> i386) fails: $ qemu-i386 ./teste qemu: Unsupported syscall: 258 Segmentation fault My next attempt was to use pth (www.gnu.org/software/pth) export LD_LIBRARY_PATH=/home/rafael/inst/pth/lib gcc -Wall -o teste -I/home/rafael/inst/pth/include/ -L/home/rafael/inst/pth/lib/-lpthread test.c $ ./test blit tata $ qemu-i386 ./teste blit tata Success with the test program. Wine is able to run putty and notes6 when compiled with linuxthreads. To compile wine with pth I had to create empty pthreadtypes.h and sigthread.h files in the pth include dir and apply the attached patch in wine. When compiled with pth wine is able to run putty (even inside qemu!). Unfortunately it fails to run notes6: wine "c:\lotus\notes\nlnotes.exe" fixme:console:SetConsoleCtrlHandler ((nil),0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x601aa540,1) - no error checking or testing yet fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 wine client error:d: version mismatch 0/147. Your wineserver binary was not upgraded correctly, or you have an older one somewhere in your PATH. Or maybe the wrong wineserver is still running? wine client error:d: read: Bad file descriptor wine client error:d: read: Bad file descriptor There was no wineserver running when I started the program and only one was in the path. The log of a successful execution when linked with linuxthreads is: fixme:console:SetConsoleCtrlHandler ((nil),0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x601aa540,1) - no error checking or testing yet fixme:ole:CoRegisterMessageFilter stub fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154 fixme:hook:NotifyWinEvent (32782,0x10036,-4,2)-stub! fixme:console:SetConsoleCtrlHandler ((nil),0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler (0x601aa540,1) - no error checking or testing yet fixme:ole:CoRegisterMessageFilter stub fixme:console:SetConsoleCtrlHandler (0x601aa540,0) - no error checking or testing yet fixme:console:SetConsoleCtrlHandler ((nil),1) - no error checking or testing yet I have followed the instructions present in http://vowe.net/archives/004104.html to install notes. Thanks for any help Rafael

1 0

runtime change to WINEDEBUG output
by James Hawkins 26 Aug '04

26 Aug '04

Hi, Is there a way to change the trace options of WINEDEBUG during runtime? For example, let's say I'm running an installer that encounters a fatal error during one part of the install. I'm not exactly sure where in the wine code base this error is occurring and it would take forever if I set WINEDEBUG=trace+all and had to wait till I get to the right section to find the error. If this is not a feature we have, would it be possible to write a simple program that will send a message to the wineserver telling it to change it's WINEDEBUG value during runtime? I have no idea how this would be implemented or if anyone else would actually want this feature, but if you have any ideas let me know. Thanks. -- James Hawkins

5 11

Re: Don't compile winetest as part of the main build
by Mike Hearn 26 Aug '04

26 Aug '04

Hi Alexandre, Was this dropped? On my laptop (a 600mhz Pentium with 128mb of ram, so not too pokey) attempting to build the winetest binary actually kills the build dead. It ends up attempting to feed ~20mb of data to gas which doesn't make it very happy. I guess I misphrased it - it's not for slower machines, it's for machines with less memory. There's not much reason to run the entire winetest binary on Wine itself, so why do we always build it ? thanks -mike > Mike Hearn <mike_at_navi.cx> > Don't compile winetest as part of the main build to avoid > problems on low memory machines. > > --- programs/winetest/Makefile.in.~1.30.~ 2004-07-22 20:43:42.000000000 +0100 > +++ programs/winetest/Makefile.in 2004-08-01 23:44:24.334453984 +0100 > @@ -1,3 +1,7 @@ > +# MKPROG_SKIP > + > +# This program must be built explicitly to make compiles on slower machines easier > + > TOPSRCDIR = @top_srcdir@ > TOPOBJDIR = ../.. > SRCDIR = @srcdir@

4 4

Re: Don't compile winetest as part of the main build
by Ivan Leo Puoti 26 Aug '04

26 Aug '04

> On my laptop (a 600mhz Pentium with 128mb of ram, so > not too pokey) attempting to build the winetest binary actually kills > the build dead. I have a 500 mhz laptop with 128 mv of ram, and winetest builds quite successfully, so maybe it's something wrong with your build toolchain, or your configuration, or something else like that? Ivan.

2 1

Re: Don't fall back to OSS when Drivers=""
by Mike Hearn 26 Aug '04

26 Aug '04

Ditto, was there something wrong with this one? > Mike Hearn <mike_at_navi.cx> > Don't fall back to OSS when Drivers="" > > --- dlls/winmm/lolvldrv.c.~1.58.~ 2004-06-01 20:40:48.000000000 +0100 > +++ dlls/winmm/lolvldrv.c 2004-08-03 22:01:16.795976000 +0100 > @@ -731,6 +731,9 @@ > size = sizeof(buffer); > if (!RegQueryValueExA(hKey, "Drivers", 0, &type, (LPVOID)buffer, &size)) { > p1 = buffer; > + > + if (!*p1) return TRUE; /* if Drivers="" don't load sound */ > + > while (p1) { > p2 = strchr(p1, ';'); > if (p2) *p2++ = '\0';

2 2

Re: Simple bugzilla question
by Ivan Leo Puoti 26 Aug '04

26 Aug '04

> Do I put the bug in fixed state and submit the patch or leave that > change to the raised? I suppose you can submit the patch, and change the bug status to fixed once the patch is committed. Ivan.

1 0