August 2012 - Wine-bugs - list.winehq.org

[Bug 30351] New: Firefox + Selenium hangs on startup
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=30351 Bug #: 30351 Summary: Firefox + Selenium hangs on startup Product: Wine Version: 1.5.1 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: fracting(a)gmail.com Classification: Unclassified 1. Download and install python26 from http://www.python.org/ftp/python/2.6/python-2.6.msi 2. Download and install easyinstall from http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11.win32-py… 3. start wine cmd, install Selenium with easyinstall : easyinstall selenium 4. start the sample python-selenium script as attachment selenium-firefox.py : $ wine 'c:\python26\python.exe' selenium-firefox.py Firefox doesn't start as expect, it hangs with the following messages: fixme:system:SetProcessDPIAware stub! fixme:process:SetProcessDEPPolicy (1): stub fixme:iphlpapi:NotifyAddrChange (Handle 0x28fe9a4, overlapped 0x28fe988): stub fixme:winsock:WSCGetProviderPath ({e70f1aa0-ab8b-11cf-8ca3-00805f48a192} 0x2afe7a0 0x2afe760 0x2afe78c) Stub! fixme:winsock:WSCGetProviderPath ({e70f1aa0-ab8b-11cf-8ca3-00805f48a192} 0x2afe7a0 0x2afe760 0x2afe78c) Stub! fixme:winsock:WSCGetProviderPath ({11058240-be47-11cf-95c8-00805f48a192} 0x2afe7a0 0x2afe760 0x2afe78c) Stub! fixme:winsock:WSCGetProviderPath ({11058241-be47-11cf-95c8-00805f48a192} 0x2afe7a0 0x2afe760 0x2afe78c) Stub! fixme:winsock:WSCGetProviderPath ({11058241-be47-11cf-95c8-00805f48a192} 0x2afe7a0 0x2afe760 0x2afe78c) Stub! fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:advapi:FileEncryptionStatusW (L"c:\\users\\fracting\\temp\\tmpdvfiar\\prefs-1.js" 0x33cc84): stub fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented -- 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 14

[Bug 17006] New: setlocale to "en_us.UTF8" succeeds under wine, fails with native, causes knock-on failures
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=17006 Summary: setlocale to "en_us.UTF8" succeeds under wine, fails with native, causes knock-on failures Product: Wine Version: 1.1.13 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: msvcrt AssignedTo: wine-bugs(a)winehq.org ReportedBy: lkcl(a)lkcl.net here's a python program which, when run under wine, succeeds when using native msvcrt, and fails using native, but for very odd reasons (attached). note the setting of locale (equivalent in c to setlocale(LC_TYPE, "en_US.UTF-8")? well, with native msvcrt.dll, that fails - the locale doesn't exist. so, the test is skipped. but under wine, it proceeds... and then wine fails to do the right things! in other words, it _does_ identify 0xa0 as a space (true), it _does_ identify 0xc0 as alpha, and a number, and upper. the next tests, which depend on 0xa0 being _not_ identified as space, then obviously fail as well. so the question is: strictly speaking, setlocale("en_US.UTF-8") shouldn't be going ahead in the first place, but if it does, should these tests work as expected? wossgoinon? :) -- 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 8

[Bug 29426] New: UDF support: VOLUME_GetSuperblockSerial invalid for some volume types
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=29426 Bug #: 29426 Summary: UDF support: VOLUME_GetSuperblockSerial invalid for some volume types Product: Wine Version: unspecified Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: winehq.org(a)mcfang.com Classification: Unclassified VOLUME_GetSuperblockSerial returns an incorrect serial for certain UDF volumes. Volume types affected: * ISO9660+UDF for all revisions: Serial displays as '0104-0001' * UDF revision 2.50/2.60: Serial displays as '0000-0000' Serial is correct for standalone UDF revisions 1.02/1.50/2.00/2.01 Test Case: Run 'wine cmd' to open the command line and observe the output of the `vol` command. Output differs from `vol` run on a native windows system for the above volume types. History: UDF support was introduced as a patch for bug #26273 http://bugs.winehq.org/show_bug.cgi?id=26273 and is hardcoded to use the 257th sector (Address 526336) for serial calculation. The actual sector used for serial calculations depends on the UDF revision and volume type. I suspect the sector may be coded somewhere in the UDF Specifications, and if that is the case then it should be a better solution than hardcoding. Serial calculations: * Sector 257 for UDF revisions 1.02/1.50/2.00/2.01 * Sector 260 for ISO9660+UDF revisions 1.02/1.50/2.00/2.01 * Sector 320 for UDF revisions 2.50/2.60 with or without ISO9660 -- 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 15

[Bug 22856] New: Runes of Magic 3.0.x: crashes at startup
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=22856 Summary: Runes of Magic 3.0.x: crashes at startup Product: Wine Version: 1.2-rc1 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P5 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: florianmattner(a)online.de Wine crashes when I open the Client.exe Wine says that the ClientUpdater.exe has been crashed. -- 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 18

[Bug 30444] New: Microsoft SQL Server Management Studio Express (SSMSE): opening new query window fails due to atl80 insufficiency
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=30444 Bug #: 30444 Summary: Microsoft SQL Server Management Studio Express (SSMSE): opening new query window fails due to atl80 insufficiency Product: Wine Version: 1.5.2 Platform: x86 URL: http://go.microsoft.com/fwlink/?linkid=65212 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: atl AssignedTo: wine-bugs(a)winehq.org ReportedBy: djelinski1(a)gmail.com Classification: Unclassified Created attachment 39803 --> http://bugs.winehq.org/attachment.cgi?id=39803 log of ssmsee.exe - steps as described. To reproduce: - run application - connection window appears. Cancel this window. - click New query button in the top toolbar. Another connection window appeaers. Connect to a running instance of MS SQL Server. A message box informing about an unhandled exception appears. It is possible to click Continue, however the window that appears is unusable. It used to work fine in wine-1.5.1. The commit that broke was "atl80: new dll". There exists an easy workaround - start winecfg and in libraries tab set atl80 to native - the native dll is installed by application installer, so no further steps are required. winetricks dotnet20 and a recent version of windows in winecfg is needed to start the application. Running instance of SQL Server is needed to reproduce this bug. -- 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 6

[Bug 25470] New: msvcrt:cpp tests do not run on 64-bit
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=25470 Summary: msvcrt:cpp tests do not run on 64-bit Product: Wine Version: 1.3.8 Platform: x86-64 URL: http://test.winehq.org/data/4ad97d404d30f9ec62649a7b81 80f51b7eb4a759/wine_ae-ub1004-x64/msvcrt:cpp.html OS/Version: Linux Status: NEW Keywords: download, source, testcase Severity: minor Priority: P2 Component: msvcrt AssignedTo: wine-bugs(a)winehq.org ReportedBy: austinenglish(a)gmail.com Doesn't run on windows or wine: http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/win7_w… http://test.winehq.org/data/4ad97d404d30f9ec62649a7b8180f51b7eb4a759/wine_a… -- 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 25717] New: Japanese fonts sometimes shifted to the left
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=25717 Summary: Japanese fonts sometimes shifted to the left Product: Wine Version: 1.3.11 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: gdi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: galtgendo(a)o2.pl Created an attachment (id=32764) --> (http://bugs.winehq.org/attachment.cgi?id=32764) output with WINEDEBUG=+font After I set up new set of font overrides (first app I encountered, that was looking up MSPGothic by its Japanese name), I ran into a strange effect. While fonts in menus were rendered correctly (well, AFAICT), glyphs in other places were shifted a bit to the left, as shown on the screenshot. Attaching log from WINEDEBUG=+font first. -- 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 88

[Bug 24621] New: Slow UI and toolbar redraw in SolidWorks
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=24621 Summary: Slow UI and toolbar redraw in SolidWorks Product: Wine Version: 1.3.4 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: denis.bonnenfant(a)diderot.org In SolidWorks, toolbars are organized in tabs, displayed contextually depending on actions ( sketching, 3D functions... ). Left panel displays a tree view, or functions properties. toolbars : Manual switching between tabs works normally, no slowdown, but sometimes tabs are drawn outside of the application window, at the top left of the screen, just below system bar (see screenshot). Moving windows erases this. When tab switching is initiated by another operation, the refresh logic is not good : first, toolbar is displayed, but then it is redrawn very slowly (1-2s, left to right). This operation slows down all the UI, resulting in a very unpleasant lag for user (icons can't be selected during redraw) Left panel (property manager) : It contain collapsable areas, containing different dialog boxes ( see screenshot ). On any updates, left panel is first displayed correctly and quite fastly. But then titles of collapsable boxes and some graphic areas are erased very slowly (1-2s, left to right) (see screenshot). This operation slows down all the UI, resulting in a very unpleasant lag for user too -- 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 16

[Bug 19465] New: _mktime64 does not work with time/dates after 2038
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=19465 Summary: _mktime64 does not work with time/dates after 2038 Product: Wine Version: 1.1.26 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt AssignedTo: wine-bugs(a)winehq.org ReportedBy: spencercw(a)googlemail.com Created an attachment (id=22617) --> (http://bugs.winehq.org/attachment.cgi?id=22617) Sample program showing the bug A simple example program is attached. Any attempt to use _mktime64 with a date after ~2038 (i.e., any date that would require a 64-bit timestamp) returns -1 in Wine, but works ok in Windows (the example program shows 29348006400, tested WinXP 32 and Win7 64, cross compiled mingw32 4.4.0). Since there doesn't appear to be any way to force UNIX mktime to return a 64-bit value, I suspect the only work-around for this would be to re-implement mktime in Wine. -- 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 6

[Bug 17031] New: popen not connecting to stdin / stdout correctly
by wine-bugs＠winehq.org 21 Dec '12

21 Dec '12

http://bugs.winehq.org/show_bug.cgi?id=17031 Summary: popen not connecting to stdin / stdout correctly Product: Wine Version: 1.1.13 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: lkcl(a)lkcl.net same command run as wine c:/mingw/bin/windres.exe _does_ work, but when run from /bin/sh.exe in msys, it fails. $ windres.exe --input python_dll.rc --output python_dll.res --output-format=coff c:\mingw\bin\windres.exe: can't popen `c:\mingw\bin\gcc -E -xc -DRC_INVOKED python_dll.rc': Bad file descriptor this is related to http://bugs.winehq.org/show_bug.cgi?id=16968 which is a slightly more complex test but still involving popen (ultimately). on 1.0.1, there was no question that this was an out-and-out failure: however, under 1.1.13, #16968 seemed to succeed. so it would appear that things have simply got... a little bit faster, in 1.1.13, so it "seems" that the problem has "gone away", but it hasn't. -- 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 18