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

[Bug 27655] New: Orbiter window disappears behind main orbiter window.
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=27655 Summary: Orbiter window disappears behind main orbiter window. Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: kfreezen(a)gmail.com On orbiter, if a window, such as the menu (F4), is opened, and then the cursor is moved to the main window, the former window disappears behind the main window. -- 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 28020] New: winepath -w should also look into user folders (Desktop, Music, etc), not just dosdevices
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=28020 Summary: winepath -w should also look into user folders (Desktop, Music, etc), not just dosdevices Product: Wine Version: unspecified Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: programs AssignedTo: wine-bugs(a)winehq.org ReportedBy: wine(a)rodrigosilva.com Currently, winepath -w (seems to) only search for symlinks in $WINEPREFIX/dosdevices to map a given native path to a windows one. But it should also look for user folder's symlinks (like Desktop, My Music, My Pyctures, etc) This is specially helpful if a given prefix has removed the "catch all" Z: => / mapping. In that case, winepath is mapping my "~/Desktop" to "\\?\unix\...", but it could be "smarter" and map it to "C:\users\rodrigo\Desktop" instead. Last but not least, a related limitation is the lack of winepath -u to understand windows env variables, like %USERPROFILE%. That usually points to C:\users\$USER , but since that can be changed in registry, a "windows enviroment-aware winepath -u" would be truly useful. -- 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 26158] New: Audio CD-ROM is lacking some integration into volume management on MacOS
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=26158 Summary: Audio CD-ROM is lacking some integration into volume management on MacOS Product: Wine Version: 1.3.13 Platform: x86 OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net MCICDA loops across all drives looking for one matching (GetDriveTypeW(root) == DRIVE_CDROM) but finds none on MacOS even when an audio CD-ROM is inserted. Oddly, winecfg correctly displays "Audio CD" for e.g. drive D: in auto-detection mode. However it is not until I force D: to type CD-ROM in winecfg that GetDriveType() returns the expected type, granting access to MCICDA. Furthermore, I must hit "Apply" in winecfg and leave its window open for this trick to work. Presumably otherwise the list is dynamically rebuilt by the volume manager upon the next process start and the setting overwritten. I believe this is sufficiently different from bug #20555 (A. pure audio vs. mixed data+audio CD-ROM; B. /media/cdrom vs. cdrom0) on Linux to warrant its own entry. Reproduce using my MCI shell (bug #20232, comment #10) wine wintest.exe mcishell open cdaudio will yield MCIERR_CANNOT_LOAD_DRIVER if there's no drive type match. Leave the shell open, apply configuration change in winecfg, then it succeeds. close cdaudio -- 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 26547] New: Champions Online: IE game starter fails using multilib binaries
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=26547 Summary: Champions Online: IE game starter fails using multilib binaries Product: Wine Version: 1.3.16 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: brianbourke75(a)gmail.com Champions online requires IE to launch/patch their game. When attempting to launch the game in a true 32 bit install it seems to work just fine. When attempting to launch the game using a multilib install on a 64bit system, it fails almost straight off. Using WINEARCH=win32 or win64 makes no difference. Using WINEDEBUG=+relay allows for the game to launch correct, thus indicating to me that there is probably a thread timing issue since the relay messages require a large time investment and the launcher takes much longer to run. -- 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 27315] New: Native Instruments REAKTOR 4.0 VST crashes when unloading plug in.
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=27315 Summary: Native Instruments REAKTOR 4.0 VST crashes when unloading plug in. Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: tectp(a)telefonica.net I am using Reaktor 4.0 as a vst plug in in Ableton live. Both programs function well in wine under the wineasio driver, but when I try to save the live set, or unload the plug in to swap it for another one, Ableton live freezes and has to be forced to quit. This problem persists regardless of whether I use the wineasio driver or the direct sound driver. I can run these programs under windows without any problems, but would like very much to get them working under ubuntu if possible. My setup: ubuntu 10.04 Ableton live 7.018 Reaktor 4.3 -- 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 27545] New: Wrong page borders when printing
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=27545 Summary: Wrong page borders when printing Product: Wine Version: 1.2 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: spooler AssignedTo: wine-bugs(a)winehq.org ReportedBy: graeter(a)hydrixos.net We are using Office 2007 upon Wine, which works mostly without problems. We have two printers that are connected to a CUPS server (1.4.3) which is separate from our clients. The CUPS client libraries and the CUPS server have the same version and are package from Ubuntu 10.04. One printer is a HP LaserJet P4015. When printing from any Wine application on this printer, the page borders are wrong. We are using DinA4 paper. When setting the printer dialog in Wine to "A4" parts of the page are outside the printable range. When setting it to "letter" everything is inside the printable range, but then we have a huge white border around the page. Using our second printer or when printing to PDF, this problem does not appear. For me it looks like that Wine somehow uses wrong page borders when communicating with this printer. -- 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 17432] New: Lan hosting/listening not working in warcraft iii.
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=17432 Summary: Lan hosting/listening not working in warcraft iii. Product: Wine Version: 1.1.14 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: whellmundv(a)gmail.com I thought warcraft was one game that ran as fluent as if it was native, or so I thought then. Today I've found myself experimenting for the second time how running this masterpiece from wine prevents me from enjoying a nice lan game with my friends, using both macintosh and windows systems. I don't know why, but I guess that is the reason for which I encounter myself writing this, at this precise moment: I think you will help me solve this--I believe, uncommon--problem. Please let me know which information do I need to post here, because I know not with accuracy. -- 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 13

[Bug 17721] New: RTG Bills reports dates incorrectly in bills for date formats (locals) not US
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=17721 Summary: RTG Bills reports dates incorrectly in bills for date formats (locals) not US Product: Wine Version: 1.1.15 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: mstuff(a)read.org.nz This is a bit of a major that I'm unsure whether is a bug with RTG Bills or WINE... But, here's a workaround/fix for it below. My local is New Zealand, my default language is LANG="en_NZ.UTF-8" with dates expressed "days / months / years" (like most of the world). Setting the dates in RTG Bills to my format results in any dates in the form "days / months / years" that make sense expressed as "months / days / years" being expressed as "months / days / years". For instance: 10th March 2009 (10/3/09) is expressed on bills as 3rd October 2009 (3/10/09)!!! A workaround/fix seems to be to set the environment variable $LANG to LANG="en_US.UTF-8" and then set the date format in RTG Bills to be expressed as "days / months / years". RTG Bills provides a "test" facility to check that date formats are sane for the system local settings, if this facility is used it will report that the format is "insane" and change it back to the "months / days / years" format. The answer is not to "test", but simply leave the format "untested" as "days / months / years" and save the setting. RTG Bills then seems to report dates correctly in its bills. So, my command to execute RTG Bills is: env WINEPREFIX="/home/myhome/.Rtgbills" LANG="en_US.UTF-8" wine "C:\Program Files\Rtgbills\rtgbills.exe" -- 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 9

[Bug 28168] New: VK_OEM_3 (0xC0) not converted into (0xC0) if US keyboard requested
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=28168 Summary: VK_OEM_3 (0xC0) not converted into (0xC0) if US keyboard requested Product: Wine Version: 1.3.26 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: Sebastian.Riemer(a)gmx.de E.g.: Carmageddon TDR 2000 requests an US keyboard layout no matter for which language version of the game. It also gets this for most keys. But for the cheating console the VK_OEM_3 (0xC0) is needed and MapVirtualKeyExW() in dlls/user32/input.c has to return 0xC0, too. But instead it returns 0x5E (^) on my German KDE4 openSUSE 11.3 amd64 system - so this key isn't converted to US keyboard layout. On my German Windows XP it works as expected (0xC0 is returned). I've also tried to enable the KDE4 keyboard layouts and to switch to US layout with that, but this didn't help. Here is my dirty fix with which I've tested it: UINT WINAPI MapVirtualKeyExW(UINT code, UINT maptype, HKL hkl) { TRACE_(keyboard)("(%X, %d, %p)\n", code, maptype, hkl); /* dirty fix for testing VK_OEM_3 */ if (code == 0xC0) return 0xC0; return USER_Driver->pMapVirtualKeyEx(code, maptype, hkl); } -- 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 27

[Bug 26747] New: SIV Window Resize and AdjustWindowRect() off-by-one issue
by wine-bugs＠winehq.org 23 Nov '14

23 Nov '14

http://bugs.winehq.org/show_bug.cgi?id=26747 Summary: SIV Window Resize and AdjustWindowRect() off-by-one issue Product: Wine Version: 1.3.17 Platform: x86 URL: http://rh-software.com/ OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: ray(a)pobox.co.uk While trying to work-a-round the lack of WM_EXITSIZEMOVE (http://bugs.winehq.org/show_bug.cgi?id=26736) I found what seems to be an off-by-one error within AdjustWindowRect(). Testing on real Windows then the code worked fine, but to get it to work on Wine 1.3.17-243 I needed to adjust things as in the code below. The svb->style is 0x00C40000 ( WS_CAPTION | WS_THICKFRAME ). The issue is the same for both window managers. ar->top = 0; ar->left = 0; ar->bottom = 0; ar->right = 0; if( AdjustWindowRect( ar, svb->style, FALSE ) ) { if( mode & MODE_WINE ) { dr->top -= ar->top + 1; // Client Area positions dr->left -= ar->left + 1; // dr->bottom -= ar->bottom + 1; // dr->right -= ar->right + 1; // } else { dr->top -= ar->top; // Client Area positions dr->left -= ar->left; // dr->bottom -= ar->bottom; // dr->right -= ar->right; // } -- 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 17