wine-bugs July 2009

wine-bugs@winehq.org

1 participants
6001 discussions

[Bug 13029] New: winetest should make it possible to just extract the individual tests
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=13029 Summary: winetest should make it possible to just extract the individual tests Product: Wine Version: CVS/GIT Platform: Other OS/Version: other Status: NEW Severity: enhancement Priority: P2 Component: testcases AssignedTo: wine-bugs(a)winehq.org ReportedBy: fgouget(a)codeweavers.com The first task that winetest does is extract the individual test binaries. However it does not say where and if one wants to get at them (to then run them by hand for testing/debugging purposes), then one has to kill winetest, and track down its temporary directory (which is something like in c:\Documents and Settings\account\Local Settings\Temp\wctXXX btw). It would be nice to have an 'Extract tests' button in the main dialog that would open a dialog letting the user choose where to save the individual tests (or some other reasonably simple way of achieving the same purpose). -- 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 10

[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 16841] New: Max Payne 2: The Fall of Max Payne installation fails
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=16841 Summary: Max Payne 2: The Fall of Max Payne installation fails Product: Wine Version: 1.1.12 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: drobyshewsky(a)gmail.com Created an attachment (id=18557) --> (http://bugs.winehq.org/attachment.cgi?id=18557) Max Payne 2: The Fall of Max Payne installation fails Max Payne 2: The Fall of Max Payne installation fails -- 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 5

[Bug 16849] New: Regression: MSI error 1608
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=16849 Summary: Regression: MSI error 1608 Product: Wine Version: 1.1.12 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Created an attachment (id=18583) --> (http://bugs.winehq.org/attachment.cgi?id=18583) Screenshot 1608 EM In Wine 1.1.12 (and I believe 1.1.11), when attempting to install: Slingplayer http://appdb.winehq.org/objectManager.php?sClass=version&iId=11492 http://appdb.winehq.org/objectManager.php?sClass=version&iId=14812 eBay Turbo Lister http://appdb.winehq.org/objectManager.php?sClass=version&iId=15122 and apparently Mathematica 5.1 http://bugs.winehq.org/show_bug.cgi?id=11771 and probably others (I didn't keep a list), MSI exits with error "1608: Unable to create InstallDriver Instance, Return Code: -2147467262". The installer works fine under Wine 1.0.0. Running git bisect, will update when done. -- 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 16851] New: Morrowind GOTY - DVD - Installers fail.
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=16851 Summary: Morrowind GOTY - DVD - Installers fail. Product: Wine Version: 1.1.12 Platform: Other OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: kphillisjr(a)gmail.com The installers all fail when launching ikernel.exe, and this is on a default install of 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 5

[Bug 17920] New: OleUIAddVerbMenu is not realized
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=17920 Summary: OleUIAddVerbMenu is not realized Product: Wine Version: unspecified Platform: Other URL: http://msdn.microsoft.com/en- us/library/ms686597(VS.85).aspx OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: ole AssignedTo: wine-bugs(a)winehq.org ReportedBy: lav(a)etersoft.ru OleUIAddVerbMenu is not realized at all in current Wine. My last realization post at January, 16: http://www.winehq.org/pipermail/wine-patches/2009-January/067827.html This realization tested with 1C Accounting program (specified for Russia) and has no reclamation. -- 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 15384] New: Incorrect behaviour when using BIF_RETURNONLYFSDIRS | BIF_BROWSEINCLUDEFILES
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=15384 Summary: Incorrect behaviour when using BIF_RETURNONLYFSDIRS | BIF_BROWSEINCLUDEFILES Product: Wine Version: 1.0.0 Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: shell32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: boris.seve(a)drillscan.com When calling SHBrowseForFolder with both BIF_RETURNONLYFSDIRS and BIF_BROWSEINCLUDEFILES flags the 'Ok' button is incorrectly disabled when a file is selected (button is enabled however when a directory is selected) If only the BIF_BROWSEINCLUDEFILES flag is set the 'Ok' button is correctly enabled when a file is selected. AFAIK (and confirmed on Windows XP SP3) the 'Ok' should be enabled when a directory is selected AND when a file is selected if both flags are set. This holds true whether BIF_NEWDIALOGSTYLE is set or not. -- 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 18578] New: Wine reverses big/small icon resources in WM_SETICON
by wine-bugs＠winehq.org 05 Jan '16

05 Jan '16

http://bugs.winehq.org/show_bug.cgi?id=18578 Summary: Wine reverses big/small icon resources in WM_SETICON Product: Wine Version: 1.1.21 Platform: PC-x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: trivial Priority: P2 Component: user32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: emwine(a)earthlink.net Created an attachment (id=21241) --> (http://bugs.winehq.org/attachment.cgi?id=21241) Testcase binary and source (VC 6.0 command line for compiling at end of c file) This could be two bugs, could be one-- I'm not sure. This occurs both in WM_SETICON, and also when registering a WNDCLASS structure with RegisterClassEx(). When calling WM_SETICON, wParam indicates whether or not to use the big or small resource. (ICON_BIG, or ICON_SMALL). Windows reverses these, Wine doesn't. Running the testcase: Windows: icon, then press 'b': get 16x16 IDI_ICON icon, then press 's': get scaled 32x32 IDI_ICON Wine: wine icon, then press 'b': get scaled 32x32 IDI_ICON wine icon, then press 's': nothing at all For Wine, you may have to hit 'b' a few times, even restarting the app before it works-- I don't know why it's flaky. I noticed this problem because I had ugly icons in my MFC MDI app in Wine, and realized it was scaling the 32x32 resource instead of using the 16x16 one. When writing the app, I noticed that CWnd::SetIcon(HICON, BOOL bBig) reversed the 2nd parameter in reality. Probably Wine just went by the docs and nobody noticed the docs are reversed from reality. The other issue that may in fact be the same bug is that the WNDCLASS structure's icons are reversed as well. I'm thinking it's the same windows bug responsible for the reversal with the documentation manifesting itself in multiple places. So it's entirely possible it's just one issue in Wine also since Wine doesn't reverse them. Running the testcase again: Windows: icon: IDI_APPLICATION used (hIconSm) icon foo: IDI_QUESTION used (hIconSm) Wine: wine icon: IDI_QUESTION used (hIcon) wine icon foo: IDI_APPLICATION used (hIcon) There's also a question of what happens when you use hInstance instead of NULL in the LoadIcon() calls, but this bug isn't dealing with that 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 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs July 2009