March 2008 - Wine-bugs - list.winehq.org

[Bug 11016] New: odbc32.dll should look for libodbc.so.1 instead of libodbc .so
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=11016 Summary: odbc32.dll should look for libodbc.so.1 instead of libodbc.so Product: Wine Version: 20040615 Platform: PC URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=259710 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.org ReportedBy: ovek(a)arcticnet.no An easy one for a newbie wine hacker, maybe... Currently, in dlls/odbc32/proxyodbc.c, there's a hardcoded libodbc.so (unless an environment variable overrides it). Perhaps it would be preferable if the WINE_GET_SONAME configure macro was used to grab a name like libodbc.so.1 instead, so that if some user have installed unixodbc, things would Just Work without forcing him/her to also either install unixodbc-dev, or manually make a symlink, or figure out weird environment variables. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 11177] New: winealsa doesn't assign unique MIDI port names
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=11177 Summary: winealsa doesn't assign unique MIDI port names Product: Wine Version: 20050628 Platform: PC URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333361 OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: _obsolete_multimedia AssignedTo: wine-bugs(a)winehq.org ReportedBy: ovek(a)arcticnet.no Currently, when mapping ALSA MIDI ports to Windows MIDI port names, winealsa uses the port's client name, which is not unique and may cause some programs to get confused. A user is suggesting using the ALSA port name, which I suspect can be acquired by e.g. replacing snd_seq_client_info_get_name(cinfo) in midi.c with snd_seq_port_info_get_name(pinfo). You could also append a number to the client name, or whatever else it takes to make the name unique. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 7

[Bug 10417] New: OLEAUT32: crash if >128 methods in an interface
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=10417 Summary: OLEAUT32: crash if >128 methods in an interface Product: Wine Version: 0.9.49. Platform: Macintosh OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P1 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: mjk(a)cardbox.com This bug was encountered in build cxoffice-6.2.0rc1-2-g024be42 of Wine (part of CrossOver Mac). The bug has been identified in the current source code at http://source.winehq.org/source/dlls/oleaut32/tmarshal.c. Using any marshaled interface with more than 128 methods causes a crash within OLEAUT32 if any method at position >=128 is called. This was detected when using Cardbox (http://www.cardbox.com) and is a SHOW-STOPPER because it makes the use of VBScript macros impossible. However, the bug is completely general and applies to any application at all that has interfaces with large number of methods. It is quite possible that many random OLE / COM - related bugs that have already been reported have this bug as their underlying cause. The version of Cardbox on which the bug was found is more recent than the one currently available on the web site. If anyone wants to have a copy for testing, together with instructions for reproducing the crash, please contact me. LOCATION OF THE BUG The bug is in dlls/oleaut32/tmarshal.c. When constructing a proxy interface, PSFacBuf_CreateProxy at line #1712 constructs the following proxy code for each method: popl %eax pushl <nr> pushl %eax call xCall lret <n> (+4) where <nr> is the position of the method in the list of methods: 0, 1, 2, and so on. The pushl <nr> instruction is defined by following code: 374 BYTE pushlval; // set to 0x6a by line #1712 375 BYTE nr; The fact that the method position is a byte already limits the maximum size of an interface to 256 methods, which is less than the 512-method limit of Windows NT4.0 SP3, and the 1024-method limit of Windows 2000: see "MIDL2362" in http://msdn2.microsoft.com/en-us/library/aa366756.aspx for details. Thus this needs to be corrected in any case. The proxy code as it stands will call method 0 instead of method 256, method 1 instead of method 257, and so on, leading to random behaviour and possible stack corruption. The crash when method 128 is called has a different cause. The proxy for method 128 contains the instruction 6A 80, because the programmer thought that this would push 00000080 onto the stack. In fact the PUSH instruction with opcode 6A SIGN-EXTENDS its operand and does not zero-extend it. Thus the proxy for the 128th method pushes FFFFFF80 onto the stack before calling xCall. xCall interprets this as a negative number (-128) and thus attempts to synthesize a call not to method 128 but to a non-existent method -128. In the same way it will call method -127 instead of method 129,... and so on. SUGGESTED CORRECTION The very simple correction to this bug, which is guaranteed to work, is to alter line 375 to 375 DWORD nr; and line 1712 to 1712 xasm->pushlval = 0x68; which expects a 32-bit operand rather than an 8-bit one. This will result in every proxy using 15 bytes per method instead of 12 bytes. This does not seem an excessive price to pay for complete reliability in the future: there will then be no limit to the number of methods that can be supported. ALTERNATIVE CORRECTIONS If the 25% expansion in proxy size is considered unacceptable (it should not really be: proxies are small) then there are several ways round the problem. An increase to 256 methods could be achieved simply by adding a line at the very beginning of xCall: method &= 0xff; but this would HAVE to be accompanied by an explicit test for the method count limit (now 256) in PSFacBuf_CreateProxy so that the attempt to create a proxy with too methods would simply fail rather than (as now) generate a proxy that will randomly crash the application. Another approach would be to create dummy functions (in assembler) that would add 128, 256, 384, 512, etc to the 'method' argument before forwarding it on to xCall. In that case, method numbers after 127 would generate proxies that called one of the variant xCalls instead of the original one. The programming in PSFacBuf_CreateProxy would be relatively straightforward, and the dummy functions would not need to do any stack manipulation: they would simply add an offset to the DWORD at [ESP+8] and then JMP straight to the start of xCall. This would *still* give a finite limit to the number of methods, but the limit would be much larger. Again, good engineering practice dictates that PSFacBuf_CreateProxy should report an error if it encounters a number of methods beyond the number that it was designed to cope with. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 11

[Bug 10536] New: ITypeInfo_fnInvoke failed to convert param 0 to VT_BOOL from VT_BSTR
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=10536 Summary: ITypeInfo_fnInvoke failed to convert param 0 to VT_BOOL from VT_BSTR Product: Wine Version: 0.9.49. Platform: PC URL: http://uniqlo.jp/uniqlock OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: wine-ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: fnjordy(a)gmail.com Uniqlock screensaver doesn't display anything, presumably it might be related to the Wine output: in CSoundUtils constructor: fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE err:ole:ITypeInfo_fnInvoke failed to convert param 0 to VT_BOOL from VT_BSTR -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

[Bug 11775] New: Oleview does not correctly generate idl files
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=11775 Summary: Oleview does not correctly generate idl files Product: Wine Version: 0.9.56. Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: m.b.lankhorst(a)gmail.com When looking at the ipodservice typelib (install itunes v7.6, then look at the typelib in C:\Program Files\iPod Service\bin\iPodService.exe in wine oleview, it will generate wrong code. HRESULT foo([in]long pointer, [out, retval]VARIANT_BOOL *rar); is turned into: VARIANT_BOOL foo([in]long pointer); This happens for example with IItunesDevice_IsMounted. -- 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 11096] New: Adobe AIR / Adobe Media Player pre 2 installer crashes during MsiViewExecute
by wine-bugs＠winehq.org 30 Dec '15

30 Dec '15

http://bugs.winehq.org/show_bug.cgi?id=11096 Summary: Adobe AIR / Adobe Media Player pre 2 installer crashes during MsiViewExecute Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: msi AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com After working around bug 11094 by doing "wine regsvr32 rsaenh", the next bug is a crash that is at least near some MSI code, so I'll risk the MSI maintainer's wrath and put it in that category :-) To repeat: download http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_play… download http://download.macromedia.com/pub/labs/air/air_b3_win_121207.exe download http://download.macromedia.com/pub/labs/mediaplayer/adobemediaplayer_p2_122… wineserver -k rm -rf .wine wine install_flash_player.exe wine air_b3_win_121207.exe wine regsvr32 rsaenh wine ~/.wine/drive_c/Program\ Files/Common\ Files/Adobe\ AIR/Versions/1.0.6/Adobe\ AIR\ Application\ Installer.exe adobemediaplayer_p2_122007.air Crashes; +relay,+msi,+msidb,+seh seems to show the exception happens in MsiViewExecute: trace:msi:MSI_ViewExecute 0x171f40 0x18e3d0 trace:msidb:UPDATE_execute 0x172310 0x18e3d0 trace:msidb:SELECT_execute 0x1722d8 (nil) trace:msidb:WHERE_execute 0x19db08 (nil) trace:msidb:TABLE_execute 0x173268 (nil) trace:msidb:TABLE_execute There are 2 columns trace:msidb:TABLE_get_dimensions 0x173268 0x33e8c8 (nil) 0009:Call ntdll.RtlAllocateHeap(00110000,00000008,00000094) ret=7e3779f1 0009:Ret ntdll.RtlAllocateHeap() retval=0018dba0 ret=7e3779f1 trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e35f539 I'll attach a full log. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8

[Bug 11094] New: Adobe AIR can't install Adobe Media Player pre 2
by wine-bugs＠winehq.org 30 Dec '15

30 Dec '15

http://bugs.winehq.org/show_bug.cgi?id=11094 Summary: Adobe AIR can't install Adobe Media Player pre 2 Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Keywords: download, Installer Severity: normal Priority: P2 Component: crypt32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com This is the next bug after bug 10956. To reproduce, run the script http://bugs.winehq.org/attachment.cgi?id=9893 Adobe media player prerelease 2, http://labs.adobe.com/technologies/mediaplayer/install/ install fails. It's kind of hard to tell, but I suspect it might be that a crypto provider wasn't found: trace:crypt:CryptAcquireContextW Did not find registry entry of crypto provider for L"Software\\Microsoft\\Cryptography\\Defaults\\Provider Types\\Type 001". ... 49000 lines deleted ... 001d:Call gdi32.GetTextExtentPoint32A(00000314,006722f8 "The application could not be installed because the AIR file is damaged. Try obtaining a new AIR file",00000064,0033eff4) ret=1027b8cc -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 13

[Bug 11764] New: surround 5.1 sound
by wine-bugs＠winehq.org 24 Dec '15

24 Dec '15

http://bugs.winehq.org/show_bug.cgi?id=11764 Summary: surround 5.1 sound Product: Wine Version: 0.9.53. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: directx-dsound AssignedTo: wine-bugs(a)winehq.org ReportedBy: iugamarian(a)yahoo.com Winamp with Winamp AC3 Filter 1.01a performs better than Amarok 1.4. Also the very old game Starcraft has support for surround. Therefore please give more importance to the following: Allow DirectSound acces to Alsa, for the rear left, rear right, center and woofer speakers. Yes, Linux does support surround. Use "alsamixer" to deactivate the mute on the other speakers. Use Amarok, Totem, or their base Xine, to test surround. You have to go to settings, select Xine Engine and select 5.1 surround (in Xine you should select first "Master of the known universe" :) ) I am attaching an example of a file that the Xine engine cannot play, but Winamp with Winamp AC3 Filter 1.01a with integrated dts support can. -- 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 70

[Bug 11118] New: client side validation for Wine bug reports
by wine-bugs＠winehq.org 14 Dec '15

14 Dec '15

http://bugs.winehq.org/show_bug.cgi?id=11118 Summary: client side validation for Wine bug reports Product: WineHQ Bugzilla Version: unspecified Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: bugzilla-unknown AssignedTo: jnewman(a)codeweavers.com ReportedBy: jeffzaroyko(a)gmail.com Every now and then some bug reporters report a Wine bug that omits basic information such as the version of wine being used, instead it is set to unspecified. It could be useful to remind people who try to submit the form with the version set to unspecified by issuing an one time alert that they should set the value to their current wine version. A similar thing could be done for the URL field where people could be reminded to link to a download of the affected application. I acknowledge that there are other bugs where 'unspecified' may make sense, but they are not as frequent so the impact should be low. If the length of the input in the Description box can be taken with JavaScript, perhaps that could be checked against a commonly large length where people have pasted logs and a warning issued also. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 7

[Bug 9919] New: Microsoft Access Snapshot Viewer 10.0 install fails
by wine-bugs＠winehq.org 04 Dec '15

04 Dec '15

http://bugs.winehq.org/show_bug.cgi?id=9919 Summary: Microsoft Access Snapshot Viewer 10.0 install fails Product: Wine Version: 0.9.46. Platform: Other URL: http://www.microsoft.com/downloads/details.aspx?familyid =B73DF33F-6D74-423D-8274-8B7E6313EDFB&displaylang=en OS/Version: other Status: NEW Keywords: download, Installer Severity: enhancement Priority: P2 Component: wine-misc AssignedTo: wine-bugs(a)winehq.org ReportedBy: dank(a)kegel.com md5sum: 2aec4a3c7a1c928deeb7d1e9b8779bb2 snpvw.exe The installer aborts with "A setup initialization file has been corrupted." The installer seems to be a win16 app. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 24