July 2008 - Wine-Bugs - list.winehq.org

[Bug 14296] winhelp: Extraneous flashing cursor/caret

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14296 --- Comment #1 from markk(a)clara.co.uk 2008-07-04 18:51:15 --- A problem related to this is that (parts of) some buttons are "unclickable". For example, load WINHELP.HLP from Windows XP into Wine winhelp. If you click on the right half of the Expand button, instead of the action occurring, a flashing cursor appears to the right of the button. In order for the Expand/Collapse feature to work, you must click the left half of the button. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 9787] Warcraft3 Battle.net Doesn't work (Needs AcceptEx)

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=9787 Scott Lindeneau <slindeneau(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |slindeneau(a)gmail.com Raul <rcioldin(a)yahoo.com.br> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rcioldin(a)yahoo.com.br Jon <blind.88(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blind.88(a)gmail.com --- Comment #206 from Scott Lindeneau <slindeneau(a)gmail.com> 2008-06-21 09:07:50 --- I have been reviewing the patch that Andrey Turkin submitted 2008-01-08 and would like to throw my 2 cents in. I haven't programmed in wine before, but I wouldn't mind starting. Please tell me how/if/why I am wrong. 1) AcceptEx can return synchronously, but it doesn't matter if it does or not. * This means that for simplicity it shouldn't. 2) The AcceptEx call has all of the information it needs when its called. * All of the variables passed to AcceptEx must be initialized before it is called. * The AcceptEx function itself should only be a wrapper for a wine server call to start an async accept, and then it should return. 3) Essentially AcceptEx is an easy way to ask the Operating System to start a thread to listen on a socket, and to get rid of the thread automatically. * We ask the wine server for an async accept (which should just be spawn a thread, listen, and return after connect) 4) AcceptEx only adds the ability to read data on the socket before the socket's error status changes from IO_PENDING to whatever. * Why not add this functionality into the wine server's async accept? --- Comment #207 from Raul <rcioldin(a)yahoo.com.br> 2008-06-24 13:32:33 --- acceptex unnofficial patch in deb package please! --- Comment #208 from Austin English <austinenglish(a)gmail.com> 2008-06-24 16:11:23 --- (In reply to comment #207) > acceptex unnofficial patch in deb package please! > Ask the maintainer to do that. Hacks are not accepted in WineHQ's codebase. You could compile it yourself... --- Comment #209 from Raul <rcioldin(a)yahoo.com.br> 2008-06-24 17:55:56 --- after a long time downloading and compiling.... the "Disable completion port creation" patch didn't work... I just have to get in my git dir and do "patch -Np1 < mypatch.diff && tools/make_requests"??? --- Comment #210 from Scott Lindeneau <slindeneau(a)gmail.com> 2008-06-29 02:53:29 --- (In reply to comment #209) > after a long time downloading and compiling.... > > the "Disable completion port creation" patch didn't work... > > I just have to get in my git dir and do > "patch -Np1 < mypatch.diff && tools/make_requests"??? > then you have to >make depend >make >sudo make uninstall >sudo make install and type your password if prompted for the sudo. --- Comment #211 from Jon <blind.88(a)gmail.com> 2008-06-29 02:57:29 --- (In reply to comment #0) > Today's patches have caused Warcraft 3 battle.net to stop working. When > connecting to Battle.net the "Connecting to Battle.net" box just idles > indefinitely. No terminal output. > > I haven't run a regression yet so I don't know exactly which patch causes this. > I had this issue with wine 1.0 and the RC's. My work around was to click battle.net then cancel (as it would get stuck) then click battle.net again, it will work instantly the 2nd time. --- Comment #212 from Peter <petoju(a)gmail.com> 2008-06-29 04:21:49 --- (In reply to comment #211) > (In reply to comment #0) > > Today's patches have caused Warcraft 3 battle.net to stop working. When > > connecting to Battle.net the "Connecting to Battle.net" box just idles > > indefinitely. No terminal output. > > > > I haven't run a regression yet so I don't know exactly which patch causes this. > > > > I had this issue with wine 1.0 and the RC's. My work around was to click > battle.net then cancel (as it would get stuck) then click battle.net again, it > will work instantly the 2nd time. I have the same problem, clicking cancel helps, but this regression is in Wine probably since 0.9.50 (I don't know exact Wine version). (In reply to comment #210) > (In reply to comment #209) > > after a long time downloading and compiling.... > > > > the "Disable completion port creation" patch didn't work... > > > > I just have to get in my git dir and do > > "patch -Np1 < mypatch.diff && tools/make_requests"??? > > > > then you have to > >make depend > >make > >sudo make uninstall > >sudo make install > and type your password if prompted for the sudo. I'd try "sudo checkinstall" instead of sudo make install and sudo make uninstall, because checkinstall creates package, that does NOT harm you package system as "make" do. --- Comment #213 from Andrey Turkin <andrey.turkin(a)gmail.com> 2008-06-29 06:19:29 --- (In reply to comment #206) > I have been reviewing the patch that Andrey Turkin submitted 2008-01-08 and > would like to throw my 2 cents in. I haven't programmed in wine before, but I > wouldn't mind starting. Please tell me how/if/why I am wrong. > > 1) AcceptEx can return synchronously, but it doesn't matter if it does or not. > * This means that for simplicity it shouldn't. I tried to cause AcceptEx to perform synchronously, but it always was failing with IO_PENDING even when connection was available (on XP SP2). So AcceptEx should not return synchronously for consistency with Windows. > 2) The AcceptEx call has all of the information it needs when its called. > * All of the variables passed to AcceptEx must be initialized before it is > called. > * The AcceptEx function itself should only be a wrapper for a wine server > call to start an async accept, and then it should return. AcceptEx should be wrapper for ws2_32-provided function (pointer can be obtained via WSAIoctl with WSAID_ACCEPTEX guid), which probably should be a wrapper for wineserver call. > > 3) Essentially AcceptEx is an easy way to ask the Operating System to start a > thread to listen on a socket, and to get rid of the thread automatically. > * We ask the wine server for an async accept (which should just be spawn a > thread, listen, and return after connect) Windows don't do this (NT kernel is fully asynchronous already); Wine don't have to do this (asynchronous accept is available with POSIX sockets). I tried to use these facilities, and here is main problem I faced with: wineserver socket implementation is complicated and is tightly integrated with asynchronous i/o part; latest patch posted here is faulty, and even with latest changes I observed missed connections (Apache2 for Windows is quite good for testing reliability). Maybe distinct listener thread would be easier to implement AcceptEx properly, I don't know. > > 4) AcceptEx only adds the ability to read data on the socket before the > socket's error status changes from IO_PENDING to whatever. > * Why not add this functionality into the wine server's async accept? AcceptEx also gives you ability to "assign" socket to be used for new connection, and more importantly AFAIK there is no async accept support in wineserver at the moment. --- Comment #214 from Martin Dengler <martin(a)martindengler.com> 2008-07-04 18:10:53 --- I used to be able to play, but not host battle.net games with wine 1.0 without any patches, and regressing to a wine pre-this-bug's-cause's-change would work fine. After the 1.22 patch, I was able to play two or three games (one quite long - 40 mins or so) and then the problems started: I would get disconnected after about 5 minutes (once as long as 11 minutes) into the game. I have had this happen about 5 times in a row now. So things are pretty unusable. As for normal logs, I see: fixme:mswsock:AcceptEx (listen=16796, accept=16800, 0x50200c0, 0, 32, 32, 0x33f948, 0x5020090), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16804, 0x5020148, 0, 32, 32, 0x33f948, 0x5020118), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16808, 0x50201d0, 0, 32, 32, 0x33f948, 0x50201a0), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16812, 0x5020258, 0, 32, 32, 0x33f948, 0x5020228), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16816, 0x50202e0, 0, 32, 32, 0x33f948, 0x50202b0), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16820, 0x5020368, 0, 32, 32, 0x33f948, 0x5020338), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16824, 0x50203f0, 0, 32, 32, 0x33f948, 0x50203c0), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16828, 0x5020478, 0, 32, 32, 0x33f948, 0x5020448), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16832, 0x5020500, 0, 32, 32, 0x33f948, 0x50204d0), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16836, 0x5020588, 0, 32, 32, 0x33f948, 0x5020558), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16840, 0x5020610, 0, 32, 32, 0x33f948, 0x50205e0), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16844, 0x5020698, 0, 32, 32, 0x33f948, 0x5020668), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16848, 0x5020720, 0, 32, 32, 0x33f948, 0x50206f0), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16852, 0x50207a8, 0, 32, 32, 0x33f948, 0x5020778), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16856, 0x5020830, 0, 32, 32, 0x33f948, 0x5020800), not implemented fixme:mswsock:AcceptEx (listen=16796, accept=16860, 0x50208b8, 0, 32, 32, 0x33f948, 0x5020888), not implemented fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmGetOpenStatus (0x135d28): semi-stub fixme:imm:ImmAssociateContextEx (0x40034, (nil), 16): stub I will look through this bug for the desired logging switches and see if I can get anything more useful. Martin System info: $ uname -a Linux cree.xades.com 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux $ rpm -q wine-core wine-core-1.0-1.fc9.i386 $ cat /etc/fedora-release Fedora release 9 (Sulphur) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 14067] Virtual desktop window refreshing

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14067 markk(a)clara.co.uk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|WONTFIX | --- Comment #3 from markk(a)clara.co.uk 2008-07-04 18:10:43 --- Is there a standard way for an application to tell the window manager to refresh/redraw its windows automatically when restored or revealed? (That is, the window manager would keep a copy of the whole window bitmap in memory, and restore its contents from that buffer when restoring it. The application code would not be involved in refreshing at all.) If there *is* a standard way to do that, it would be great if such an option could be added to Wine. If there *isn't* a standard way to request that behaviour... Like any other application, Wine is responsible for redrawing/refreshing its window (the virtual desktop window) when it is restored or revealed. Currently, am I correct in thinking that Wine does that by asking the running Windows programs to redraw/refresh their windows? My suggestion would be to have an option for Wine to remember the window state, so - as far as the running Windows programs are concerned - nothing happens when the user minimises & restores the virtual desktop window. (No refresh messages sent to them etc.) This is important when the Windows program thinks it is the only window on the desktop, and does not repaint itself. A specific example is the installer for the Microsoft game "Age of Mythology". While the installation is running, the installer only updates a progress gauge, leaving the rest of its window untouched. So if you e.g. drag another X application window over the Wine virtual desktop, then minimise it to reveal the virtual desktop, the installer does not repaint its window, leaving "trash" on the screen. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 13838] AutoCAD 2005 setup : Missing backslash in registry entry and profile path

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13838 --- Comment #36 from max(a)veneto.com 2008-07-04 17:58:01 --- (In reply to comment #35) > (In reply to comment #33) > > Well, if you think that's more logical return the same stuff in 2 different > > ways..... > > The two pieces of functionality you are referring to are completely separate. > It's not necessarily logical for them to return different things, but it's not > illogical if they do. They are not comparable. I don't agree. They maybe come from separate functionalities, but you're indeed asking installer to locate a folder path in both cases. And I expect to get it in a consistent way in both cases. I'd agree with you if you where speaking about shell path functions and msi path functions in terms of each other. In shell path, the convention is to return path WITHOUT backslash. In msi, there's big evidence that there's a convention on returning path WITH backslash. You can easily see in code I pasted before; for global properties you READ from REGISTRY a path an ADD a backslash. In local properties, you READ from REGISTRY a path and you simply forgot to add the backslash, point. Autocad installer does make the assumption that msi paths are returned WITH backslash and act on consequence. I could agree that an installer should be a bit more error proof, but windows is full of such cases. Even agreeing on tests many times, I really don't see the point on loosing time to make a one where stuffs can't simply be different. The best test here is just autocad installer, having excluded any alternative, you can easily see looking at msi code. > > > Btw, autocad installer expects it WITH a trailing backslash, so it > > must be like that. As I excluded a registry difference (checked with windows > > one...) and a path function difference (on that one i DID make a test and it's > > right, without the backslash), the only place on which the backslash can appear > > is here. > > I never said the fix was wrong. I said the fix has to be backed up by a test. > > > And, if somebody added backslashes in set_installer_properties() there should > > be a reason..... > > There is a backslash because the tests prove there should be a backslash. > I even don't know if there's a test for it, I haven't looked at that. But I'm pretty sure that there's NO test that proves the opposite for local properties. As I said, that one is one of RARE cases where I think making a testcase is just loosing time, in particular if I've got to learn all MSI mechanics to demonstrate something about I'm 100% sure. Max -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 14302] New: winhelp: Make dropshadows on popup boxes semi-transparent

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14302 Summary: winhelp: Make dropshadows on popup boxes semi- transparent Product: Wine Version: 1.1.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: markk(a)clara.co.uk Currently, Wine winhelp renders drop shadows on popup boxes as solid black. Windows 95 WINHLP32.EXE uses a cross-hatch pattern, so drop shadows appear semi-transparent. I think Wine winhelp should do the same. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 14301] New: winhelp: Selecting a topic does not aways go to the correct page

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14301 Summary: winhelp: Selecting a topic does not aways go to the correct page Product: Wine Version: 1.1.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: markk(a)clara.co.uk The search button is not implemented in Wine winhelp; it reports fixme:winhelp:MACRO_Search () when that button is clicked. The Topics button does bring up a list of topics, but selecting a topic and clicking OK does not always go to the correct page. To demonstrate, download castle1.hlp from http://bugs.winehq.org/attachment.cgi?id=14573 and click the Topics button. Compare which page you are taken to with that when using Windows 95 WINHLP.EXE. Also, in the topic window, it should be possible to select a topic by double-clicking the text (no need to select and click OK button). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 14300] New: winhelp: Wrong initial view position in pages

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14300 Summary: winhelp: Wrong initial view position in pages Product: Wine Version: 1.1.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: markk(a)clara.co.uk With some help files, on clicking a link Wine winhelp shows the new page part-way down, not from the top. To demonstrate, download winehelp_bugs.tar.bz2 from http://bugs.winehq.org/attachment.cgi?id=14574 and load winrisk.hlp into Wine winhelp. Resize the window to be about half its original width and height. Click the Contents button. The view moves about half-way down the page. Click "Revision History". The view is over half-way down the page. In both cases, Windows 95 WINHLP32.EXE remains at the top of the page. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 14299] New: winhelp: Missing << and >> buttons with some help files

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14299 Summary: winhelp: Missing << and >> buttons with some help files Product: Wine Version: 1.1.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: markk(a)clara.co.uk For many help files, the forward and back buttons (<< and >>) are not shown in Wine winhelp. However they do appear with other help files (e.g. pphelp.hlp). For example, download winehelp_bugs.tar.bz2 from http://bugs.winehq.org/attachment.cgi?id=14574 and load castle1.hlp, chess.hlp or emle.hlp into Wine winhelp. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 13838] AutoCAD 2005 setup : Missing backslash in registry entry and profile path

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=13838 --- Comment #35 from James Hawkins <truiken(a)gmail.com> 2008-07-04 17:35:11 --- (In reply to comment #33) > Well, if you think that's more logical return the same stuff in 2 different > ways..... The two pieces of functionality you are referring to are completely separate. It's not necessarily logical for them to return different things, but it's not illogical if they do. They are not comparable. > Btw, autocad installer expects it WITH a trailing backslash, so it > must be like that. As I excluded a registry difference (checked with windows > one...) and a path function difference (on that one i DID make a test and it's > right, without the backslash), the only place on which the backslash can appear > is here. I never said the fix was wrong. I said the fix has to be backed up by a test. > And, if somebody added backslashes in set_installer_properties() there should > be a reason..... There is a backslash because the tests prove there should be a backslash. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008

[Bug 14298] winhelp: Mouse pointer flickers when moved

by wine-bugs＠winehq.org

http://bugs.winehq.org/show_bug.cgi?id=14298 --- Comment #1 from markk(a)clara.co.uk 2008-07-04 17:30:55 --- I'm using Ubuntu 8.04 with the GNOME desktop -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.

July 4, 2008