- Wine-Devel - list.winehq.org

Re: [Bug 3148] Mouse: multi-file "selection" & drag behavior broken
by Hiji Oct. 2, 2005

Oct. 2, 2005

Looks like someone else is having this problem. I've tried looking at listview.c and the treeview equivalent as well, but I can't made heads or tails of it. I have no experience with C. Anybody on this list make any changes to listview or treeview in the last few months? Hiji > ------- Additional Comments From > qingdao33122(a)yahoo.com 2005-04-08 23:58 ------- > About the same problem with AceFTP > > Free download for trial > http://software.visicommedia.com/en/products/aceftpfreeware/ > > wine-20050524-1fc1winehq > > Problem starts before I do the FTP thing. > When I drag a file within the local pane(a > listview), > a copy of that file is immediately created. But > things > don't stop there. The moment I move the mouse a bit, > AceFTP asks me with a popup menu if want to: > Move to current location > Copy to current location or > Create a short > If I choose to copy, ANOTHER copy of the file is > created. > After that, every time I move the mouse, > AceFTP asks me again, thus an infinite loop > and infinite number of copies of the same file. > > BTW. I have to use native shell related dlls for > AceFTP to > display the local pane. So I suspect the problem is > with > the interaction between native and builtin code. > > I hope my English is good enough for me to make some > sense... > > -- > Configure bugmail: > http://bugs.winehq.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 9

re: Autoresolving our 554 old UNCONFIRMED bugs
by Dan Kegel Oct. 2, 2005

Oct. 2, 2005

Vijay wrote: > http://kegel.com/wine/qa/autoresolve.html >> In the same can we close the older bugs >> dated below 2003, with no activity. If they're unconfirmed, my proposal will take care of them. And there are only 24 'new' or 'assigned' bugs which haven't been changed in two years, so we can look at those manually just fine, I think. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Oregon Trail 5 and DirectX 8?
by Dan Kegel Oct. 1, 2005

Oct. 1, 2005

http://appdb.winehq.org/appview.php?versionId=2909 claims that Oregon Trail 5 runs, so I tried running the free Oregon Trail 5 demo, http://www.learningcompany.com/jump.jsp?itemID=147&itemType=PRODUCT&RS=1 But it failed to install, saying DirectX 8 was not installed. Anyone know what's going on? Thanks! -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Kid Pix Deluxe 3 redux
by Dan Kegel Oct. 1, 2005

Oct. 1, 2005

Four years ago, I tested Kid Pix Deluxe 3 on wine: http://www.winehq.org/hypermail/wine-users/2001/08/0287.html http://www.winehq.org/hypermail/wine-devel/2001/08/0096.html Couldn't even install it. Now that Wine's approaching 0.9, I figured it was time to try again. So I found the old disc, dusted it off, and gave it a shot. What a difference four years makes - it installs now! Oh, there were three bugs in the installer: (see http://bugs.winehq.org, bugs 3448, 3449, 3451) but nothing a determined user can't work around. This was particularly impressive, since the Kid Pix installer installs several other packages, including Quicktime. Sadly, the resulting app fails to start. That's bug 3450: KPD3.exe aborts while loading, with message err:module:import_dll Library CONFIGIT.dll ... not found Presumably that library was supposed to be installed by the installer, but wasn't. While Kid Pix Deluxe 3 isn't free software, it's pretty cheap; you can get it for $2 online. But lots of schools probably still use copies of this app, and it makes a nice test, so it seems worth working on. (There's also a version of Kid Pix specialized for schools; that's different somehow, but I bet getting the retail version working will make it a lot more likely the school version will work.) - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Small CVS-Update-Script
by Gladiac Spark Oct. 1, 2005

Oct. 1, 2005

This is nothing special but may be useful for some people out there having problems updating their cvs-trees or being lazy writing some commands in their console. Copy the 'getwinecvs' to /usr/src or wherever you want (don't forget to edit the SRC=Variable if you're doing so) and chmod it to give you x-rights. (e.g.: 'chmod 750 getwinecvs' without quotes) By running it, it will search for an existing wine-tree... if there is one, it will be cleaned and then updated; if not, the complete tree will be downloaded. When using -c as parameter for getwinecvs, it will automatically begin to compile after getting all the updates and then install. To see what it exactly does, have a look at the source. Even if it is called General CVS-Updater by gladiac it has been written FOR wine. I hope it is helpful for others. I know it's not very nerdy but.... who cares ;).

1 0

undocumented APIs
by Ivan Leo Puoti Oct. 1, 2005

Oct. 1, 2005

Hello, I would like to make a general appeal to not write wine code based on the docs at undocumented.ntinternals.net, because they're often misleading, incomplete or simply wrong, and do more harm than good. Please refer to "windows nt/2000 native api reference" by Gray Nebbett, to the reactos team, or to me (I've got the book) instead, and always write tests for undocumented functions. Ivan.

1 0

cannot run a lot of 16 bit apps
by Robbert Xerox Oct. 1, 2005

Oct. 1, 2005

Hi, i'm trying out some apps from the bugzilla database, but in quite some cases i get this error: winevdm: unable to exec 'winbr34.exe': 16-bit support missing I compiled from current cvs without any options, i even tried --enable-win16 but didn't help. Appearently other people _are_ able to run these apps. One example is ftp://ftp.mvpsoft.com/pub/winbr34.exe Anyone could give me a hint how to solve this? I run fc3 (x32) on an athlon64. kernel 2.6.12.3 ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

1 0

Re: Autoresolving our 554 old UNCONFIRMED bugs
by Dan Kegel Oct. 1, 2005

Oct. 1, 2005

Joerg Mayer wrote: >> We will automatically mark your bug as 'resolved' if we don't >> hear from you in the next two weeks. > > Add something like this: > > It doesn't matter if don't find the time to verify the bug right now, > you can always reopen the bug later. Good idea. I've updated the text at http://kegel.com/wine/qa/autoresolve.html Thanks! - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

testsuite patch - please run on windows
by Marcus Meissner Oct. 1, 2005

Oct. 1, 2005

Hi, Can one of the Windows testers please try this testsuite patch? The second test fails on WINE, but I have a Bugzilla where the reporter said it should not. (http://bugs.winehq.org/show_bug.cgi?id=1847) Ciao, Marcus Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.71 diff -u -r1.71 win.c --- dlls/user/tests/win.c 29 Sep 2005 13:36:14 -0000 1.71 +++ dlls/user/tests/win.c 1 Oct 2005 15:18:35 -0000 @@ -2173,6 +2173,8 @@ static void test_capture_3(HWND hwnd1, HWND hwnd2) { + BOOL ret; + ShowWindow(hwnd1, SW_HIDE); ShowWindow(hwnd2, SW_HIDE); @@ -2188,7 +2190,10 @@ ShowWindow(hwnd1, SW_SHOW); check_wnd_state(hwnd1, hwnd1, hwnd1, hwnd2); - ReleaseCapture(); + ret = ReleaseCapture(); + ok (ret, "releasecapture did not return TRUE.\n"); + ret = ReleaseCapture(); + ok (ret, "releasecapture did not return TRUE after second try.\n"); } static void test_keyboard_input(HWND hwnd)

2 1

Bug Triage: Infinite loop in painting.c / winpos.c (2658)
by Molle Bestefich Oct. 1, 2005

Oct. 1, 2005

Hello I'd like to take a stab at helping clear out bugzilla. I've chosen this particular entry: http://bugs.winehq.org/show_bug.cgi?id=2658 A trial version can be downloaded here: http://www.download.com/Trillian/3000-2150-10047473.html The installer runs the setup wizard, which will crash and misbehave. Ignore that, and continue onwards with running "wine trillian.exe". In today's CVS, the application behaves as explained in the Bugzilla. The app goes into an infinite loop somewhere around user/painting.c and user/winpos.c. The visual effect is that: 1. The splash screen pops up in the middle of the screen, 2. It moves a notch (3 by 3 pixels) down and to the right, 3. Step 2.) repeats almost ad infinitum. That is, until the window is at the bottom edge of the screen and halfway to the right edge. 4. The application then waits for a very short while before finally starting over from step 1. Google gives us a few hints, so I'll take you on a short tour: http://bugs.winehq.org/show_bug.cgi?id=2658 "With previous versions, at least the splash window worked [...] but 20050111 makes the splash screen go crazy [...]! It shows up in the middle of the screen, but then goes down until the bottom of the screen." http://article.gmane.org/gmane.comp.emulators.wine.user/3048 "I've been running Trillian Pro quite successfully on wine-20030508 since, well, May 8th." http://article.gmane.org/gmane.comp.emulators.wine.user/6 "CodeWeavers Crossover Plugin works 100% with Trillian, no window move issues." http://www.desktoplinux.com/news/NS4813802007.html "Jan. 23, 2003 [...] CodeWeavers, Inc. today announced the release of CrossOver Plugin Version 1.2, [...] the new release also [... has] improved support for [...] Trillian." http://www.codeweavers.com/site/compatibility/browse/name?app_id=251;forum=1 "Has anyone tested the new version 3.0 already with Crossover?" "Yes. It works somewhat okay - there are bugs that need to be ironed out (i.e. new windows don't pop up well, dragging windows causes artsd to lock up on KDE)." Also slightly interesting: http://www.codeweavers.com/site/compatibility/browse/name?app_id=251;issues… So, it seems it works with CrossOver, but not vanilla Wine. Something fishy seems to be going on in Wine's USER32. I've run with +win, which gives an infinitely repeating list consisting of RedrawWindow, BeginPaint, GetWindowRect, SetWindowPos, MoveWindow, WINPOS_GetMinMaxInfo and others. Here's the infinitely looping part of a +win run: win:RedrawWindow 0x10028 whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW win:BeginPaint hdc = 0xbb4 box = (0,0 - 177,368), fErase = 0 win:GetWindowRect hwnd 0x10028 (741,1244)-(924,1634) win:GetWindowRect hwnd 0x10028 (741,1244)-(924,1634) win:SetWindowPos hwnd 0x10028, after (nil), 549,317 (183x390), flags 80000015 win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE 80000000 [ notice the block below.. ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:MoveWindow 0x10028 552,336 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 552,336 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:WINPOS_GetMinMaxInfo 183 390 / 552 336 / 183 390 / 183 390 [ it's repeated now, below.. ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:MoveWindow 0x10028 555,355 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 555,355 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:WINPOS_GetMinMaxInfo 183 390 / 555 355 / 183 390 / 183 390 [ above block repeats 10 more times, only coordinates changing. ] [ then poof happens the below. Almost a repeat, except for the GetMinMaxInfo params: ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:MoveWindow 0x10028 645,925 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 645,925 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:WINPOS_GetMinMaxInfo 1282 1026 / -1 -1 / 1288 1032 / 112 27 win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (645,925)-(828,1315) win:RedrawWindow 0x10020 region 0x192c box (642,906)-(825,1296) flags: RDW_INVALIDATE RDW_ALLCHILDREN win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE win:RedrawWindow 0x10020 region 0x1934 box (639,887)-(822,1277) flags: RDW_INVALIDATE RDW_ALLCHILDREN win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE [ above repeats 30 times, albeit with new coordinates etc. ] After this, the trace "wraps around" and repeats itself from the beginning. Coordinates change slightly though, it's a few pixels off from the first run. Please help me understand why the above infinite loop occurs! I also did a +relay trace and ran it through examine-relay. The resulting call stack is awe inspiring - it's as deep as the Mariana Trench. See the attached snippet. Does it not seem "wrong"? I also did a +all trace, which instantly got very big and confusing. I tried grepping to get rid of parts of it, which went OK, but then examine-relay wouldn't indent half of the lines in it, and in the end it complained about a bunch of leftover calls. So I patched Wine (attached) to output only toplevel calls, which gave me this listing: Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) retval=00000001 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) [ window moves a lot now ] Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) retval=00000001 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) [ window moves a lot now ] Etc. ad infinitum. The above should be the stuff that Trillian actually calls in Wine, but my patch might be wrong. Seems odd that the WM_blah calls do not show up in +relay mode. Please help me understand: Why is that? Thank You for Paying Attention. And Please Help Me Fix This Bug! :-)

1 0