January 2014 - Wine-Bugs - list.winehq.org

[Bug 8539] VMXBuider 0.8 (VB6 app) fails to create new VM, reporting "Run-time error '-2147417848 (80010108)': Automation error"
by wine-bugs＠winehq.org Jan. 10, 2014

Jan. 10, 2014

http://bugs.winehq.org/show_bug.cgi?id=8539 --- Comment #19 from Nikolay Sivov <bunglehead(a)gmail.com> --- I don't trust IRecordInfo to be honest, mostly because it doesn't have any tests. I'll try to find time this weekend to improve the situation. -- 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 0

[Bug 8539] VMXBuider 0.8 (VB6 app) fails to create new VM, reporting "Run-time error '-2147417848 (80010108)': Automation error"
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=8539 --- Comment #18 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, commit http://source.winehq.org/git/wine.git/commitdiff/b058c96136850e543d171d766e… from bug 23005 helped a bit, the pre-checks of 'psa->fFeatures' on __vbaAryRecCopy() entry are now passed. Still crashes though. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/RDPSoftware/VMware/VMX Builder $ WINEDEBUG=+tid,+seh,+relay,+snoop,+ole,+variant wine ./VMXBuilder.exe >>log.txt 2>&1 ... 0028:Call oleaut32.SafeArrayAllocData(01ba6c98) ret=660db9e8 0028:trace:variant:SafeArrayAllocData (0x1ba6c98) 0028:Call ntdll.RtlAllocateHeap(00110000,00000008,000001a0) ret=7e7b19ac 0028:Ret ntdll.RtlAllocateHeap() retval=01ba6e58 ret=7e7b19ac 0028:trace:variant:SafeArrayAllocData 416 bytes allocated for data at 0x1ba6e58 (52 objects). 0028:Ret oleaut32.SafeArrayAllocData() retval=00000000 ret=660db9e8 0028:Call oleaut32.SafeArraySetRecordInfo(01ba6c98,01ba5668) ret=660dba31 0028:trace:variant:SafeArraySetRecordInfo (0x1ba6c98,0x1ba5668) ... 0028:Call oleaut32.SafeArrayCopy(01ba6d04,01ba6c90) ret=66103c0e 0028:trace:variant:SafeArrayCopy (0x1ba6d04,0x1ba6c90) 0028:trace:variant:SafeArrayGetVartype (0x1ba6d04,0x33e102) 0028:trace:variant:SafeArrayAllocDescriptorEx (36->VT_RECORD,2,0x1ba6c90) 0028:trace:variant:SafeArrayAllocDescriptor (2,0x1ba6c90) 0028:Call ntdll.RtlAllocateHeap(00110000,00000008,00000030) ret=7e7b19ac 0028:Ret ntdll.RtlAllocateHeap() retval=01bc5b90 ret=7e7b19ac 0028:trace:variant:SafeArrayAllocDescriptor (2): 32 bytes allocated for descriptor. 0028:Call ntdll.RtlAllocateHeap(00110000,00000008,000001a0) ret=7e7b19ac 0028:Ret ntdll.RtlAllocateHeap() retval=01bc5bc8 ret=7e7b19ac 0028:trace:variant:SafeArrayGetRecordInfo (0x1ba6d04,0x33e0a4) 0028:trace:ole:IRecordInfoImpl_AddRef (0x1ba5668) -> 14 0028:trace:variant:SafeArraySetRecordInfo (0x1bc5ba0,0x1ba5668) 0028:trace:ole:IRecordInfoImpl_AddRef (0x1ba5668) -> 15 0028:trace:ole:IRecordInfoImpl_Release (0x1ba5668) -> 14 0028:Ret oleaut32.SafeArrayCopy() retval=00000000 ret=66103c0e 0028:RET MSVBVM60.__vbaAryRecCopy(4872ce2c,01ba6c90,0033e1ac) retval=00000000 ret=48754a9c 0028:CALL MSVBVM60.__vbaAryRecCopy(4872ce2c,01ba6c90,0033e1ac) ret=48754a9c 0028:Call oleaut32.SafeArrayDestroyData(01bc5ba0) ret=660db598 0028:trace:variant:SafeArrayDestroyData (0x1bc5ba0) 0028:trace:variant:SafeArrayGetRecordInfo (0x1bc5ba0,0x33e0b8) 0028:trace:ole:IRecordInfoImpl_AddRef (0x1ba5668) -> 15 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5bc8) 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5be8) 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5c08) 0028:Call ntdll.RtlFreeHeap(00110000,00000000,01bab4f0) ret=7e7a03d6 0028:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e7a03d6 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5c28) 0028:Call ntdll.RtlFreeHeap(00110000,00000000,01bab530) ret=7e7a03d6 0028:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e7a03d6 ... 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5d48) 0028:Call ntdll.RtlFreeHeap(00110000,00000000,01bab838) ret=7e7a03d6 0028:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e7a03d6 0028:Call ntdll.RtlFreeHeap(00110000,00000000,01bab870) ret=7e7a03d6 0028:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7e7a03d6 0028:trace:ole:IRecordInfoImpl_RecordClear (0x1ba5668)->(0x1bc5d68) 0028:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7e7a01e5 ip=7e7a01e5 tid=0028 0028:trace:seh:raise_exception info[0]=00000000 0028:trace:seh:raise_exception info[1]=00002935 0028:trace:seh:raise_exception eax=00002935 ebx=7e8aa000 ecx=0033e010 edx=00000000 esi=0033e090 edi=7e7aff38 0028:trace:seh:raise_exception ebp=0033dff8 esp=0033dfc0 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210206 0028:trace:seh:call_stack_handlers calling handler at 0x48723286 code=c0000005 flags=0 0028:CALL MSVBVM60.__vbaExceptHandler(<unknown, check return>) ret=7bc866c9 --- snip --- Release of old resources before copy new data: __vbaAryRecCopy() -> __vbaErase() -> SafeArrayDestroyData() on target safearray Seems some double free of bstr. --- snip --- Wine-dbg>bt Backtrace: =>0 0x7e7a01e2 SysFreeString+0x36(str=<couldn't compute location>) [/home/focht/projects/wine/wine-git/dlls/oleaut32/oleaut.c:259] in oleaut32 (0x0033e078) 1 0x7e7aff45 IRecordInfoImpl_RecordClear+0x1f8(iface=<couldn't compute location>, pvExisting=<couldn't compute location>) [/home/focht/projects/wine/wine-git/dlls/oleaut32/recinfo.c:219] in oleaut32 (0x0033e0f8) 2 0x7e7b2059 SAFEARRAY_DestroyData+0x16b(psa=0x1b53038, ulStartCell=0) [/home/focht/projects/wine/wine-build32/dlls/oleaut32/../../include/oaidl.h:4150] in oleaut32 (0x0033e178) 3 0x7e7b3d4a SafeArrayDestroyData+0x9f(psa=0x1b53038) [/home/focht/projects/wine/wine-git/dlls/oleaut32/safearray.c:1239] in oleaut32 (0x0033e1c0) 4 0x660db598 in msvbvm60 (+0xdb597) (0x0033e1f4) 5 0x48754a9c in vmcomps (+0x34a9b) (0x0033e238) 6 0x004b5b1a in vmxbuilder (+0xb5b19) (0x0033e2d4) 7 0x0047650f in vmxbuilder (+0x7650e) (0x0033e37c) 8 0x660ca914 in msvbvm60 (+0xca913) (0x0033e3d8) Wine-dbg>p *This {IRecordInfo_iface={lpVtbl=0x7e8c0700}, ref=0xf, guid={Data1=0x97dfd25d, Data2=0x596c, Data3=0x4f93, Data4="????"}, lib_index=0, n_vars=0x2, size=0x8, name="GuestOSVer", fields=0x1b32a78, pTypeInfo=0x1b32888} ... {vt=VT_BSTR, varkind=VAR_PERINSTANCE, offset=0, name="DisplayedName"} {vt=VT_BSTR, varkind=VAR_PERINSTANCE, offset=0x4, name="ConfigName"} --- snip --- Disabling bstr caching with OANOCACHE=1 didn't change behaviour (point of crash didn't move). Regards -- 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 0

[Bug 35113] New: The program pluginloader.exe has encountered a serious problem.
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=35113 Bug ID: 35113 Summary: The program pluginloader.exe has encountered a serious problem. Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: vjacques01(a)gmail.com Classification: Unclassified Created attachment 46842 --> http://bugs.winehq.org/attachment.cgi?id=46842&action=edit Error file instructed to save for bug report. Wine Silverlight 4.0 5.0 & 5.1 error generated (tested all) when attempting to play a video using both Netflix desktop for Linux or when attempting to watch a video using UAControl or User Agent Overrider extensions (tried both) with user agent Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20131011 Firefox/24.0-Agent overrider. Ubuntu 13.10/Linux Mint 16 64Bit. Full error message: The program pluginloader.exe has encountered a serious problem and needs to close. We are sorry for the inconvenience. This can be caused by a problem in the program or a deficiency in Wine .You may want to check the application Database for tips about running this application. -- 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 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #138 from Ken Thomases <ken(a)codeweavers.com> --- (In reply to comment #136) > - The main thing I'm wondering about is if it wouldn't make more sense to > pass a window to wglCreateFullscreenDCWINE(). Some of the considerations > there are what should happen when the device window is e.g. destroyed or > minimized. It seems like knowing how to respond to such events should be the responsibility of ddraw/d3d. The driver can provide the tools necessary for those to implement the proper behavior. If we know what those are, we can add them to the extension. > - If we do want to pass a device name to wglCreateFullscreenDCWINE(), it > should probably take a WCHAR[], and you can get at that from the context as > "context->swapchain->device->adapter->DeviceName". I would have used a WCHAR string but make_opengl doesn't currently know about WCHARs. It could be taught. (Actually, I'd probably use "LPCWSTR" because it's easier to teach make_opengl how to handle that than "const WCHAR*".) I didn't know about getting the device name. Thanks for that. > - wglDeleteFullscreenDCWINE() seems to just be a wrapper around > DeleteDC(). If possible I think it would be preferable to be able to just > call ReleaseDC() on the DC returned by wglCreateFullscreenDCWINE(), and then > just use wined3d_release_dc(). Well, DeleteDC() and ReleaseDC() are for different purposes. ReleaseDC() is from user32 and, conceptually, user32 doesn't know anything about the DC provided by the extension and so we shouldn't ask it to release any DCs we didn't get from it (even if ReleaseDC() were a simple wrapper around DeleteDC(), which it's not). Beyond that, wined3d_release_dc() checks if WindowFromDC() matches the passed-in window and does nothing if not. I'm not aware of any way for the WGL extension to create a DC such that WindowFromDC() returns a window, except by using GetDC() and that defeats the point. Finally, although the implementation of the extension in the Mac driver is just a thin wrapper around DeleteDC(), I wanted to provide for the possibility that it might not be for some other implementation. That said, the driver does already have a pDeleteDC entry in its GDI function table, so it could put custom cleanup there. > - If we can just use wined3d_release_dc(), context->hdc_fullscreen can > just go away, but otherwise it should probably be part of the other context > bitfields like current/destroyed/valid. Indeed. I just failed to see that group of bitfields. > - When there are multiple threads drawing, wglCreateFullscreenDCWINE() is > going to be called multiple times for the same window / display. I didn't > really review the winemac.drv changes, but will it do the right thing in > that case? Good question. The implementation in the patch creates a single Cocoa window for all full-screen DCs. So the rendering from all contexts would go to the same drawable. Currently, there's also a single pixel format tracked, although it always allows the pixel format to be changed even if it was already set. That's almost certainly wrong. I was planning to change that to track the pixel format per DC in which case I'd probably enforce the usual rules about changing it. I'm not sure that's right, either. Does it make sense for multiple callers to create separate DCs with separate pixel formats but sharing a drawable? > wglGetFullscreenDCWINE() might be a more appropriate name for how > we're using this. The implication being that there should be one full-screen DC and all callers would share it? Maybe that's OK. I'm not sure. It has the issue with the pixel format – over its lifetime, can a shared DC have different pixel formats at different times? (Leaving aside the question of whether different callers would want to set different pixel formats simultaneously.) Here's another approach to that same question. What if the WGL_WINE_fullscreen_dc extension didn't add any new functions? What if it simply indicated that doing OpenGL on the screen DC returned by GetDC(0) was allowed and full-featured? Then, the change to wined3d would be to simply use GetDC(0) for a full-screen swapchain. Releasing the DC could go through ReleaseDC() (and maybe wined3d_release_dc() with some tweaking). The implementation in the driver would detect the screen DC using WindowFromDC(hdc) == GetDesktopWindow() much like what I did in attachment 46977 (which isn't that different from the newer patch). In other words, the driver-side behavior would be just the same, just with a different means of detecting when a DC was full-screen. Would that work? What about the issue with the pixel format? Are there other issues? -- 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #137 from Stefan Dösinger <stefan(a)codeweavers.com> --- (In reply to comment #136) > - The main thing I'm wondering about is if it wouldn't make more sense to > pass a window to wglCreateFullscreenDCWINE(). Some of the considerations > there are what should happen when the device window is e.g. destroyed or > minimized. Is there a device window in those ddraw cases? My impression is that SetCooperativeLevel(DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE, hwnd_that_will_never_be_visible) sets the focus window, not the device window. It would be interesting what ddraw does when an application calls SetCooperativeLevel(DDSCL_SETDEVICEWINDOW, hwnd_that_will_never_be_visible). Similarly, what do d3d8/9 do when they are passed a window like the one Worms Armageddon uses? -- 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #136 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to comment #135) > Created attachment 47154 [details] > Implement WGL extension to get fullscreen DC, use it in WineD3D > I think that mostly works for me, from a wined3d point of view. - The main thing I'm wondering about is if it wouldn't make more sense to pass a window to wglCreateFullscreenDCWINE(). Some of the considerations there are what should happen when the device window is e.g. destroyed or minimized. - If we do want to pass a device name to wglCreateFullscreenDCWINE(), it should probably take a WCHAR[], and you can get at that from the context as "context->swapchain->device->adapter->DeviceName". - wglDeleteFullscreenDCWINE() seems to just be a wrapper around DeleteDC(). If possible I think it would be preferable to be able to just call ReleaseDC() on the DC returned by wglCreateFullscreenDCWINE(), and then just use wined3d_release_dc(). - If we can just use wined3d_release_dc(), context->hdc_fullscreen can just go away, but otherwise it should probably be part of the other context bitfields like current/destroyed/valid. - When there are multiple threads drawing, wglCreateFullscreenDCWINE() is going to be called multiple times for the same window / display. I didn't really review the winemac.drv changes, but will it do the right thing in that case? wglGetFullscreenDCWINE() might be a more appropriate name for how we're using this. -- 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 9, 2014

Jan. 9, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #46977|0 |1 is obsolete| | --- Comment #135 from Ken Thomases <ken(a)codeweavers.com> --- Created attachment 47154 --> http://bugs.winehq.org/attachment.cgi?id=47154 Implement WGL extension to get fullscreen DC, use it in WineD3D (In reply to comment #132) I said (to Henri): > With respect to a WGL extension, were you thinking of something like an > alternative to wglMakeCurrent() such as wglMakeCurrentFullScreenWINE()? In looking at the code, I decided it makes more sense for the extension to provide a full-screen DC which can then be used pretty much as normal. The attached patch adds a Wine WGL extension named WGL_WINE_fullscreen_dc. It provides two functions: wglCreateFullscreenDCWINE() and wglDeleteFullscreenDCWINE(). The patch makes WineD3D aware of the extension and makes it use it instead of GetDC()/wined3d_release_dc() if the swapchain is not windowed. Then the extension is implemented in the Mac driver. Taken together, this gets Worms Armageddon to show its rendering without the use of any of its tweaks. Since the extension hasn't been implemented for the X11 driver it doesn't help there but, unlike my previous patch, it shouldn't break X11 either. It should work just like it has. If the extension is implemented for X11, then it should start working, too. -- 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 0

[Bug 8320] DirectInput joystick timestamps are wrong
by wine-bugs＠winehq.org Jan. 8, 2014

Jan. 8, 2014

https://bugs.winehq.org/show_bug.cgi?id=8320 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.6.x -- 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 8, 2014

Jan. 8, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 arthur.huillet(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC|arthur.huillet(a)free.fr | -- 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 0

[Bug 2082] DirectDraw games only showing black screen
by wine-bugs＠winehq.org Jan. 8, 2014

Jan. 8, 2014

http://bugs.winehq.org/show_bug.cgi?id=2082 --- Comment #134 from Henri Verbeet <hverbeet(a)gmail.com> --- (In reply to comment #133) > Created attachment 47148 [details] > Test z-order in ddraw tests > > To my surprise, SetForegroundWindow() has nothing to do with z-order, at > all. It just affects foreground/active statuses which are related to focus. > > This patch modifies the ddraw tests to check z-order. In all of the places > that used to call SetForegroundWindow(), I now also call SetWindowPos(…, > HWND_TOP, …). In all of the places that checked the window returned from > GetForegroundWindow(), I now also check the window order. I also check the > z-order immediately after attempting to set it to verify that it's working. > We don't want new tests to go anywhere that isn't ddraw[1247].c. (And the existing ones should get cleaned up and moved over to there eventually as well.) > The tests marked "todo_wine" in testcooperativelevels_normal() are due to > ddraw/wined3d setting the window topmost for fullscreen and, in some cases, > not restoring it. > Right, setting WS_EX_TOPMOST is correct for d3d8 and d3d9, it isn't for ddraw. (See also the various versions of test_window_style().) -- 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 0