June 2003 - Wine-Bugs - list.winehq.org

[Bug 893] make install error's in debugger directory
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=893 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 08:11 ------- Bug comments restored from Gmane.org: During make install for the whole package, make enters into the directory and throws an error because there is no "install" directive within the Makefile. Fix: echo "install:" >> debugger/Makefile ------- Additional Comments From marcus <at> jet.franken.de 2002-07-20 02:45 ------- the debugger makefile clearly has an install target here, so something else is broken on your side. try make clean ; ./configure ; make ; make install Ciao, Marcus ------- Additional Comments From tony_lambregts <at> telusplanet.net 2003-03-26 15:21 ------- Closing -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 892] Implement GetSystemInfo using CPUID
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=892 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 08:10 ------- Bug comments restored from Gmane.org: Currently GetSystemInfo reads the CPU information from /proc/cpuinfo. The problem is that this only works on Linux and other x86-based platform only get the defaults which are certainly not optimal for current CPUs. One potential issue is that pre-586 (or is it pre-486) processors don't support the CPUID instruction. But this it not a big issue and can probably be handled in some way. I have set this bug's platform to FreeBSD but this is just as valid for Solaris x86. ------- Additional Comments From marcus <at> jet.franken.de 2002-07-19 03:47 ------- If you want to use CPUID, use an exception handler around the instruction which will trigger if it is not there. Otherwise I do not see a problem to implement it for !Linux x86 systems. -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 891] winemaker and winebuild compatibility problem in the .spec file
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=891 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 08:09 ------- Bug comments restored from Gmane.org: tried to compile 'hello world' using winelib. empty dir w/ hello.c. winemaker. ok. configure. ok. make : winebuild complained about unknown tokens in the spec file. it turned out that its parser doesn't support (any more?) the 'type' and 'import' keywords. after removing these lines from the .spec file, it compiled fine. updating the winemaker script should solve the problem. (+plus updating the docs) -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 890] Virtual Pages difference - Spotted with VirtualQuery()
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=890 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 08:08 ------- Bug comments from Gmane.org: As usual, AutoCAD seems to be a good test-bench for wine :-) I spotted the problem that seemed coming from VirtualQuety function, but that is (I guess... hmmmm) more a problem of memory handling in wine. I made a little test app; here the results in wine and win2k, later on the app itself : WINE RESULTS : Memory info about '004012F0' : Base Address : 00401000 Allocation Base : 00400000 Allocation Protect : PAGE_READONLY | PAGE_WRITECOPY | PAGE_EXECUTE_READWRITE | PAGE_NOACCESS Region Size : 00017000 State : MEM_COMMIT Protect : PAGE_WRITECOPY <----- HERE Type : MEM_PRIVATE WIN2k RESULTS : Memory info about '004012F0' : Base Address : 00401000 Allocation Base : 00400000 Allocation Protect : PAGE_EXECUTE_WRITECOPY Region Size : 00001000 State : MEM_COMMIT Protect : PAGE_EXECUTE_READ <---- AND HERE Type : MEM_IMAGE Well, dunno too much about Type field, I didn't find an app that check it yet; I did find the app that uses Protect flag; I think it's poor coded, but as usual we should make bad apps work too :-) The app put some data in code page, not yet spotted if hard or soft-coded, then before reading it checks Protect field to see if it has not set the PAGE_GUARD, NO_ACCESS and WRITECOPY flags; if t has, it hangs some 10.000 lines later (sigh....) I think wine should set Protect flag quite as like as possible as windoze For AutoCAD2000 I put a dirty hack in process.c, but is really ugly; i'd prefer not to put my hands (bytes ?) too deeply inside some code that I don't understand completely... Attached is the test source (compiled in Borland CBuilder, but should work with any compiler, apart some unuseful pragma's). If needed I can post the compiled too :-) ------- Additional Comments From maxx2 <at> veneto.com 2002-07-18 03:09 ------- Created an attachment (id=232) --> (http://bugs.winehq.com/attachment.cgi?id=232&action=view) C++ Test app for bug 890 ------- Additional Comments From maxx2 <at> veneto.com 2002-07-19 14:42 ------- Just submitted a Patch on wine-patches that seems to solve the problem. -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 889] WINPOS_GetWinOffset() yields wrong offset
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=889 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 08:06 ------- Bug comments restored from Gmane.org: Using the game Dynomite from PopCap Games works very well except that the offset for the graphics is the same as the offset of the window (on the desktop) in which the graphics are being displayed; I essentially eliminated the code in WINPOS_GetWinOffset() by adding a return immediately following the code that sets of the X and Y component of the offset to 0 -- this solves the problem but I suspect that it will cause problems elsewhere; the file of interest is windows/winpos.c; feel free to contact me for any additional information ------- Additional Comments From tuiningas_ml <at> shaw.ca 2002-07-21 00:26 ------- I followed the trail a little bit further as I noticed that "hot spots" on an image (like buttons) would fade in and out when the window wasn't at the top left of the screen. The trail led to the file dlls/x11drv/winpos.c. It is making a call to MapWindowPoints() which in turn calls WINPOS_GetWinOffset(). If I eliminate the call to MapWindowPoints() in the function expose_window() at line 290, (and restore the original version of windows/winpos.c) everything works beautifully. The window draws itself properly and the buttons work as expected. I am not all that familiar with Wine code, though, so can anyone think of a good reason why this code ought to be there? Should I submit a patch? And if so, can anyone point me to the method required for doing so? Thanks. ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-21 09:59 ------- I am not that familiar with wine internals either, but if you submit a patch to wine_patches <at> winehq.com, I'm sure that if there is something wrong with it someone will point it out. The following links are from the Wine Developers Guide on how to submit patches http://www.winehq.com/Docs/wine-devel/patches.shtml http://www.winehq.com/Docs/wine-devel/patch-quality.shtml ------- Additional Comments From tuiningas_ml <at> shaw.ca 2002-07-23 21:42 ------- Created an attachment (id=239) --> (http://bugs.winehq.com/attachment.cgi?id=239&action=view) Proposed patch for this ug ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-24 10:26 ------- I applied your patch to my system and tested it with several programs and the results are not very good. the startup screen of winzip is totally corrupted by this patch. ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-24 10:30 ------- Created an attachment (id=240) --> (http://bugs.winehq.com/attachment.cgi?id=240&action=view) Screen shot showing corruption of Winzip startup screen. ------- Additional Comments From tuiningas_ml <at> shaw.ca 2002-07-24 22:42 ------- The proposed patch that I made was wrong but it seems that someone else made the right patch elsewhere so it is now fixed. I guess the moral of the story is: if you wait long enough, someone else will do it for you.... :-) ------- Additional Comments From tony_lambregts <at> telusplanet.net 2003-03-26 15:20 ------- Closing -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 888] DXGrab can't be undone.
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=888 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 08:04 ------- Bug comments restored from Gmane.org: It would be nice to be able to have a key-combo (one that you wouldn't likely use in Windows -- eg CTRL-ALT-SHIFT-R or something silly.) that would RELEASE a mouse that is DXGrabbed, so that a user may go back to his desktop, deal with other programs, and then lock it back... normally, you would just turn DX grab off, but that makes games nearly impossible to play. Being able to release, do whatever else you wanna do, and the click back in the window to re-lock would be sweet. -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 885] Screen Corruption in riven
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=885 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 08:03 ------- Bug comments restored from Gmane.org: When playing Riven I can move ahead and the screens are fine, but when I want to rotate the view the screen gets corrupted. I think I have tracked the problem down to StretchBlt and BitBlt in X11, but I have run into problems debugging it. It turns out that winedbg uses BITBLT_InternalStretchBlt extensivly so I cannot use winedbg to track down. ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-16 23:19 ------- Created an attachment (id=228) --> (http://bugs.winehq.com/attachment.cgi?id=228&action=view) Screen shot before rotate. ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-16 23:21 ------- Created an attachment (id=229) --> (http://bugs.winehq.com/attachment.cgi?id=229&action=view) Screen shot after rotate ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-16 23:22 ------- Created an attachment (id=230) --> (http://bugs.winehq.com/attachment.cgi?id=230&action=view) Screenshot of what it should look liek after rotate. ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-16 23:26 ------- Created an attachment (id=231) --> (http://bugs.winehq.com/attachment.cgi?id=231&action=view) Short log file that goes with screen shots ------- Additional Comments From dclark <at> akamail.com 2002-07-17 11:32 ------- Yep, I agree. I noticed that by setting transitions to "best", it becomes really obvious what is happening. It is supposed to scroll the window left or right, and then paints in the new portion of the display. It does it with calls like this: trace:scroll:X11DRV_ScrollDC 08dc -181,0 hrgnUpdate=0000 rcUpdate = (nil) which as you suggest causes a BitBlt: trace:bitblt:BitBlt hdcSrc=08dc 181,0 24 bpp->hdcDest=08dc 0,0 427x392x24 rop=cc0020 For some reason, that does not seem to be working. Only the new part is being painted in. The scroll never happens. I never got much beyond that point. ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-18 12:25 ------- :BitBlt hdcSrc=08dc 181,0 24 bpp->hdcDest=08dc 0,0 427x392x24 rop=cc0020 OK. This looks (to me) like the source and destination are the same. hdcSrc and hdcDest both = 08dc. Based on my experience with SimCity's screen corruption I am inclined to be suspicious of this. The other thing about it is that it is 24bpp and as Lionel says its evil <g> source x = 181 source y = 0 destination x = 0 destination y = 0 width = 427 hieght = 392 So my assumption is that you clicked on the right side of the screen and the left hand side of the screen is not getting updated, right? ------- Additional Comments From dclark <at> akamail.com 2002-07-18 17:48 ------- Yep, that was a click on the right. And of course there is a series of quick scrolls of various sizes, corresponding to the various sized pieces left on the right side causing the screen corruption. trace:scroll:X11DRV_ScrollDC 08dc -181,0 hrgnUpdate=0000 rcUpdate = (nil) trace:scroll:X11DRV_ScrollDC 08dc -81,0 hrgnUpdate=0000 rcUpdate = (nil) trace:scroll:X11DRV_ScrollDC 08dc -81,0 hrgnUpdate=0000 rcUpdate = (nil) trace:scroll:X11DRV_ScrollDC 08dc -82,0 hrgnUpdate=0000 rcUpdate = (nil) trace:scroll:X11DRV_ScrollDC 08dc -60,0 hrgnUpdate=0000 rcUpdate = (nil) I think 24 bits is only because that is what my video card is set for, so that is what wine is using. Riven itself is only 8 bit color, as I recall. ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-18 19:47 ------- Well I've tracked it down to this code snippet case SRCCOPY: /* 0xcc */ if (dcSrc->bitsPerPixel == dcDst->bitsPerPixel) { wine_tsx11_lock(); XSetFunction( gdi_display, physDevDst->gc, GXcopy ); XCopyArea( gdi_display, physDevSrc->drawable, physDevDst->drawable, physDevDst->gc, physDevSrc->org.x + visRectSrc.left, physDevSrc->org.y + visRectSrc.top, width, height, physDevDst->org.x + visRectDst.left, physDevDst->org.y + visRectDst.top ); physDevDst->exposures++; wine_tsx11_unlock(); return TRUE; } In each case it goes into this code. (XCopyArea is not a wine function) can you confirm? ------- Additional Comments From dclark <at> akamail.com 2002-07-18 22:56 ------- Yep, it looks like that for me. I added a trace to check the parameters to XCopyArea, and they look ok. case SRCCOPY: /* 0xcc */ if (dcSrc->bitsPerPixel == dcDst->bitsPerPixel) { TRACE(" src_xy=%d,%d size=%d,%d dst_xy=%d,%d\n", physDevSrc->org.x + visRectSrc.left, physDevSrc->org.y + visRectSrc.top, width, height, physDevDst->org.x + visRectDst.left, physDevDst->org.y + visRectDst.top ); I think what is happening is that the first bitblt is doing the scroll on an internal image. trace:bitblt:BitBlt hdcSrc=08dc 38,0 24 bpp->hdcDest=08dc 0,0 570x392x24 rop=cc0020 ... trace:bitblt:BITBLT_InternalStretchBlt src_xy=38,0 size=570,392 dst_xy=0,0 And then the second copies the entire image to the screen trace:bitblt:StretchBlt 08dc 0,0 608x392x24 -> 0894 0,0 608x392x24 rop=cc0020 ... trace:bitmap:X11DRV_DIB_SetImageBits XPutImage(44041069,0x8079818,0x80b3ec0,0,0,0,0,608,436) ... trace:bitblt:BITBLT_InternalStretchBlt src_xy=0,0 size=608,392 dst_xy=16,22 The dst_xy on this second one is offset to accomodate the frame (I think). ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-18 23:30 ------- It's a timing problem, it seems that when the source and destination are the same the screen is not updated properly before the next bitblt. I found this out by putting a FIXME in a for loop. I wanted to slow this down so I could see the problem as it progressed. What it did is clear the problem up. .... physDevDst->exposures++; wine_tsx11_unlock(); if (physDevDst == physDevSrc){ INT q; for(q=1;q<1000 q++){ FIXME("Same Source; } } return TRUE; .... ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-19 02:50 ------- Created an attachment (id=235) --> (http://bugs.winehq.com/attachment.cgi?id=235&action=view) Horribly hacked solution that masks the problem (patch) ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-19 21:13 ------- Duane, have you tried Riven with either of my hacks and if so what do you think the problem is? Do you have any idea how to really fix this or should we leave it to one of the real wine guru's? ------- Additional Comments From dclark <at> akamail.com 2002-07-20 11:38 ------- I tried both. They partially fix it for me, but not completely. I still get a single piece of the old view, though it is a much smaller piece than before. It always happens if I first move forward and then turn sideways. And of course the other noticable thing is that the window does not slide (scroll) but instead just jumps from one view to the other. I notice that if I obscure part of the window with another window and then uncover it, that it is repainted with the corruption still there. By the way, I can always get the window to repaint correctly by sliding my mouse down into the area at the bottom where the books are kept. This might require the window focus to be set to focus follows mouse. I don't really have much of a feel for where the problem is. It appears to me that the bitblt commands have the correct parameters, so like you I think this is some sort of timing problem. I have the Xlib reference book that explains the XCopyArea command, but it does not mention any gotchas if the two Drawables are the same. At the point I don't think I now enough to know how to attack it. ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-24 18:42 ------- I've had several days to think about this one and I have come up with the following conclusions 1. The problem is not with the source and destination drawables being the same. This is pretty rock stable stuff that has been tested in X11 for years. Also while Debuging Bug 792 I noticed that when scrolling in the file dialog that the source and destination were the same with no screen corruption. (I had put a fixme in the code to detect this.) So it isn't this. 2. Timing is a factor because slowing down the execution of same drawables clears up the problem somewhat. 3. If I move forward and then turn. at the begining of the trace there is this fixme. > fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIB copy This does not occure if I am turning around in circles. What brought my attention to this is that another program that has screen corruption (Bug 911) displays this fixme a lot. All that means is that I understand the problem a little better and have a hint of where to look next I suppose. My burning question at this point is what does the somewhat cryptic fixme really mean? ------- Additional Comments From dclark <at> akamail.com 2002-07-25 13:00 ------- I think that slowing down redrawing is actually masking the problem, rather than fixing it somewhat. I noticed that what Riven appears to do is measure how long it takes to perform a scroll, and if it is too long, Riven does fewer scrolls with larger chunks. I think this is what it is doing what it initially does several zero length scrolls. And specifically, what makes it appear to work is that if scrolling takes really long, it does the scroll in a single step. Since the painting of the fill image has always worked, if the fill image is the entire thing, it appears to work. So in short, I am less confident now that it really is a timing issue. ------- Additional Comments From dclark <at> akamail.com 2003-01-09 14:18 ------- Fixed by: http://www.winehq.com/hypermail/wine-cvs/2003/01/0159.html ------- Additional Comments From tony_lambregts <at> telusplanet.net 2003-01-09 19:16 ------- Closing... Thanks Duane. -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 881] Mouse cursor not blanked in opengl game
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=881 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 07:56 ------- Bug comments restored from Gmane.org: This just started in 20020710, it works properly in 20020605. When running Icewind Dale (an opengl game), the default X mouse cursor does not disappear, and is rendered on top of the in-game mouse cursor. The previous release of wine worked properly, so I assume it was broken in one of the cursor changes I see in the changelog for this release. -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 1345] Visual FoxPro 6 won't create executable when compiling project
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=1345 jkreps(a)rev.state.ne.us changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED OS/Version|NetBSD |FreeBSD Resolution| |FIXED ------- Additional Comments From jkreps(a)rev.state.ne.us 2003-20-06 07:32 ------- Upgraded from MDK 8.2 to MDK 9.1 "fresh install" and reinstalled latest stable WINE. VFP 6 now compiles fine. -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

[Bug 878] Icons arent transparent if Managed='Y'
by Wine Bugs June 20, 2003

June 20, 2003

http://bugs.winehq.com/show_bug.cgi?id=878 ------- Additional Comments From z_god(a)wanadoo.nl 2003-20-06 07:30 ------- Bug comments restored from Gmane.org: In Managed='N', icons are correctly transparent, but in Managed='Y' mode their transparent parts come up as black. This can be seen by using the test program against bug #856 and a windows oleaut32.dll. I know its picky but it annoys me! ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-14 14:38 ------- Using the test program in bug 856 the background for the icon is black even if I have "managed" = "N". RedHat 7.2 latest CVS "oleaut32" = "native, builtin". Is there anything else that I should have checked or set? ------- Additional Comments From us <at> the-edmeades.demon.co.uk 2002-07-14 14:52 ------- Er - You do have an oleaut32.dll locally? Aside from that, I dont think so - I can swap Managed in my ini file and change behaviour! I am running cvs on no- windows except in my system dir: ASYNCFILT.DLL, COMCAT.DLL MSVBVM60.DLL OLEPRO32.DLL STDOLE2.TLB VB6STKIT.DLL ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-14 18:29 ------- Well I run wine with a windows 98 c:directory and oleaut32 is located in the windows/system directory. I usually run with "*" = "builtin, native, so" though. ------- Additional Comments From us <at> the-edmeades.demon.co.uk 2002-07-18 13:38 ------- Hmmm - Sounds like I am one step ahead of you!! No idea really - The background of the icon should be the same colour as the active window title bar (in my case blue). The only reason I tried playing with managed is that the X11drv part of icons has special code in one of the cases. I am running Mandrake 8.2 if it helps, cant remember what window manager though (I dual boot, am in windows right now...) ------- Additional Comments From tony_lambregts <at> telusplanet.net 2002-07-18 14:28 ------- I must check if the background of my window manager is black. (SawFish) -- Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0