[DCOM95] not installable: "a newer version had been installed"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, as Mike Hearn asked if 'wineinstall' is still needed [1], I was making some tests with no config file and a fresh 'fake_windows' created automatically by 'wine-20040615'. This is the first test of two: 'Adobe Illustrator 10' doesn't install because a problem with the DCOM95 package The steps: - - get and uncompress 'Wine-20040615' - - ./configure && make depend && make - - su root - - make install - - CTRL-D - - then the following ===== luca(a)gismo:~/cvs/wine-20040615$ wine /home/luca/win32_install/Adobe/Adobe.Illustrator.10/Adobe\ Illustrator\ 10/Setup.exe wine: creating configuration directory '/home/luca/.wine'... wine: '/home/luca/.wine' created successfully. fixme:ole:RegisterTypeLib Registering non-oleautomation interface! fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:ITypeInfo_fnRelease destroy child objects fixme:ole:create_marshalled_proxy Failed to read marshal id from classfactory of {91814ec0-b5f0-11d2-80b9-00104b1f6cea}. ************************************************************************** You must copy a 'stdole32.tlb' file to your Windows\System directory! You can get one from a Windows installation, or look for the DCOM95 package on the Microsoft Download Pages. ************************************************************************** fixme:ole:LoadTypeLibEx Wanted to load L"stdole32.tlb" as typelib, but file was not found. fixme:ole:_get_funcdesc Did not find a typeinfo for reftype 0? fixme:ole:PSFacBuf_CreateProxy GetFuncDesc 80004005 should not fail here. fixme:ole:StdMarshalImpl_UnmarshalInterface Failed to create a proxy for {91814ec1-b5f0-11d2-80b9-00104b1f6cea} fixme:ole:CoUnmarshalInterface Failed to Unmarshal the interface, 80004005? fixme:ole:_unmarshal_interface Marshalling interface {91814ec1-b5f0-11d2-80b9-00104b1f6cea} failed with 80004005 fixme:ole:deserialize_param failed to stuballoc in TKIND_RECORD. fixme:ole:xCall Failed to unmarshall param, hres 80004005 wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405de730,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00404a34). In 32 bit mode. 0x00404a34: movl 0x0(%eax),%ecx Wine-dbg> Wine-dbg>WineDbg terminated on pid 0x8 fixme:ole:_xread Read only 0 of 4 bytes from 0x50. fixme:ole:_StubReaderThread Failed with hres 80004005 luca(a)gismo:~/cvs/wine-20040615$ ===== I downloaded the DCOM95 package [2], but when I tried to install it, I got the message window: "A newer version of DCOM95 or DCOM98 had been installed. To override, you must uninstall the current version first." with this message in the 'gnome-terminal': ===== luca(a)gismo:~/cvs/wine-20040615$ wine /home/luca/.wine/drive_c/windows/temp/x86/DCom95.Exe err:module:load_builtin_dll loaded .so for L"setupx.dll" but got L"setupapi.dll" instead - probably 16-bit dll luca(a)gismo:~/cvs/wine-20040615$ ===== The same if I try to install DCOM98... and I can't install 'Adobe Illustrator 10' :-( With the 'fake_windows' provided by the 'WineTools' [3], I can install the DCOM98 with no problem. Is this the same problem reported as bug #1456 [4]? Or is it a problem of mine? Thx, bye, Gismo / Luca [1] http://www.winehq.org/hypermail/wine-devel/2004/06/0242.html [2] http://www.microsoft.com/com/dcom/dcom95/download.asp [3] http://franksworld.net/winetools.html [4] http://bugs.winehq.org/show_bug.cgi?id=1456 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0BxYVAp7Xm10JmkRAqptAJ45+cwvWG0ZX8zrAxRRvGmW7m39UwCfUA83 3s222OvH6YaXFtzLA0uK/ro= =TMuG -----END PGP SIGNATURE-----
On Wed, 16 Jun 2004 12:09:29 +0200, Luca Capello wrote:
This is the first test of two: 'Adobe Illustrator 10' doesn't install because a problem with the DCOM95 package
Yes, the InstallShield/DCOM problems are well known. Me and Rob have started looking at this in the last few days, hopefully we'll have progress to report soon.
I downloaded the DCOM95 package [2], but when I tried to install it, I got the message window: "A newer version of DCOM95 or DCOM98 had been installed. To override, you must uninstall the current version first."
You have to run it like this: WINEDLLOVERRIDES="ole32=n" wine DCOM95.exe Yes, this is unintuitive, no there is nothing we can do with default config files/registry entries to fix it as the first thing DCOM95.EXE does it extract a file called "setup.exe" or some equally generic name and run it. You have to love Windows installers.
The same if I try to install DCOM98... and I can't install 'Adobe Illustrator 10' :-(
With the 'fake_windows' provided by the 'WineTools' [3], I can install the DCOM98 with no problem.
WineTools basically sets up a fake C drive (same as our own wineprefixcreate) and then fills it with a ton of native DLLs. It's a solution you can use if you like, though the real fix is just to nail DCOM so it works out of the box.
Is this the same problem reported as bug #1456 [4]? Or is it a problem of mine?
Yes, it's the same problem but that bug is old and can be closed. I changed email addresses and no longer have full access rights to the WineHQ bugzilla so I can't do this myself. Originally I thought by modifying the ole32 DLL version we could make it install but that's a catch-22 situation: modifying the version to allow it to be upgraded just stops other apps working because the DLL appears too old. The environment variable "fix" works, but isn't well known. It's in the #winehq FAQ but that's it, AFAIK. thanks -mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Mike, on 06/16/04 14:57, Mike Hearn wrote:
On Wed, 16 Jun 2004 12:09:29 +0200, Luca Capello wrote:
This is the first test of two: 'Adobe Illustrator 10' doesn't install because a problem with the DCOM95 package Yes, the InstallShield/DCOM problems are well known. Me and Rob have started looking at this in the last few days, hopefully we'll have progress to report soon. ok, nice to hear that someone is working on it.
You have to run it like this:
WINEDLLOVERRIDES="ole32=n" wine DCOM95.exe
Yes, this is unintuitive, no there is nothing we can do with default config files/registry entries to fix it as the first thing DCOM95.EXE does it extract a file called "setup.exe" or some equally generic name and run it. You have to love Windows installers. This does the trick for both DCOM95 and DCOM98 (as in the reported logs). First, I got a message to debug a problem ===== fixme:seh:EXC_RtlRaiseException call to unimplemented function shell32.dll.SHGetSpecialFolderPathW wine: Unhandled exception (thread 0009), starting debugger... ===== but after the debug step I could continue installing DCOM95/DCOM98 without the previous problem.
Well, now I got another error for 'Adobe Illustrator 10', but I'll report it in a new thread. BTW, I supposed 'wine-devel' to be a better place than 'wine-user' to report these problems becuase I'm making these tests after Mike's question about 'wineinstall'. Please let me know if I should switch to 'wine-user'.
WineTools basically sets up a fake C drive (same as our own wineprefixcreate) and then fills it with a ton of native DLLs. It's a solution you can use if you like, though the real fix is just to nail DCOM so it works out of the box. Yes, I know the native DLLs of 'WineTools' :-) I've no preference for the WineTools' fake_windows or the Wine one: actually, if I could use the Wine one it'll be better, so the reason of my tests.
Is this the same problem reported as bug #1456 [4]? Or is it a problem of mine? Yes, it's the same problem but that bug is old and can be closed. I changed email addresses and no longer have full access rights to the WineHQ bugzilla so I can't do this myself. Originally I thought by modifying the ole32 DLL version we could make it install but that's a catch-22 situation: modifying the version to allow it to be upgraded just stops other apps working because the DLL appears too old. The environment variable "fix" works, but isn't well known. It's in the #winehq FAQ but that's it, AFAIK. Mmm, I can't find any hit for 'winedll' or 'dcom' in the WineHQ FAQ [1].
Thx, bye, Gismo / Luca [1] http://www.winehq.com/site/docs/wine-faq/index -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0FdgVAp7Xm10JmkRAgdTAJ99M+kqFEqy+ydHKKjBxY5h4lidXQCcCUpg cVapiWVoDDJXru6uXKsp/pI= =JDOd -----END PGP SIGNATURE-----
On Wed, 16 Jun 2004 16:21:22 +0200, Luca Capello wrote:
This does the trick for both DCOM95 and DCOM98 (as in the reported logs). First, I got a message to debug a problem ===== fixme:seh:EXC_RtlRaiseException call to unimplemented function shell32.dll.SHGetSpecialFolderPathW wine: Unhandled exception (thread 0009), starting debugger... =====
Well this is very strange, this function is definitely implemented in Wine. Try using WINEDLLOVERRIDES="ole32=n,shell32=b" wine DCOM95.EXE does that help?
BTW, I supposed 'wine-devel' to be a better place than 'wine-user' to report these problems becuase I'm making these tests after Mike's question about 'wineinstall'. Please let me know if I should switch to 'wine-user'.
No, this list is fine. I'll try and fix the simpler problems as we go. Of course, I'm not sure I should put too much effort into this as soon the config file will "reappear" but in the registry :)
Mmm, I can't find any hit for 'winedll' or 'dcom' in the WineHQ FAQ [1].
I meant the #winehq channel FAQ I (badly) maintain. See here: http://bylands.dur.ac.uk/~mh/wine-faq.html I guess this should be linked to from winehq really, it is more about specific problems with specific apps than the official FAQ which is more general. thanks -mike
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello again, on 06/16/04 16:46, Mike Hearn wrote:
On Wed, 16 Jun 2004 16:21:22 +0200, Luca Capello wrote:
This does the trick for both DCOM95 and DCOM98 (as in the reported logs). First, I got a message to debug a problem ===== fixme:seh:EXC_RtlRaiseException call to unimplemented function shell32.dll.SHGetSpecialFolderPathW wine: Unhandled exception (thread 0009), starting debugger... ===== Well this is very strange, this function is definitely implemented in Wine. Try using
WINEDLLOVERRIDES="ole32=n,shell32=b" wine DCOM95.EXE
does that help? no, same problem.
BTW, I found another minor problem: the TMP folder created by DCOM95 isn't deleted at the end of the installation. You can see the log in the attached file. The same occurs for DCOM98.
No, this list is fine. I'll try and fix the simpler problems as we go. Of course, I'm not sure I should put too much effort into this as soon the config file will "reappear" but in the registry :) Ok, thank you for your efforts. I'll continue report bugs with the 'no-config' environment.
I meant the #winehq channel FAQ I (badly) maintain. See here:
http://bylands.dur.ac.uk/~mh/wine-faq.html
I guess this should be linked to from winehq really, it is more about specific problems with specific apps than the official FAQ which is more general. Sorry, my mistake. And I agree, it should be linked from WineHQ (as I don't see any other way to fall on your #winehq channel FAQ.
Thx, bye, Gismo / Luca -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFA0GLuVAp7Xm10JmkRAiK+AJ0fiPuc4nVpw4n+MvJnFo56JswepgCeM6Eo /U7OTHnwDlI7CRfMh3MNETo= =gcbG -----END PGP SIGNATURE-----
On Wed, 16 Jun 2004, Mike Hearn wrote:
On Wed, 16 Jun 2004 12:09:29 +0200, Luca Capello wrote:
"A newer version of DCOM95 or DCOM98 had been installed. To override, you must uninstall the current version first."
You have to run it like this:
WINEDLLOVERRIDES="ole32=n" wine DCOM95.exe
Yes, this is unintuitive, no there is nothing we can do with default config files/registry entries to fix it as the first thing DCOM95.EXE does it extract a file called "setup.exe" or some equally generic name and run it. You have to love Windows installers.
And why there couldn't be additional option introduced for AppDefaults sections to instruct Wine to apply AppDefaults for child processes too? If we cannot fix the situation by using the win32-process name, maybe the situation would be easier to fix if we'd using the name of its parent win32-process or even name of the its first ancestor win32-process? Lets name the option "ChildProcessInheritsAppDefaults", for example. How hard it would be to implement such parent-to-child option replication?
participants (4)
-
Luca Capello -
Mike Hearn -
Mike Hearn -
Saulius Krasuckas