October 2015 - Wine-bugs - list.winehq.org

[Bug 25105] New: Wine fails to load 3d model (with testcase)
by wine-bugs＠winehq.org 02 Sep '16

02 Sep '16

http://bugs.winehq.org/show_bug.cgi?id=25105 Summary: Wine fails to load 3d model (with testcase) Product: Wine Version: 1.3.6 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: cleberdemattoscasali-wine(a)yahoo.com.br Wine will fail to load a 3d model running this simple program made with DarkBASIC Pro. -- 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 21

[Bug 34056] New: Nabeta Jisho: Can't input Japanese characters with Input Method.
by wine-bugs＠winehq.org 02 Sep '16

02 Sep '16

http://bugs.winehq.org/show_bug.cgi?id=34056 Bug #: 34056 Summary: Nabeta Jisho: Can't input Japanese characters with Input Method. Product: Wine Version: 1.6-rc5 Platform: x86 URL: http://www.nabeta.tk/nabeta550.zip OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: sagawa.aki+winebugs(a)gmail.com CC: slash(a)ac.auone-net.jp Classification: Unclassified Regression SHA1: dc02e4d1a7c35b4205f6109ad71deee5fdddd750 Nabeta Jisho is a dictionary software which built with C++Builder6 CLX Library. In the search box, I can't input any Japanese characters. Reverting commit dc02e4 fixes the issue. In detail, I input some Japanese characters through the input method, then hit the Enter key. Both of candidate characters and result strings are not shown in the edit box. However, I can input ASCII characters and paste some Japanese characters. I'm using mozc 1.3.975.102 and IBus 1.4.1 as input method in Ubuntu 12.04. Of course, I can input Japanese characters in the notepad application. -- 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 19

[Bug 36378] New: wsus won't run wget from dos box
by wine-bugs＠winehq.org 31 Aug '16

31 Aug '16

http://bugs.winehq.org/show_bug.cgi?id=36378 Bug ID: 36378 Summary: wsus won't run wget from dos box Product: Wine Version: 1.6.1 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ToddAndMargo(a)zoho.com Hi All, Scientific Linux 6.5, 64 bit Wine 1.6.1 Xfce 4.8 wsusoffline-9.2 Would you guys fix WSUS (http://www.wsusoffline.net/) so that it works in Wine? Currently, you can configure the GUI, but when it goes to run, the DOS box with wget in it fails to run. No crashing, WSUS just tells you it is finished, almost instantly, without downloading anything. Many thanks, -T -- 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 13

[Bug 34428] New: Cannot switch window while running full-screen program
by wine-bugs＠winehq.org 23 Aug '16

23 Aug '16

http://bugs.winehq.org/show_bug.cgi?id=34428 Bug #: 34428 Summary: Cannot switch window while running full-screen program Product: Wine Version: 1.5.23 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: 710214093(a)qq.com Classification: Unclassified When I'm play games running full screen mode, I cannot switch to any other windows until the full-screen game is closed. Contrary to Bug 33324, the problem is that I cannot switch "out of" the full-screen game, not switch "in to" it. -- 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 4

[Bug 24652] New: Missing sizes for wine app icon
by wine-bugs＠winehq.org 23 Aug '16

23 Aug '16

http://bugs.winehq.org/show_bug.cgi?id=24652 Summary: Missing sizes for wine app icon Product: Wine Version: 1.3.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: michael.monreal+wine(a)gmail.com Created an attachment (id=31162) --> (http://bugs.winehq.org/attachment.cgi?id=31162) Screenshot Wine ships 16x16, 32x32 and 48x48 versions of its icon. These should be installed in some place where panels, pagers, window managers can find them (packager's duty?). However, at the moment two common sizes are missing: 24x24 and some larger version like 64x64, 128x128 or 256x256. In GNOME3's window chooser, 64x64 icons are shown. Currently, wine only shows a smaller icon here, which looks kind of out of place (see attached screenshot). Note that GNOME does not ship 64x64 artwork itself but scales the bigger 256x256 version down to 64x64 in this place. -- 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 22819] New: Some applications like Heroes of Might and Magic 2 display loopback.
by wine-bugs＠winehq.org 22 Aug '16

22 Aug '16

http://bugs.winehq.org/show_bug.cgi?id=22819 Summary: Some applications like Heroes of Might and Magic 2 display loopback. Product: Wine Version: 1.1.44 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: zombie(a)terralab.com Some applications like Heroes of Might and Magic 2 display loopback addresses when attempting to initiate a network game. The network game will complain it is running on 127.12.34.56. I have checked /etc/hosts and determined it is not the cause of the 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 25

[Bug 37063] New: NTLM EncryptMessage/DecryptMessage failure
by wine-bugs＠winehq.org 22 Aug '16

22 Aug '16

http://bugs.winehq.org/show_bug.cgi?id=37063 Bug ID: 37063 Summary: NTLM EncryptMessage/DecryptMessage failure Product: Wine Version: 1.7.22 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: secur32 Assignee: wine-bugs(a)winehq.org Reporter: dwmw2(a)infradead.org Created attachment 49252 --> http://bugs.winehq.org/attachment.cgi?id=49252 Test case Attached is a test case based on GSSAPI authentication to a SOCKS proxy (RFC1961). An alternative summary for this bug could be "OpenConnect VPN server cannot authenticate to SOCKS proxy", since that's where this test code is derived from. The protocol is fairly simple — it's a GSSAPI exxchange followed by a single byte 0x00 being sent in each direction under "wrapping" by gss_wrap() or EncryptMessage(). We are only supposed to be using integrity protection (signing), not encryption. Testing has been done against a Dante SOCKS server using gss-ntlmssp. Windows testing has been done under Windows 7 64-bit, set to use NTLMv1 & LMv1 (I don't seem to have permissions to change that for testing NTLMv2). There are various issues with wine's emulation which make it fail once gss-ntlmssp has been made to work correctly with Windows. I'm not sure if it's best to file separate bugs for each or whether to track them together. Firstly, wine seems to mishandle the Password field in SEC_WINNT_AUTH_IDENTITY unless it's in Unicode mode; using SEC_WINNT_AUTH_IDENTITY_ANSI doesn't work because the password that gets passed to ntlm_auth is mangled. Secondly, it looks like the Domain field is ignored too and we just pass '--domain=' to ntlm_auth. (There's a separate bug filed at https://bugzilla.samba.org/show_bug.cgi?id=10691 for ntlm_auth not giving us the session key back when it's using default credentials, and the *flags* are wrong in that case too because they are missing the NTLMSSP_NEGOTIATE_SIGN/SEAL bits, but that's probably Samba bug). Third... it looks like Windows will always encrypt messages, even when ISC_REQ_CONFIDENTIALITY is *not* in the InitializeSecurityContext flags and SECQOP_WRAP_NO_ENCRYPT is set. But wine doesn't, so the first 'encrypted' message fails in gss_unwrap() on the server side. If we do use ISC_REQ_CONFIDENTIALITY (or bypass the NTLM2&&SEAL check in ntlm_EncryptMessage() and make it always take that path, sending a wrapped message works but then... Fourth, we fail to *unwrap* the returned message. It's looking for a SECBUFFER_TOKEN buffer in the array, but as far as I can tell, NTLM DecryptMessage() takes SECBUFFER_STREAM and a SECBUFFER_DATA. The documentation on this is sparse, but this code does work under Windows... -- 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 16

[Bug 38137] New: WBaduk: "Could not obtain OLE control window handle" regression
by wine-bugs＠winehq.org 22 Aug '16

22 Aug '16

https://bugs.winehq.org/show_bug.cgi?id=38137 Bug ID: 38137 Summary: WBaduk: "Could not obtain OLE control window handle" regression Product: Wine Version: 1.7.34 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lemonsqueeze(a)gmx.com Distribution: Ubuntu Created attachment 50855 --> https://bugs.winehq.org/attachment.cgi?id=50855 wine log Greetings and a big thanks to the wine team, WBaduk is a windows client to play the game of go on wbaduk go servers. It used to work like a charm with wine 1.2 (ubuntu lucid, package version 1.2.2-0ubuntu2~lucid1) except for a harmless "Floating point exception" popup when logging in. It's unuseable however with the latest ubuntu dev build (1.7.34, ubuntu trusty): We can login no problem, but keep getting "Could not obtain OLE control window handle" popups when trying to observe a game. Here's the steps I used to reproduce: - Installed wine 1.7.34 on ubuntu trusty from the wine ppa. - Download wbaduk (21Mb) from www.wbaduk.com using the "download" button on the top left. Currently it points to: http://www.wbaduk.com/download/WBaduk_20140410A.exe - Installed in brand new account (no previous .wine directory) $ wine WBaduk_20140410A.exe - And run: $ wine '.wine/drive_c/Program Files/WBaduk/OrO20.exe' - Login with test account, username: grumly2, pass: foobar Pick any server. - Left click on any of the active games in the list on the left, and choose "observe after joining" from the menu. - Wbaduk tries to join the game but we keep getting "Could not obtain OLE control window handle" popups forever. Terminal output looks like: ... fixme:ieframe:PersistStreamInit_InitNew (0x5ea3c28) fixme:ieframe:OleControl_OnAmbientPropertyChange Unknown dispID -701 fixme:ieframe:OleControl_OnAmbientPropertyChange Unknown dispID -703 fixme:ieframe:OleControl_OnAmbientPropertyChange Unknown dispID -704 fixme:ieframe:OleControl_OnAmbientPropertyChange Unknown dispID -702 It's also broken with the default wine ubuntu packages on ubuntu precise and trusty (wine 1.4) If there's some useful info missing please let me know. -- 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 21

[Bug 20977] New: Bad hlp table rendering
by wine-bugs＠winehq.org 22 Aug '16

22 Aug '16

http://bugs.winehq.org/show_bug.cgi?id=20977 Summary: Bad hlp table rendering Product: Wine Version: 1.1.34 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: adys.wh(a)gmail.com Created an attachment (id=25145) --> (http://bugs.winehq.org/attachment.cgi?id=25145) Help file Terrible rendering on attached HLP file. Refer to screenshots. -- 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 35

[Bug 37271] New: Applications get IP address of 127.12.34.56 when lo0 is up
by wine-bugs＠winehq.org 22 Aug '16

22 Aug '16

https://bugs.winehq.org/show_bug.cgi?id=37271 Bug ID: 37271 Summary: Applications get IP address of 127.12.34.56 when lo0 is up Product: Wine Version: 1.7.26 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jere(a)krischel.org My testing is specifically with Artemis 2.1.1, but it seems to be true for other applications as well. When running Artemis 2.1.1 under a standard OSX Mavericks 10.9.4 install, the application reports an IP address of 127.12.34.56. If I specifically shut down the loopback interface (lo0), it reports the IP address of the box properly (192.168.1.104). This behavior is *not* seen on Ubuntu 14.04.1, which has a loopback interface, but seems to prioritize it differently than OSX. I checked the routing table before and after shutting down the loopback interface, and this is the line that disappears on OSX after lo0 is down: Destination Gateway Flags Refs Use Netif Expire localhost localhost UH 0 0 lo0 -- 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 12