http://bugs.winehq.org/show_bug.cgi?id=29589
Bug #: 29589
Summary: Interface corruption in the Windows Live Essentials
2011 installer
Product: Wine
Version: 1.3.36
Platform: x86-64
URL: http://g.live.com/1rewlive4-web/en/wlsetup-web.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: trivial
Priority: P2
Component: winex11.drv
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: RandomAccountName(a)mail.com
CC: julliard(a)winehq.org
Classification: Unclassified
Regression SHA1: c123c2f87af55f6b432e7be8560d65baee603520
The Windows Live Essentials 2011 installer shows a black rectangle near the
bottom of the screen, in place of the text "By clicking an installation option
you agree to the Microsoft service agreement and privacy" (cut off message?).
Regression testing indicated:
c123c2f87af55f6b432e7be8560d65baee603520 is the first bad commit
commit c123c2f87af55f6b432e7be8560d65baee603520
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Tue Jan 10 11:56:06 2012 +0100
winex11: Fix support for PALETTEINDEX mapping and get rid of DIBINDEX
support.
:040000 040000 c98b298f9afd6e61583dd2a1a0defbd08843b2fb
b25a5be902731076c886228453a502bb2db5b659 M dlls
Reverting fixed the problem. Standard terminal output is the same with or
without the patch.
The reported Windows version needs to be Windows 7 to run this installer.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=25134
Summary: Windows Live Essentials 2011 refuses to install
without native .NET
Product: Wine
Version: 1.3.6
Platform: x86-64
URL: http://g.live.com/1rewlive4-web/en/wlsetup-web.exe
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: RandomAccountName(a)mail.com
Created an attachment (id=31883)
--> (http://bugs.winehq.org/attachment.cgi?id=31883)
Terminal output
The installer refuses to run after "winetricks mono26 win7" saying "Windows
Live Essentials requires Microsoft .NET Framework 3." Note that it fails to run
for other reasons in other Windows versions (either due to the OS being
insufficient, or no platform update installed).
--
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.
http://bugs.winehq.org/show_bug.cgi?id=21634
Summary: ACT!2010 installer prereq check fails
Product: Wine
Version: 1.1.38
Platform: x86
URL: http://experience.act.com/
OS/Version: Linux
Status: NEW
Keywords: download, Installer
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dank(a)kegel.com
I tested the downloadable trial of ACT!2010. The installer has sha1sum
3ce9033e20c79707d3798195c74cb8e8bd3b5731 ACT! by Sage.exe
It probably needs winetricks dotnet20 first.
It fails with message
Prereq.Exceptions.KeyDoesn’tExistException: Exception of Type
‘Prereq.Exceptions.KeyDoestntExistException’ was thrown. at
Prereq.AccessINI.GetValue(StringKey, StringValueName) at
Prereq.Program.Main(String[] args).
http://community.act.com/sage/board/message?board.id=ACT&thread.id=3715
says to check the log file
C:\WINDOWS\Temp\ACTInstLog\ActWindows.log
That file contains
C:\users\Public\Application Data\Microsoft\Protect does not exist.
which seems related to the Protected Storage service
and lsass.exe, which Wine doesn't have yet.
The app then spews several crash report dialogs.
(The installer continues on anyway, and fails when installing
SQL Express, but that's a different 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.
http://bugs.winehq.org/show_bug.cgi?id=20651
Summary: Crash when installing Impulse
Product: Wine
Version: 1.1.32
Platform: PC-x86-64
URL: http://www.impulsedriven.com/downloads/impulse_setup.e
xe
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: drakkk(a)centrum.cz
Created an attachment (id=24653)
--> (http://bugs.winehq.org/attachment.cgi?id=24653)
terminal output
When installing Impulse with current git (wine-1.1.32-499-gffb2cfc), there is a
crash in file setsdaff.exe, but installer continues and reports that it
finished successfully. Another thing I noticed: after installation some
processes remains in memory, they are mscorsvw.exe (disappear aprox. 5-10
later) and rpcss.exe (remains there until killed).
Impulse needs dotnet20, I installed it with winetricks. After installation
Impulse starts, but cannot connect to server, bug 15486.
I did some search on the Stardock forums and it looks like even some windows
users had similar problem, in their case this was caused by broken .NET
install, .NET re-installation or update solved this.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=17902
Summary: ole32.CoGetClassObject: threads without apartment should
use existing MTA
Product: Wine
Version: 1.1.18
Platform: Other
URL: http://www.microsoft.com/downloads/details.aspx?FamilyID
=fe6f2099-b7b4-4f47-a244-c96d69c35dec
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ole32
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
there are apps which use free threaded COM (inproc) servers and call
CoGetClassObject() from (new) threads that do not explicitly initialize COM.
This is valid behaviour when one of the existing threads already created the
MTA by calling CoInitializeEx(NULL, COINIT_MULTITHREADED).
See: http://support.microsoft.com/kb/150777
--- quote ---
Current implementations of COM allow a thread that does not explicitly
initialize COM to be a part of the MTA. A thread that does not initialize COM
is part of the MTA only if it starts using COM after at least one other thread
in the process has previously called CoInitializeEx(NULL,
COINIT_MULTITHREADED). (It is even possible that COM itself may have
initialized the MTA when no client thread has explicitly done so; for example,
a thread associated with an STA calls CoGetClassObject/CoCreateInstance[Ex] on
a CLSID that is marked "ThreadingModel=Free" and COM implicitly creates an MTA
into which the class object is loaded.) See the information on threading model
interoperability below.
However, this is a configuration that might cause problems, such as access
violations, under certain circumstances. Therefore, it is strongly recommended
that each thread that needs to do COM work initialize COM by calling
CoInitializeEx and then, on completion of COM work, call CoUninitialize. The
cost of "unnecessarily" initializing an MTA is minimal.
--- quote ---
An example app suffering from this is the managed console debugger from .NET
2.0 SDK "cordbg.exe":
When trying to debug a simple console C# app created with symbols (.pdb
format):
--- snip ---
wine "C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\csc.exe" /debug+
foo.cs
--- snip ---
Start debugger:
--- snip ---
wine "C:\\Program Files\\Microsoft.NET\\SDK\\v2.0\\Bin\\cordbg.exe foo.exe"
--- snip ---
The debugger will immediately begin to execute the app - not halting in Main()
method (source).
This is because symbol information can't be loaded using COR symbol binder
which lives in a free threaded COM inproc server.
0A29FF9E-7F9C-4437-8B11-F424491E3931 -> CLSID_CorSymBinder
Threads 0x38 (main) and 0x36 call "CoInitializeEx" with COINIT_MULTITHREADED,
creating the MTA.
Thread 0x3b is created later as pooled thread - part of MTA - to serve CLR
debugger requests (work items).
That thread never makes any init calls to COM (verified).
--- snip ---
...
0038:Call KERNEL32.GetProcAddress(60970000,7a37e2ae "CoInitializeEx")
ret=79e9d311
0038:Ret KERNEL32.GetProcAddress() retval=609750c8 ret=79e9d311
0038:Call ole32.CoInitializeEx(00000000,00000000) ret=79ebfba8
0038:Call ntdll.RtlAllocateHeap(00110000,00000008,000000fc) ret=60986499
0038:Ret ntdll.RtlAllocateHeap() retval=0014f9c0 ret=60986499
0038:Call ntdll.RtlAllocateHeap(00110000,00000000,00000028) ret=609a750c
0038:Ret ntdll.RtlAllocateHeap() retval=001500e8 ret=609a750c
0038:Call KERNEL32.InitializeCriticalSection(001500f8) ret=609a7543
0038:Ret KERNEL32.InitializeCriticalSection() retval=00000001 ret=609a7543
0038:Call ntdll.RtlAllocateHeap(00110000,00000008,0000007c) ret=60983f54
0038:Ret ntdll.RtlAllocateHeap() retval=00151df0 ret=60983f54
0038:Call KERNEL32.InitializeCriticalSection(00151e10) ret=60983fb4
0038:Ret KERNEL32.InitializeCriticalSection() retval=00000001 ret=60983fb4
0038:Ret ole32.CoInitializeEx() retval=00000000 ret=79ebfba8
...
0036:Call ole32.CoInitializeEx(00000000,00000000) ret=79ebfba8
0036:Call ntdll.RtlAllocateHeap(00110000,00000008,000000fc) ret=60986499
0036:Ret ntdll.RtlAllocateHeap() retval=00151e78 ret=60986499
0036:Ret ole32.CoInitializeEx() retval=00000000 ret=79ebfba8
...
003b:Call advapi32.RegOpenKeyExW(80000000,0310d170
L"CLSID\\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\\InprocServer32",00000000,00020019,0310d0dc)
ret=79ea5b8a
003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a
003b:Call
...
003b:Call advapi32.RegOpenKeyExW(00000238,0310d270
L"2.0.50727",00000000,00020019,0310d0ec) ret=79ea5b8a
003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a
003b:Call advapi32.RegQueryValueExW(0000023c,7a136a40
L"ImplementedInThisVersion",00000000,0310d0e4,00000000,0310d0e8) ret=79ea5bd0
003b:Ret advapi32.RegQueryValueExW() retval=00000000 ret=79ea5bd0
003b:Call advapi32.RegCloseKey(0000023c) ret=7a1369f2
003b:Ret advapi32.RegCloseKey() retval=00000000 ret=7a1369f2
...
003b:Call advapi32.RegOpenKeyExW(80000000,0310d318
L"CLSID\\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\\InprocServer32\\2.0.50727",00000000,00020019,0310d314)
ret=79ea5b8a
003b:Ret advapi32.RegOpenKeyExW() retval=00000000 ret=79ea5b8a
003b:Call advapi32.RegQueryValueExW(00000238,79f873d0
L"Class",00000000,0310d2f8,00000000,0310d310) ret=79ea5bd0
003b:Ret advapi32.RegQueryValueExW() retval=00000002 ret=79ea5bd0
003b:Call advapi32.RegCloseKey(00000238) ret=79f88946
003b:Ret advapi32.RegCloseKey() retval=00000000 ret=79f88946
...
003b:Call KERNEL32.GetProcAddress(60970000,7a37e222 "CoGetClassObject")
ret=79e9d311
003b:Ret KERNEL32.GetProcAddress() retval=60974f78 ret=79e9d311
003b:Call ole32.CoGetClassObject(00175d3c,00000015,00000000,79f83a7c,0310d5e8)
ret=7a041335
003b:err:ole:CoGetClassObject apartment not initialised
003b:Ret ole32.CoGetClassObject() retval=800401f0 ret=7a041335
003b:Call KERNEL32.GetLastError() ret=79e74ab4
003b:Ret KERNEL32.GetLastError() retval=0000007f ret=79e74ab4
000007f ret=78132d14
...
003b:Call
KERNEL32.FormatMessageW(000031ff,00000000,800401f0,00000400,0310d4f4,00000000,0310d4a0)
ret=7a127c38
003b:Ret KERNEL32.FormatMessageW() retval=00000000 ret=7a127c38
--- quote ---
The failure is due to Wine's CoGetClassObject() rejecting requests when no
apartment in current thread (oletls) exists.
--- snip dlls/ole32/compobj.c ---
HRESULT WINAPI CoGetClassObject(
REFCLSID rclsid, DWORD dwClsContext, COSERVERINFO *pServerInfo,
REFIID iid, LPVOID *ppv)
{
LPUNKNOWN regClassObject;
HRESULT hres = E_UNEXPECTED;
APARTMENT *apt;
TRACE("\n\tCLSID:\t%s,\n\tIID:\t%s\n", debugstr_guid(rclsid),
debugstr_guid(iid));
if (!ppv)
return E_INVALIDARG;
*ppv = NULL;
apt = COM_CurrentApt();
if (!apt)
{
ERR("apartment not initialised\n");
return CO_E_NOTINITIALIZED;
}
...
--- snip dlls/ole32/compobj.c ---
Rather than failing CoGetClassObject() without apartment, it should look for an
existing MTA and let the current thread use it.
With the MTA being used, the inproc server is created and the app works as
intended, e.g. symbols get loaded, source can be stepped ...
Regards
--
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.
http://bugs.winehq.org/show_bug.cgi?id=24875
Summary: SongSmith doesn't install
Product: Wine
Version: 1.3.5
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: VincentBeers(a)gmail.com
Created an attachment (id=31485)
--> (http://bugs.winehq.org/attachment.cgi?id=31485)
Very short Wine log
I wanted to try out this Microsoft application for laughs, but it turns out it
won't install. Execution ends before even a single installer window is shown.
A very short log is attached to this post, but it basically ends with this:
err:msi:ITERATE_Actions Execution halted, action L"VSDCA_VsdLaunchConditions"
returned 1603
Free demo download is available here:
http://research.microsoft.com/en-us/um/redmond/projects/songsmith/download.…
Running 64-bit Ubuntu 10.10 with 32-bit Wine 1.3.5. If any more info is
required, I'll gladly help.
--
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.
http://bugs.winehq.org/show_bug.cgi?id=31087
Bug #: 31087
Summary: WMI class property retrieval: some CIM data type to
OLE variant (VT) mappings are incorrect (CIM_UINT32,
CIM_UINT16 ...)
Product: Wine
Version: 1.5.7
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: wmi&wbemprox
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello,
another problem from app in bug 24875 which deserves an extra bug.
The app still fails with wine-1.5.7-252-g1f01355
The problems seems to be a WMI -> .NET type conversion problem of "ProcessId"
property value.
"InvalidCastException" is thrown
--- snip ---
006ee1e8 7b83953f [HelperMethodFrame: 006ee1e8]
006ee258 040347f6
System.Management.PropertyData.MapWmiValueToValue(System.Object,
System.Management.CimType, Boolean)
006ee2d0 04034204 System.Management.PropertyData.get_Value()
006ee2dc 04033aa6
System.Management.ManagementBaseObject.GetPropertyValue(System.String)
006ee2e8 04033a35
System.Management.ManagementBaseObject.get_Item(System.String)
006ee2ec 04034f70
SSCustomInstaller.SSInstaller.GetSongsmithSetupPathAndCopyMSI()
006ee31c 04034c0f
SSCustomInstaller.SSInstaller.Install(System.Collections.IDictionary)
006ee350 649e3fc6
System.Configuration.Install.Installer.Install(System.Collections.IDictionary)
006ee398 649e5d38
System.Configuration.Install.AssemblyInstaller.Install(System.Collections.IDictionary)
006ee3d0 649e7f6e
System.Configuration.Install.ManagedInstallerClass.InstallHelper(System.String[])
006ee494 649e7734
System.Configuration.Install.ManagedInstallerClass.System.Configuration.Install.IManagedInstaller.ManagedInstall(System.String,
Int32)
--- snip ---
MapWmiValueToValue converts WMI values (wrapped in object) to native .NET value
(wrapped in object) with type conversion if necessary.
MSDN claims "ProcessId" is CIM_UINT32/uint32.
The following link shows example "ProcessId" property dump with 'wbemdump'
tool:
http://nukz.net/reference/wmi/hh/wmisdk/wbemdump_8wft.htm
--- snip ---
wbemdump /Q /wy root\cimv2 WQL "SELECT ProcessId
FROM Win32_process WHERE Name = 'Winmgmt.exe'"
This command produces the following output:
(WQL) SELECT ProcessId FROM Win32_Process WHERE Name = 'Winmgmt.exe'
ProcessId (CIM_UINT32/uint32) = 644 (0x284)
--- snip ---
For CIM_UINT32 type there seems to be 'unboxing' taking place:
net_value = (uint)((int)(wmi_value))
I extracted a small C# snippet from the app .NET assembly which can be used for
easy reproduction of the problem.
Save the following snippet to a text file (ex: "test.cs"):
--- snip test.cs ---
using System;
using System.Collections;
using System.Management;
class TestProgram
{
[STAThread]
static void Main(string[] args)
{
using (ManagementObjectSearcher searcher = new
ManagementObjectSearcher("Select * from Win32_Process"))
{
new ManagementScope(@"root\CIMV2");
foreach (ManagementObject obj2 in searcher.Get())
{
string str = obj2["ProcessId"].ToString();
}
}
}
}
--- snip test.cs ---
Compile it with C# compiler which is present if you installed .NET 2.0
Framework (winetricks).
--- snip ---
$ wine "C:\\windows\\Microsoft.NET\\Framework\\v2.0.50727\\csc.exe" /debug+
test.cs
--- snip ---
Run and get the same backtrace as with installer.
The problem is CIMTYPE -> OLE Variant type conversion.
Source:
http://source.winehq.org/git/wine.git/blob/d2661b802556e073760af5d70869fb55…
--- snip ---
665 HRESULT get_propval( const struct view *view, UINT index, const WCHAR
*name, VARIANT *ret,
666 CIMTYPE *type, LONG *flavor )
667 {
...
681 switch (view->table->columns[column].type & COL_TYPE_MASK)
682 {
683 case CIM_STRING:
684 case CIM_DATETIME:
685 V_VT( ret ) = VT_BSTR;
686 V_BSTR( ret ) = SysAllocString( (const WCHAR *)(INT_PTR)val );
687 break;
688 case CIM_SINT16:
689 V_VT( ret ) = VT_I2;
690 V_I2( ret ) = val;
691 break;
692 case CIM_UINT16:
693 V_VT( ret ) = VT_UI2;
694 V_UI2( ret ) = val;
695 break;
696 case CIM_SINT32:
697 V_VT( ret ) = VT_I4;
698 V_I4( ret ) = val;
699 break;
700 case CIM_UINT32:
701 V_VT( ret ) = VT_UI4;
702 V_UI4( ret ) = val;
703 break;
704 case CIM_SINT64:
705 V_VT( ret ) = VT_BSTR;
706 V_BSTR( ret ) = get_value_bstr( view->table, row, column );
707 break;
708 case CIM_UINT64:
709 V_VT( ret ) = VT_BSTR;
710 V_BSTR( ret ) = get_value_bstr( view->table, row, column );
711 break;
...
--- snip ---
The unbox failure let me guess that CIM_UINT32 doesn't map to VT_UI4 but to
VT_I4.
Google "CIM_UINT32 VT_I4" and hit the first link -> book "Developing Wmi
Solutions: A Guide to Windows Management ..."
Bingo! There is a table which shows the type mapping (BTW good WMI resource to
read...)
uint32 - VT_I4 - CIM_UINT32
While you're at it you might want to fix other type conversions (CIM_UINT16
...) according to the table.
Regards
--
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.
http://bugs.winehq.org/show_bug.cgi?id=31088
Bug #: 31088
Summary: SongSmith 1.0.2 fails to install due to unimplemented
IWshShortcut::WindowStyle property (set/get)
Product: Wine
Version: 1.5.7
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Classification: Unclassified
Hello,
when bug 31087 is fixed the app installer runs into unimplemented
IWshShortcut::WindowStyle property (set/get)
Managed backtrace:
--- snip ---
006ee2a8 7b83953f [ComPlusMethodFrameStandaloneCleanup: 006ee2a8]
Interop.IWshRuntimeLibrary.IWshShortcut.set_WindowStyle(Int32)
006ee2b8 04035355 SSCustomInstaller.SSInstaller.CreateDesktopShortcut()
006ee2ec 0403505c
SSCustomInstaller.SSInstaller.GetSongsmithSetupPathAndCopyMSI()
006ee31c 04034c0f
SSCustomInstaller.SSInstaller.Install(System.Collections.IDictionary)
006ee350 649e3fc6
System.Configuration.Install.Installer.Install(System.Collections.IDictionary)
006ee398 649e5d38
System.Configuration.Install.AssemblyInstaller.Install(System.Collections.IDictionary)
006ee3d0 649e7f6e
System.Configuration.Install.ManagedInstallerClass.InstallHelper(System.String[])
006ee494 649e7734
System.Configuration.Install.ManagedInstallerClass.System.Configuration.Install.IManagedInstaller.ManagedInstall(System.String,
Int32)
--- snip ---
Regards
--
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.
http://bugs.winehq.org/show_bug.cgi?id=18531
Summary: FontValidator (.NET based app) needs
OleInPlaceObject_InPlaceDeactivate properly
implemented
Product: Wine
Version: 1.1.21
Platform: Other
URL: http://www.microsoft.com/typography/FontValidator.mspx
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: shdocvw
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
now that some urlmon MIME support patches are on the way which are essential
for this app ("text/xml" MIME is later needed to show XML content in embedded
browser window) I file an "intermediate" bug that needs to be fixed before we
can verify the new functionality with real apps ;-)
The story is basically about in-place activation and deactivation of embedded
browser control.
The current shdocvw OleInPlaceObject_InPlaceDeactivate stub is mostly harmless
for many embedded browser control hosting apps because they don't rely on the
fact that in-place deactivation doesn't really take place (control will be
destroyed shortly anyway).
This app use case is a bit special hence the current in-place deactivation stub
becomes the culprit.
Steps to reproduce:
1. clean WINEPREFIX
2. winetricks -q dotnet20
3. start app, "Font files" -> "Add..." -> select whatever true/opentype font
from your system
4. "Table tests" -> "Clear All" -> select only "BASE" (shortens test)
5. "Rasterization" -> deselect "Test rasterization of TrueType outlines"
(shortens test)
6. hit "Start validation"
The .NET 2.0 app creates an embedded browser control:
--- snip ---
...
0029:trace:ole:CoCreateInstance (rclsid={8856f961-340a-11d0-a96b-00c04fd705a2},
pUnkOuter=(nil), dwClsContext=00000001,
riid={00000000-0000-0000-c000-000000000046}, ppv=0x32e2a4)
...
0029:fixme:shell:URL_ParseUrl failed to parse L"Interop.SHDocVw"
...
0029:trace:win:WIN_CreateWindowEx L"Shell Embedding" L"Shell Embedding"
ex=00000100 style=46010000 0,0 0x0 parent=0x500b4 menu=(nil) inst=0x61020000
params=0x136d00
...
0029:trace:win:WIN_CreateWindowEx created window 0x100b6
...
0029:trace:shdocvw:create_shell_embedding_hwnd parent=0x500b4 hwnd=0x100b6
...
0029:trace:shdocvw:OleObject_DoVerb (0x136d00)->(-5 (nil) 0x3c80034 -1 0x500b4
0xadd434)
0029:trace:shdocvw:OleObject_DoVerb OLEIVERB_INPLACEACTIVATE
...
0029:trace:win:DestroyWindow (0x500b4)
...
--- snip ---
and a "parking window" to host the control in inactive/hidden state until the
real hosting window is about to be created and displayed to avoid runtime
penalties of destroying and recreating browser control each time.
This blog gives some insight in the world of "parking windows":
http://blogs.msdn.com/sburke/archive/2007/06/20/flashback-windows-forms-par…
--- snip ---
0029:trace:win:WIN_CreateWindowEx L"WindowsFormsParkingWindow"
L"WindowsForms10.Window.8.app.0.378734a" ex=00010000 style=02010000 0,0 0x0
parent=0xfffffffd menu=(nil) inst=0x400000 params=(nil)
...
0029:trace:win:WIN_CreateWindowEx created window 0x100b8
0029:trace:win:show_window hwnd=0x100b6, cmd=0, wasVisible 1
...
0029:fixme:shdocvw:OleInPlaceObject_InPlaceDeactivate (0x136d00)
0029:trace:shdocvw:WebBrowser_AddRef (0x136d00) ref=11
0029:trace:ole:GetErrorInfo (0, 0x32d9b0, 0x19a9c4)
0029:fixme:shdocvw:WebBrowser_QueryInterface
(0x136d00)->({df0b3d60-548f-101b-8e65-08002b2bd119} 0x32d9a8) interface not
supported
0029:trace:shdocvw:WebBrowser_Release (0x136d00) ref=10
0029:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b84385b
ip=7b84385b tid=0029
...
0029:trace:win:WIN_SetWindowLong 0x100b6 -4 61031784 W
0029:trace:win:alloc_winproc reusing 0xffff0057 for (nil)/0x61031784
0029:trace:win:WIN_DestroyWindow 0x500b4
--- snip ---
The CLR exceptions resulting from E_NOTIMPL of
OleInPlaceObject_InPlaceDeactivate are handled gracefully.
The window which is the real target for the browser control gets created later:
--- snip ---
0029:trace:win:WIN_CreateWindowEx L"C:\\windows\\temp\\tmp47b0.tmp.report.xml"
L"WindowsForms10.Window.8.app.0.378734a" ex=00050040 style=46cf0000
-2147483648,-2147483648 376x358 parent=0x10088 menu=(nil) inst=0x400000
params=(nil)
...
0029:trace:win:WIN_CreateWindowEx hwnd 0x600b4 cs 0,0 376x358
...
0029:trace:win:show_window hwnd=0x600b4, cmd=5, wasVisible 0
0029:trace:shdocvw:WebBrowser_AddRef (0x136d00) ref=11
0029:trace:shdocvw:OleObject_DoVerb (0x136d00)->(-5 (nil) 0x3c80034 -1 0x600b4
0xaece88)
0029:trace:shdocvw:OleObject_DoVerb OLEIVERB_INPLACEACTIVATE
0029:trace:shdocvw:WebBrowser_Release (0x136d00) ref=10
0029:trace:seh:raise_exception code=e0434f4d flags=1 addr=0x7b84385b
ip=7b84385b tid=0029
0029:trace:seh:raise_exception info[0]=80131509
0029:trace:seh:raise_exception eax=7b82ca1d ebx=7b8c2918 ecx=00000000
edx=0032d958 esi=0032d958 edi=e0434f4d
0029:trace:seh:raise_exception ebp=0032d920 esp=0032d8bc cs=0023 ds=002b
es=002b fs=0063 gs=006b flags=00000246
--- snip ---
The CLR exception leads to following backtrace dialog (and abort):
--- snip ---
************** Exception Text **************
System.InvalidOperationException: Unable to get the window handle for the
'AxWebBrowser' control. Windowless ActiveX controls are not supported.
at System.Windows.Forms.AxHost.EnsureWindowPresent()
at System.Windows.Forms.AxHost.InPlaceActivate()
at System.Windows.Forms.AxHost.TransitionUpTo(Int32 state)
at System.Windows.Forms.AxHost.CreateHandle()
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
at System.Windows.Forms.ContainerControl.WndProc(Message& m)
at System.Windows.Forms.Form.WmShowWindow(Message& m)
at System.Windows.Forms.Form.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr
wparam, IntPtr lparam)
--- snip ---
The activate_inplace() OLE verb bails out early because Wine thinks the control
is in-place activated (This->inplace) -> real in-place deactivation never took
place.
.NET runtime tries to fetch hosted control's window handle which fails because
no parent switch was done.
Adding simple in-place deactivation (releasing IOleInPlaceSite, resetting
This->inplace) lets this app succeed, having windows properly
switched/re-parented.
Regards
--
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.