September 2009 - Wine-bugs - list.winehq.org

[Bug 19942] New: wine does not detect pa thus no sound
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=19942 Summary: wine does not detect pa thus no sound Product: Wine Version: unspecified Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: epistemepromeneur(a)free.fr Mandriva 2008.1 pa is activated since wine 1.1.28 and now with 1.1.29 there is no more sound wine does not detect pa and offers to remove pa from registry if you select any other driver audio test failed to have sound you must use padsp winecfg to select OSS then padsp wine <app> to have sound with <app> -- 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.

1 7

[Bug 3154] Matchad 5 remains in memory on exit
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=3154 --- Comment #18 from Paul Romanyszyn <pgr(a)arcelectronicsinc.com> 2009-09-05 10:31:52 --- I took a look at using overrides. Set mcad.exe to XP then using olesvr32 from XP home into windows/system32. With that it will close a document with two Ole stubs OLeregisterClientDoc and OleRevokeClientDoc and exit. Overriding only olecli32 does not help. Overriding both removes all the Ole fixme's. -- 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.

1 0

[Bug 3817] InstallShield very slow when copying many small files
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=3817 Joseph Miller <josephcmiller2(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josephcmiller2(a)gmail.com --- Comment #29 from Joseph Miller <josephcmiller2(a)gmail.com> 2009-09-05 09:10:55 --- > imho the best solution for this (except the locking-thing) would be to rely on > a cached intermediate state. when looking up files in a certain directory, we > read the entire directory into a cache-structure (including ordering Foo.bar > and foo.Bar) and start monitoring this directory using inotify. > one big advantage about inotify is the clarity of messages: when a new file is > added to the directory in question, we get to know the file's name in advance > and don't need to re-read the entire directory. consider a directory with 1.000 > files, adding 100 files would require reading the directory once, reading from > the cache 100 times and adding to the cache 100 times. > if inotify is not present, we can always fall back to the slower version > already implemented. This sounds like the best solution to me as well. The only problem with it is that it is unlikely one would want wine to monitor every single directory that any program accesses. Windows programs are notorious for opening many files in many directories. Perhaps the cache could be designed as a needs-based cache. The cache could keep a list of each directory accessed, the last time it was accessed, and a count for how many times the directory has been accessed in the last 2-3 seconds. Once the count rises above a threshold for a directory, caching of the directory would begin. Once a directory hasn't been accessed for a period of time, it could be removed from monitoring and caching. This would provide for smart memory management and significant performance increases as well. More comments are needed on this so a request can be submitted for the best way to do this. Wine's got a good history of rejecting patches and I'm not going to be very excited about starting work only to have to redo everything once I finish. We also need a test program to demo this. I will try to make a simple EXE to demonstrate this do a simple benchmark so progress can be shown. -- 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.

1 0

[Bug 19941] New: KDE on Windows Installer: Text is not visible
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=19941 Summary: KDE on Windows Installer: Text is not visible Product: Wine Version: 1.1.29 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: fonts AssignedTo: wine-bugs(a)winehq.org ReportedBy: koesterreich(a)gmx.net Created an attachment (id=23446) --> (http://bugs.winehq.org/attachment.cgi?id=23446) Screenshot I just wanted to run the KDE on Windows Installer [1] with Wine to see which package-versions are currently provided there. Unfortunately I cannot see the Installer's text, see appended screenshot. Testet with KDE on Windows Installer 0.9.6-4 [2], Wine version is 1.1.29. [1] http://windows.kde.org/ [2] http://www.winkde.org/pub/kde/ports/win32/installer/kdewin-installer-gui-0.… -- 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.

1 3

[Bug 19541] New: kde installer: all text blank
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=19541 Summary: kde installer: all text blank Product: Wine Version: 1.1.26 Platform: PC URL: https://bugs.kde.org/show_bug.cgi?id=202170 OS/Version: Linux Status: NEW Keywords: download, source Severity: minor Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com KDE's new installer (0.9.60) has all text blank under wine. Under the old version (0.9.50) displays fine. Url points to KDE bug report. Url for download is: http://www.winkde.org/pub/kde/ports/win32/installer/kdewin-installer-gui-0.… -- 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.

1 7

[Bug 3154] Matchad 5 remains in memory on exit
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=3154 Ken Sharp <kennybobs(a)o2.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #3603|0 |1 is obsolete| | --- Comment #17 from Ken Sharp <kennybobs(a)o2.co.uk> 2009-09-05 02:59:37 --- Created an attachment (id=23441) --> (http://bugs.winehq.org/attachment.cgi?id=23441) Wine 1.1.29 +relay,+seh,+tid (13.9MiB) May as well attach the +relay. ..... 0009:Call olesvr32.OleRevokeServerDoc(00000002) ret=004289e0 0009:fixme:ole:OleRevokeServerDoc (2): stub 0009:Ret olesvr32.OleRevokeServerDoc() retval=00000000 ret=004289e0 0009:Ret window proc 0x429ac0 (hwnd=0x1004e,msg=WM_CLOSE,wp=00000000,lp=00000000) retval=00000000 ...... This is when it hits the loop. -- 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.

1 0

[Bug 3154] Matchad 5 remains in memory on exit
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=3154 Ken Sharp <kennybobs(a)o2.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|mathcad 5.0 when closing |Matchad 5 remains in memory |file or application fixme: |on exit |ole:OleRevokeClientDoc (1): | |stub repeated forever. | --- Comment #16 from Ken Sharp <kennybobs(a)o2.co.uk> 2009-09-05 02:53:44 --- I have been messing around with this for a few hours now and unfortunately got nowhere. Note, that the error seems to have changed over time. Originally starting with a OleRevokeClientDoc (1) problem, then moving onto a OleRevokeServerDoc (3) and now onto a OleRevokeServerDoc (2). Unless I'm mistaken, these are status codes (1 = OLE_WAIT_FOR_RELEASE, 2 = OLE_BUSY, 3 = OLE_ERROR_PROTECT_ONLY). I could be wrong, but this does seem to fit the results. The traces over time also become slightly more descriptive, which seems to show Wine handling the app (OLE) better. According to http://support.microsoft.com/kb/83454 OleRevokeServerDoc should be issuing a OLE_CLOSED notification to the client, but OLE_CLOSED doesn't seem to be defined. I've tried adding a simple definition in the hope the app would handle it, but it didn't help (the link does mention that it might not). The stub currently issues an OLE_OK, but I don't think the app cares too much for that. +ole trace doesn't give any clue. +relay shows the same lines repeated forever until killed: 0009:Call user32.SendMessageA(0001004e,00000010,00000000,00000000) ret=00404765 0009:Call window proc 0x429ac0 (hwnd=0x1004e,msg=WM_CLOSE,wp=00000000,lp=00000000) 0009:Ret window proc 0x429ac0 (hwnd=0x1004e,msg=WM_CLOSE,wp=00000000,lp=00000000) retval=00000000 0009:Ret user32.SendMessageA() retval=00000000 ret=00404765 0009:Call user32.GetWindow(00010034,00000005) ret=00404735 0009:Ret user32.GetWindow() retval=0001004e ret=00404735 0009:Call user32.GetWindow(0001004e,00000004) ret=00404743 0009:Ret user32.GetWindow() retval=00000000 ret=00404743 Sorry for not being more help, I was hoping to have learned something, but failed. The best I managed to achieve messing with the code was a few page faults - at least it was different! The repeated user32 messages, however, make me wonder if I have been barking up the wrong ole tree? -- 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.

1 0

[Bug 735] The WM_INPUTLANGCHANGE message is not send when switching layouts
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=735 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P2 Status|ASSIGNED |NEW --- Comment #21 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-05 01:51:52 --- Not assigned. Importance is not high. -- 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.

1 0

[Bug 735] The WM_INPUTLANGCHANGE message is not send when switching layouts
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=735 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|winex11.drv |user32 Platform|All |Other OS/Version|All |other --- Comment #20 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2009-09-05 01:50:02 --- This is a user32 problem. -- 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.

1 0

[Bug 735] The WM_INPUTLANGCHANGE message is not send when switching layouts
by wine-bugs＠winehq.org 05 Sep '09

05 Sep '09

http://bugs.winehq.org/show_bug.cgi?id=735 --- Comment #19 from Shachar Shemesh <shachar(a)shemesh.biz> 2009-09-05 01:00:54 --- (In reply to comment #18) > > May fix this? Hi Austin, First, a somewhat administrative note. With my current Wine involvement being somewhat low, comments like #17 are bound to be ignored. comments like #18, on the other hand, justify downloading, compiling and running the test code again, as they show something relevant has actually changed. More to the point, however, I'm afraid the commits you point out have done little to alleviate the bug. The two commits seem to provide an infrastructure with which the relevant messages could be distributed to applications, but the do nothing to actually detect the keyboard change event. Without that, this is just dead code that will never be actually called. Downloaded, compiled and ran the test program. Works on Windows XP. Doesn't work on Wine freshly compiled out of git. Bug is still open, sorry. Shachar -- 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.

1 0