http://bugs.winehq.org/show_bug.cgi?id=8159
------- Additional Comments From focht(a)gmx.net 2007-24-04 08:34 -------
Created an attachment (id=5916)
--> (http://bugs.winehq.org/attachment.cgi?id=5916&action=view)
Test Client which mimics ie6sp1 installer behaviour
Hello,
this test client mimics ie6sp1 installer to verify ole server
lifetime/apartment issue.
You need Microsoft Active Setup Engine (inseng.dll) registered.
Runs fine on windows.
Crashes on wine while trying to access interface (of unloaded inproc server).
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8158
vitaliy(a)kievinfo.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
------- Additional Comments From vitaliy(a)kievinfo.com 2007-24-04 08:09 -------
Hm somehow urlmon.h made it into my source dir. And `git show` doesn't say
anything about it being there...
Sorry for wasted time.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8159
Summary: Native ie6sp1 install crashes/broken, possibly affects
other apps using OLE too
Product: Wine
Version: 0.9.35.
Platform: All
URL: http://download.microsoft.com/download/ie6sp1/finrel/6_s
p1/W98NT42KMeXP/DE/ie6setup.exe
OS/Version: other
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: wine-ole
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: focht(a)gmx.net
Hello,
while playing with some application, i needed to install native ie6sp1 (not just
fake with winetricks).
Doesnt work, now crashes in installer (ie6wzd.exe).
I remember this has worked before?
Some debugging revealed that modules are unloaded due to CoUninitialize.
COM interface method calls cause access violations because the inproc server is
already unloaded/dead.
In this specific case: native install engine, inseng.dll, IID_IInstall
Explicit wine dll override of inseng.dll produces same result.
All tested on clean install (rm -rf .wine)
wine-0.9.35-140-g452f728
Following are explicit and implicit ole/com init/uninit calls, extracted from
log (i paired them for betting reading):
--- snip ---
0009:trace:ole:CoInitializeEx ((nil), 2)
0009:trace:ole:CoInitializeEx () - Initializing the COM libraries
000d:trace:ole:OleInitialize ((nil))
000d:trace:ole:CoInitializeEx ((nil), 2)
000d:trace:ole:OleInitialize ((nil))
000d:trace:ole:CoInitializeEx ((nil), 2)
000d:trace:ole:OleUninitialize ()
000d:trace:ole:CoUninitialize ()
000d:trace:ole:OleUninitialize ()
000d:trace:ole:OleUninitialize () - Freeing the last reference count
000d:trace:ole:CoUninitialize ()
000d:trace:ole:OleInitialize ((nil))
000d:trace:ole:CoInitializeEx ((nil), 2)
000d:trace:ole:OleUninitialize ()
000d:trace:ole:OleUninitialize () - Freeing the last reference count
000d:trace:ole:CoUninitialize ()
000d:trace:ole:CoInitializeEx ((nil), 2)
000d:trace:ole:CoUninitialize ()
000d:trace:ole:apartment_release 80000000d: after = 0
000d:trace:ole:apartment_release destroying apartment 0x16f708, oxid 80000000d
000d:trace:ole:COMPOBJ_DllList_ReleaseRef freeing 0x50060000
000d:trace:ole:DllMain (0x68f30000,0,(nil))
000d:trace:loaddll:free_modref Unloaded module
L"C:\\windows\\temp\\xxx\\inseng.dll" : native
000d:trace:loaddll:free_modref Unloaded module
L"c:\\windows\\system32\\oleaut32.dll" : builtin
--- snip ---
You might argue that all Ole Init and Uninit calls are apartment-wise balanced,
therefore the unload of installer engine due to apartment release in
CoUninitialize() is valid.
This is not the way windows handles inproc server/module refcounts...
The global COM reference count is still > 1 (due to first CoInitializeEx() call,
see tid=0009) (independent of apartments).
For proof i wrote a small test client which shows same behaviour as the ie6
installer.
Will follow in next attachment.
Such code is not that uncommon...
The ol32 maintainer might consider COMPOBJ_DllList_ReleaseRef()
(apartment_release, ...) honour s_COMLockCount...
Though this change might require more testing :)
Regards
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5841
------- Additional Comments From dank(a)kegel.com 2007-24-04 07:58 -------
The easiest way to install the prerequisites is now
wget http://kegel.com/wine/winetricks
sh winetricks fakeie6 vbrun60 mdac27
If you get the error
Unhandled exception: unimplemented function
syssetup.dll.SetupQueryRegisteredOsComponent called in 32-bit code (0x7ee5cc68).
while installing mdac, you can work around it by removing syssetup.dll.so.
The problem still occurs with current wine.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=425
------- Additional Comments From blin(a)gmx.net 2007-24-04 07:58 -------
So, do we want to interface with cifs (if available) to mount remote shares?
This will probably be the way to go with named pipes. I'm still busy with taking
in all the information around winbind and some other Samba features, but if I'm
bit more clear on what we need, I can see what Samba can offer.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8158
julliard(a)winehq.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From julliard(a)winehq.com 2007-24-04 07:48 -------
Most likely your source tree isn't clean. Do a make distclean in there.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8158
------- Additional Comments From vitaliy(a)kievinfo.com 2007-24-04 07:32 -------
Correct this is out of the source tree build:
../wine.git/configure
make -s depend all"
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8151
------- Additional Comments From odal(a)stuffcenter.de 2007-24-04 07:30 -------
Well, interesting, the demo works (also without sound, I did the same how to as
for the full version).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=425
------- Additional Comments From dank(a)kegel.com 2007-24-04 07:28 -------
Mike's patch mentioned in #1 is moot
because all SMB support was removed from Wine
with http://cvs.winehq.org/patch.py?id=12382 in
March '04, with comment "Removed the no longer used
SMB file I/O support, we can't do reliable
file I/O in user space anyway."
winecfg appears to be the only place in Wine that
mentions smb/cifs, and all it does it autodetect
the mounts and let you create drive letters for them.
The URL for the UNC patch mentioned in #0 is stale; it's now at
http://www.winehq.org/pipermail/wine-patches/2001-December/001460.html
All it did was try to resolve UNC paths by looking at
/etc/fstab. Perhaps we should reconsider that approach
(or possibly a more limited one that only looks at
shares that have been assigned drive letters already).
The objection to that before was probably that Wine
should do full-on CIFS, but that objection was rendered
moot when CIFS support was removed as unreliable.
Or perhaps we should wait for Linux to support per-user mounts.
But even then we might consider the other method
as a fallback for when running on operating systems
that don't support that.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=8155
------- Additional Comments From xerox_xerox2000(a)yahoo.co.uk 2007-24-04 07:26 -------
This is a problem i already asked a question about a long time ago, but i still
don't get it really. The problem is wine seems to look in
~/.wine/drive_c/windows/fonts/ for a font, and now it finds the "guitar-pro"
font , and uses it as default font for a lot of applications. Work around is to
copy another common font (i.e. arial.ttf) to ~/.wine/drive_c/windows/fonts/,
that should solve the problem. Maybe someone could solve this "mystery" once and
for all....
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.