I'm trying to run a particular installer made with Installshield on cvs wine without any Windows DLLs. This used to work (on a different machine, with who knows what other changes). Now I just get an empty InstallShield wizard frame, and then it hangs. Hrmph. Maybe installshield wants some new spiffy ole stuff. Now, this machine dual-boots with win2k, so I thought I'd try native dlls for a few things:
$ cd ~/c/windows/system $ cp /dos/c/WINNT/system/stdole.tlb . $ cp /dos/c/WINNT/system32/compobj.dll . $ cp /dos/c/WINNT/system32/storage.dll . $ cp /dos/c/WINNT/system32/ole{2,32}.dll .
$ cd ~/c/temp/disk1 $ ~/wine/wine --dll compobj,storage,ole,ole2,ole32=n Setup.exe
Unfortunately, that crashes. Rerunning with +relay > log 2>&1, and doing egrep 'fixme|^wine|^Unhand' log, I see:
fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE fixme:seh:check_resource_write Broken app is writing to the resource data, enabling work-around fixme:win:WIN_CreateWindowEx Parent is HWND_MESSAGE fixme:win:GetProcessWindowStation (void): stub fixme:win:GetThreadDesktop (9): stub fixme:win32:GetUserObjectInformationW (0x1 2 0x406817cc 64 0x4068181c),stub! fixme:win32:GetUserObjectInformationW (0x1 2 0x4068178c 64 0x4068181c),stub! fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x77a7abc8,pFormat = ^0x77a7ac1a,...): semi-stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000004,0x00000001,0x4068181c): stub fixme:advapi:SetThreadToken ((nil), (nil)): stub (NT impl. only) fixme:ntdll:NtOpenProcessToken (0xffffffff,0x00000008,0x40681828): stub fixme:ntdll:NtQueryInformationToken (0xcafe,1,0x406817d0,52,0x40681824): stub fixme:advapi:LookupAccountSidW ((null),sid=0x406817d8,0x40681724,0x40681830(80),0x403c61d8,0x4068182c(80),0x40681820): semi-stub fixme:advapi:SetThreadToken ((nil), 0xcafe): stub (NT impl. only) fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x77a8c4b8,pFormat = ^0x77a8c572,...): semi-stub fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000004,0x00000001,0x40681898): stub fixme:advapi:SetThreadToken ((nil), (nil)): stub (NT impl. only) fixme:advapi:SetThreadToken ((nil), 0xcafe): stub (NT impl. only) wine: Unhandled exception, starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x77a539ca).
There are enough fixmes there that I can believe something crucial isn't implemented yet.
Here's the last few lines of relay, plus the backtrace:
fixme:advapi:SetThreadToken ((nil), 0xcafe): stub (NT impl. only) 00000009:Ret advapi32.SetThreadToken() retval=00000000 ret=77a5e17f 00000009:Call kernel32.CloseHandle(0000cafe) ret=77a5e186 00000009:Ret kernel32.CloseHandle() retval=00000000 ret=77a5e186 00000009:Call ntdll.RtlLeaveCriticalSection(77b32b68) ret=77a5db8f 00000009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77a5db8f 00000009:Call kernel32.GetCurrentProcessId() ret=77a5b6a5 00000009:Ret kernel32.GetCurrentProcessId() retval=00000008 ret=77a5b6a5 00000009:Call kernel32.OpenEventA(001f0003,00000000,4068187c "MSFT.VSA.COM.DISABLE.8") ret=77a5b6cc 00000009:Ret kernel32.OpenEventA() retval=00000000 ret=77a5b6cc 00000009:Call kernel32.OpenEventA(00100002,00000000,77a5b6f4 "MSFT.VSA.IEC.STATUS.6c736db0") ret=77a5b6e1 00000009:Ret kernel32.OpenEventA() retval=00000000 ret=77a5b6e1 00000009:Call ntdll.RtlLeaveCriticalSection(77b333c0) ret=77b295c0 00000009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b295c0 00000009:Call ntdll.RtlEnterCriticalSection(77b326a0) ret=77a51d8e 00000009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77a51d8e wine: Unhandled exception, starting debugger... ... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x77a539ca). In 32-bit mode. 0x77a539ca (OLE32.DLL.StringFromCLSID+0x137 in C:\WINDOWS\SYSTEM\OLE32.DLL): movw 0x0(%edx),%dx Backtrace: =>0 0x77a539ca (OLE32.DLL.StringFromCLSID+0x137 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40681858) 1 0x77a5b2be (OLE32.DLL.CoRegisterMessageFilter+0x324 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=406818ac) 2 0x77a7e5f0 (OLE32.DLL.CoCreateGuid+0x1114 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=406818e4) 3 0x77a7d103 (OLE32.DLL.CoFreeUnusedLibraries+0x45b in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=406818fc) 4 0x77a6f555 (OLE32.DLL.OleCreateEx+0x1305 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=4068194c) 5 0x77a58359 (OLE32.DLL.CoCreateInstance+0x3ca1 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40681b94) 6 0x77a582ca (OLE32.DLL.CoCreateInstance+0x3c12 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40681bb0) 7 0x77a54518 (OLE32.DLL.CoCreateInstanceEx+0x223 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=4068231c) 8 0x77a5431d (OLE32.DLL.CoCreateInstanceEx+0x28 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40682344) 9 0x77a546ea (OLE32.DLL.CoCreateInstance+0x32 in C:\WINDOWS\SYSTEM\OLE32.DLL) (ebp=40682374) 10 0x00403a0f (Setup.exe.EntryPoint+0x1eb5 in C:\temp\Disk1\Setup.exe) (ebp=406823ec) 11 0x0040258b (Setup.exe.EntryPoint+0xa31 in C:\temp\Disk1\Setup.exe) (ebp=40682448) 12 0x004022c4 (Setup.exe.EntryPoint+0x76a in C:\temp\Disk1\Setup.exe) (ebp=406828a4) 13 0x00401ff9 (Setup.exe.EntryPoint+0x49f in C:\temp\Disk1\Setup.exe) (ebp=40682e34) 14 0x00401be6 (Setup.exe.EntryPoint+0x8c in C:\temp\Disk1\Setup.exe) (ebp=40682e9c) 15 0x4009dd90 (start_process+0x21c [process.c:564] in libntdll.dll.so) (ebp=40682f38) 16 0x400a212d (call_on_thread_stack+0x1d(func=0x4009db74) [sysdeps.c:171] in libntdll.dll.so) (ebp=40682ff4) 17 0x400a22c0 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000)
I'd be happy to send a better log or implement some small missing call if someone wants to point me in the right direction. - Dan
fixme:win:GetProcessWindowStation (void): stub
You can ignore lines that refer to window stations I think, it's a part of the NT window security system.
fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x77a7abc8,pFormat = ^0x77a7ac1a,...): semi-stub
I'd guess this is the more crucial one.
So, try finding out what gets passed into StringFromCLSID(), i expect there is a debug channel for it.
On Thursday 06 February 2003 03:08 am, Mike Hearn wrote:
fixme:win:GetProcessWindowStation (void): stub
You can ignore lines that refer to window stations I think, it's a part of the NT window security system.
fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x77a7abc8,pFormat = ^0x77a7ac1a,...): semi-stub
hmm.... that should be changed, it's a 100% stub now.
I'd guess this is the more crucial one.
So, try finding out what gets passed into StringFromCLSID(), i expect there is a debug channel for it.
all the rpc stuff is still +ole, so that's your channel.
Implementing NdrClientCall2 is going to be pretty difficult I think. Getting it to work for installshield seems like a good pet project for Ove & me... what is the application?
You could try:
$ cd ~/c/windows/system $ cp /dos/c/WINNT/system32/rpcrt4.dll . $ cd ~/c/temp/disk1 $ ~/wine/wine --dll compobj,storage,ole,ole2,ole32,rpcrt4=n Setup.exe
but that may not work either... Using Win2K ole they will probably call some "port" commands to do the IPC... but that's not implemented in wine.
Gregory M. Turner wrote:
Implementing NdrClientCall2 is going to be pretty difficult I think. Getting it to work for installshield seems like a good pet project for Ove & me... what is the application?
An installer made with plain old Installshield 6.
You could try:
$ cd ~/c/windows/system $ cp /dos/c/WINNT/system32/rpcrt4.dll . $ cd ~/c/temp/disk1 $ ~/wine/wine --dll compobj,storage,ole,ole2,ole32,rpcrt4=n Setup.exe
but that may not work either... Using Win2K ole they will probably call some "port" commands to do the IPC... but that's not implemented in wine.
I played around with that, but ended up writing the following recipe for running Installshield 6 installers:
-------
Installing Software on Wine
If the setup program was written with Installshield 6, here's how to run it:
You'll need to copy a few Windows files from your Windows partition. Only Win98 or WinME files will work; Win2K files don't seem to work. If you do not have a license from Microsoft for these files on this computer, you cannot legally run this software's installer under Wine (though you can probably install it under Windows and run it under Wine). The files you need are
windows/system/compobj.dll windows/system/ole2.dll windows/system/ole32.dll windows/system/oleaut32.dll windows/system/stdole32.tlb windows/system/storage.dll windows/system/rpcrt4.dll
Copy these to your fake Windows directory, e.g. ~/c/windows/system.
For instance, $ cd /dos/c/windows/system $ cp compobj.dll ole2.dll ole32.dll oleaut32.dll stdole32.tlb storage.dll rpcrt4.dll ~/c/windows/system
Start the installer (SETUP.EXE) with the command $ wine --dll compobj,storage,ole,ole2,ole32,oleaut32,rpcrt4=n SETUP.EXE
If you get the error "Error installing iKernel.exe: (0x1400)" at any point, it's probably because there are leftover processes from a previous try. You can verify this with the command $ ps augxw | grep wine
If that command shows old copies of wine, kill them with the command $ killall wine
Repeat the ps to make sure the old wines are gone.
If you get errors like "Setup failed to launch installation engine: (0x80070008), it may mean you haven't copied the right Windows files.
The installation will procede normally, if slowly. At the end, installation may hang after all files are installed. If this happens, abort the installation by pressing control-C in the window it was started in.
---------
And yes, native oleaut32 is needed. Or at least it was with 20030115; this recipe was for people without cvs. I bet it hasn't changed much since the Jan 15th release, though.
Maybe that recipe could be added to the FAQ?
- Dan
Installing IS6 installers is not very hard on Wine. You don't need any windows dlls. You need to have the winedefault.reg file installed and after that you need stdole32.tlb from windows. For the rest no native files are needed.
Roderick
On Friday 07 February 2003 18:55, Dan Kegel wrote:
Gregory M. Turner wrote:
Implementing NdrClientCall2 is going to be pretty difficult I think. Getting it to work for installshield seems like a good pet project for Ove & me... what is the application?
An installer made with plain old Installshield 6.
You could try:
$ cd ~/c/windows/system $ cp /dos/c/WINNT/system32/rpcrt4.dll . $ cd ~/c/temp/disk1 $ ~/wine/wine --dll compobj,storage,ole,ole2,ole32,rpcrt4=n Setup.exe
but that may not work either... Using Win2K ole they will probably call some "port" commands to do the IPC... but that's not implemented in wine.
I played around with that, but ended up writing the following recipe for running Installshield 6 installers:
Installing Software on Wine
If the setup program was written with Installshield 6, here's how to run it:
You'll need to copy a few Windows files from your Windows partition. Only Win98 or WinME files will work; Win2K files don't seem to work. If you do not have a license from Microsoft for these files on this computer, you cannot legally run this software's installer under Wine (though you can probably install it under Windows and run it under Wine). The files you need are
windows/system/compobj.dll windows/system/ole2.dll windows/system/ole32.dll windows/system/oleaut32.dll windows/system/stdole32.tlb windows/system/storage.dll windows/system/rpcrt4.dll
Copy these to your fake Windows directory, e.g. ~/c/windows/system.
For instance, $ cd /dos/c/windows/system $ cp compobj.dll ole2.dll ole32.dll oleaut32.dll stdole32.tlb storage.dll rpcrt4.dll ~/c/windows/system
Start the installer (SETUP.EXE) with the command $ wine --dll compobj,storage,ole,ole2,ole32,oleaut32,rpcrt4=n SETUP.EXE
If you get the error "Error installing iKernel.exe: (0x1400)" at any point, it's probably because there are leftover processes from a previous try. You can verify this with the command $ ps augxw | grep wine
If that command shows old copies of wine, kill them with the command $ killall wine
Repeat the ps to make sure the old wines are gone.
If you get errors like "Setup failed to launch installation engine: (0x80070008), it may mean you haven't copied the right Windows files.
The installation will procede normally, if slowly. At the end, installation may hang after all files are installed. If this happens, abort the installation by pressing control-C in the window it was started in.
And yes, native oleaut32 is needed. Or at least it was with 20030115; this recipe was for people without cvs. I bet it hasn't changed much since the Jan 15th release, though.
Maybe that recipe could be added to the FAQ?
- Dan
Roderick Colenbrander wrote:
Installing IS6 installers is not very hard on Wine. You don't need any windows dlls. You need to have the winedefault.reg file installed and after that you need stdole32.tlb from windows. For the rest no native files are needed.
Does ./tools/wineinstall properly install winedefault.reg? If so, then it looks like you might be mistaken. Shall I file a bug report? - Dan
Dan Kegel a écrit:
Roderick Colenbrander wrote:
Installing IS6 installers is not very hard on Wine. You don't need any windows dlls. You need to have the winedefault.reg file installed and after that you need stdole32.tlb from windows. For the rest no native files are needed.
Does ./tools/wineinstall properly install winedefault.reg?
It does install it (or did last time I used it, and those lines are still in it).
If so, then it looks like you might be mistaken. Shall I file a bug report?
What probably happened is that the one you used needed more functions from various OLE DLLs than "plain" Installshield 6 installers. A stdole32.tlb from Windows (and the proper registry keys) work for some (can't name any app, sorry) Installshield 6.
I know Ove worked on compatibility with it for Transgaming, maybe he can shed some more light on the issue.
Vincent
On Fri, Feb 07, 2003 at 01:52:34PM -0500, Vincent Béron wrote:
Dan Kegel a écrit:
Roderick Colenbrander wrote:
Installing IS6 installers is not very hard on Wine. You don't need any windows dlls. You need to have the winedefault.reg file installed and after that you need stdole32.tlb from windows. For the rest no native files are needed.
Does ./tools/wineinstall properly install winedefault.reg?
It does install it (or did last time I used it, and those lines are still in it).
If so, then it looks like you might be mistaken. Shall I file a bug report?
Please give us full error messages and/or detailed descriptions.
Ciao, Marcus
Dan Kegel wrote:
Roderick Colenbrander wrote:
Installing IS6 installers is not very hard on Wine. You don't need any windows dlls. You need to have the winedefault.reg file installed and after that you need stdole32.tlb from windows. For the rest no native files are needed.
Does ./tools/wineinstall properly install winedefault.reg? If so, then it looks like you might be mistaken. Shall I file a bug report?
- Dan
The short answer is not always. If your wine directory does not sit below your home directory (actualy is not on a dos drive letter) the the installation of the default registries fails. (been meaning to file a bug report about this some time)
There are a number of times that I have noted that our winelib programs do not work right if they do have a dos path to wine winedbg is one of them.
Tony Lambregts a écrit:
The short answer is not always. If your wine directory does not sit below your home directory (actualy is not on a dos drive letter) the the installation of the default registries fails. (been meaning to file a bug report about this some time)
I had the same problem while making RPMs. Would this patch fix it? Minimal testing only has been made.
Changelog: - Allow the wine build tree to be located anywhere, and correctly install the initial registry keys
Vincent
Index: wine/tools/wineinstall =================================================================== RCS file: /home/wine/wine/tools/wineinstall,v retrieving revision 1.51 diff -u -r1.51 wineinstall --- wine/tools/wineinstall 21 Jan 2003 20:14:36 -0000 1.51 +++ wine/tools/wineinstall 7 Feb 2003 20:50:36 -0000 @@ -610,8 +610,10 @@ echo "Preparing to install default Wine registry entries..."
# edit config files so we don't have to run regedit under X + # and make sure we are in a Windows drive mv $LCONF $LCONF.orig - sed "s/"GraphicsDriver" = .*/"GraphicsDriver" = "ttydrv"/" $LCONF.orig > $LCONF + sed "s/"GraphicsDriver" = .*/"GraphicsDriver" = "ttydrv"/" $LCONF.orig |\ + sed "s/"Path" = "${HOME}"$/"Path" = "${PWD}"/" -> $LCONF
echo "Installing default Wine registry entries..." echo
Vincent Béron wrote:
Tony Lambregts a écrit:
The short answer is not always. If your wine directory does not sit below your home directory (actualy is not on a dos drive letter) the the installation of the default registries fails. (been meaning to file a bug report about this some time)
I had the same problem while making RPMs. Would this patch fix it? Minimal testing only has been made.
Changelog:
- Allow the wine build tree to be located anywhere, and correctly
install the initial registry keys
Vincent
Index: wine/tools/wineinstall
RCS file: /home/wine/wine/tools/wineinstall,v retrieving revision 1.51 diff -u -r1.51 wineinstall --- wine/tools/wineinstall 21 Jan 2003 20:14:36 -0000 1.51 +++ wine/tools/wineinstall 7 Feb 2003 20:50:36 -0000 @@ -610,8 +610,10 @@ echo "Preparing to install default Wine registry entries..."
# edit config files so we don't have to run regedit under X
- # and make sure we are in a Windows drive mv $LCONF $LCONF.orig
- sed "s/"GraphicsDriver" = .*/"GraphicsDriver" = "ttydrv"/" $LCONF.orig > $LCONF
sed "s/"GraphicsDriver" = .*/"GraphicsDriver" = "ttydrv"/" $LCONF.orig |\
sed "s/"Path" = "${HOME}"$/"Path" = "${PWD}"/" -> $LCONF
echo "Installing default Wine registry entries..." echo
I tried this patch and it does not work for me. I have a windows drive mounted but when I choose a " no windows" install i get the following.
Configuring Wine without Windows. Some fake Windows directories must be created, to hold any .ini files, DLLs, start menu entries, and other things your applications may need to install. Where would you like your fake C drive to be placed? (default is /home/tony/c) Configuring Wine for a no-windows install in /home/tony/c...
Created /home/tony/.wine/config using default Wine configuration. You probably want to review the file, though.
Compiling regedit... make: Nothing to be done for `all'.
Preparing to install default Wine registry entries... Installing default Wine registry entries...
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: programs/regedit/regedit: cannot determine executable type for 'F:\winedefault.reg' Registry install failed.
Thanks for sharring the patch though.
Le sam 08/02/2003 à 19:16, Tony Lambregts a écrit :
I tried this patch and it does not work for me. I have a windows drive mounted but when I choose a " no windows" install i get the following.
Configuring Wine without Windows. Some fake Windows directories must be created, to hold any .ini files, DLLs, start menu entries, and other things your applications may need to install. Where would you like your fake C drive to be placed? (default is /home/tony/c) Configuring Wine for a no-windows install in /home/tony/c...
Created /home/tony/.wine/config using default Wine configuration. You probably want to review the file, though.
Compiling regedit... make: Nothing to be done for `all'.
Preparing to install default Wine registry entries... Installing default Wine registry entries...
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: Could not stat /cdrom (No such file or directory), ignoring drive D: programs/regedit/regedit: cannot determine executable type for 'F:\winedefault.reg'
It's not the issue I thought you had. Is it possible that programs/regedit/regedit is a symlink to a script (or directly a script) which tries to launch Wine and execute it's first argument?
I'll take the time to compile current CVS tonight,
Vincent
Vincent Béron wrote:
Tony Lambregts a écrit:
The short answer is not always. If your wine directory does not sit below your home directory (actualy is not on a dos drive letter) the the installation of the default registries fails. (been meaning to file a bug report about this some time)
I had the same problem while making RPMs. Would this patch fix it? Minimal testing only has been made.
Changelog:
- Allow the wine build tree to be located anywhere, and correctly
install the initial registry keys
Vincent
Index: wine/tools/wineinstall
RCS file: /home/wine/wine/tools/wineinstall,v retrieving revision 1.51 diff -u -r1.51 wineinstall --- wine/tools/wineinstall 21 Jan 2003 20:14:36 -0000 1.51 +++ wine/tools/wineinstall 7 Feb 2003 20:50:36 -0000 @@ -610,8 +610,10 @@ echo "Preparing to install default Wine registry entries..."
# edit config files so we don't have to run regedit under X
- # and make sure we are in a Windows drive mv $LCONF $LCONF.orig
- sed "s/"GraphicsDriver" = .*/"GraphicsDriver" = "ttydrv"/" $LCONF.orig > $LCONF
sed "s/"GraphicsDriver" = .*/"GraphicsDriver" = "ttydrv"/" $LCONF.orig |\
sed "s/"Path" = "${HOME}"$/"Path" = "${PWD}"/" -> $LCONF
echo "Installing default Wine registry entries..." echo
Sorry for previous report of this not working. I did some clean-up on my tree and this patch is fine.
Dan Kegel wrote:
If you get the error "Error installing iKernel.exe: (0x1400)" at any point, it's probably because there are leftover processes from a previous try. You can verify this with the command $ ps augxw | grep wine
If that command shows old copies of wine, kill them with the command $ killall wine
Repeat the ps to make sure the old wines are gone.
I suppose this recipe should emphasize that you should shut down all Wine programs before trying this, else that killall may spoil your day.
- Dan
Dan Kegel wrote:
An installer made with plain old Installshield 6.
...
Start the installer (SETUP.EXE) with the command $ wine --dll compobj,storage,ole,ole2,ole32,oleaut32,rpcrt4=n SETUP.EXE
OK, I have more data. wine-20030115 works without any DLL overrides; cvs wine requires overrides, otherwise it hangs after a while. This is a regression.
I failed to figure out how to catch this in winedbg. kill -HUP just killed wine; ^C in winedbg just caused winedbg to crash into gdb; walk process printed out the table, then terminated winedbg (!); attach doesn't appear to be a command anymore (the doc is out of date?).
What's the right way to get a stack dump of a hung program in winedbg?
--debugmsg +ole gives some idea where cvs wine hangs. grep shows that it hangs before the second _StubMgrThread message: ole.log:4796:trace:ole:_StubMgrThread Stub Manager Thread starting on (\.\pipe\WINE_OLE_StubMgr_080e15b8) ole.log:4849:trace:ole:_StubMgrThread Stub Manager Thread starting on (\.\pipe\WINE_OLE_StubMgr_08072fb0) olecvs.log:4797:trace:ole:_StubMgrThread Stub Manager Thread starting on (\.\pipe\WINE_OLE_StubMgr_0000000c)
Here's the log:
[4840 or so lines deleted] ... trace:ole:_StubMgrThread Stub Manager Thread starting on (\.\pipe\WINE_OLE_StubMgr_0000000c) warn:ole:create_marshalled_proxy Could not open named pipe to broker \.\pipe{91814EC0-B5F0-11D2-80B9-00104B1F6CEA}, le is 2 warn:ole:create_marshalled_proxy Could not open named pipe to broker \.\pipe{91814EC0-B5F0-11D2-80B9-00104B1F6CEA}, le is 2 trace:ole:CoRegisterClassObject ({22d84ec7-e201-4432-b3ed-a9dca3604594},0x40f20e30,0x00000004,0x00000000,0x483778) trace:ole:DllMain 0x40a20000 0x2 (nil) trace:ole:_LocalServerThread Starting threader for {91814ec0-b5f0-11d2-80b9-00104b1f6cea}. trace:ole:WINE_StringFromCLSID 0x403951d0->{91814EC0-B5F0-11D2-80B9-00104B1F6CEA} trace:ole:CoMarshalInterface (0x40399468, {00000001-0000-0000-c000-000000000046}, 0x40f20f50, 0, (nil), 0) trace:ole:CoGetStandardMarshal ({00000001-0000-0000-c000-000000000046},0x40f20f50,0,(nil),0,0x416f2d80) trace:ole:StdMarshalImpl_MarshalInterface (...,{00000001-0000-0000-c000-000000000046},...) trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x416f2d1c trace:ole:WINE_StringFromCLSID 0x40a5d794->{00000001-0000-0000-C000-000000000046} trace:ole:DllMain 0x40a20000 0x2 (nil) trace:ole:_LocalServerThread Starting threader for {22d84ec7-e201-4432-b3ed-a9dca3604594}. trace:ole:WINE_StringFromCLSID 0x40399438->{22D84EC7-E201-4432-B3ED-A9DCA3604594} trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x416f2d1c trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} trace:ole:WINE_StringFromCLSID 0x416f2d1c->{00000320-0000-0000-C000-000000000046} trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} trace:ole:CoMarshalInterface (0x40399490, {00000001-0000-0000-c000-000000000046}, 0x40f20e30, 0, (nil), 0) trace:ole:CoGetStandardMarshal ({00000001-0000-0000-c000-000000000046},0x40f20e30,0,(nil),0,0x41932d80) trace:ole:StdMarshalImpl_MarshalInterface (...,{00000001-0000-0000-c000-000000000046},...) trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x41932d1c trace:ole:WINE_StringFromCLSID 0x40a5d794->{00000001-0000-0000-C000-000000000046} trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x41932d1c trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} trace:ole:WINE_StringFromCLSID 0x41932d1c->{00000320-0000-0000-C000-000000000046} trace:ole:CoGetClassObject CLSID: {00000320-0000-0000-c000-000000000046}, IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} trace:ole:COMPOBJ_DLLList_Add trace:ole:COMPOBJ_DLLList_Add trace:ole:PSFacBuf_CreateStub ({00000001-0000-0000-c000-000000000046},0x40f20f50,0x416f2d04) trace:ole:PSFacBuf_CreateStub ({00000001-0000-0000-c000-000000000046},0x40f20e30,0x41932d04)
And, so you can get an idea of what would have happened right after that, here's a diff of the working log from wine-20030115 with the broken log from wine-cvs:
... many lines deleted ... 4821c4818,4822 < trace:ole:WINE_StringFromCLSID 0x40a5d754->{00000001-0000-0000-C000-000000000046} ---
trace:ole:CoMarshalInterface (0x40399490, {00000001-0000-0000-c000-000000000046}, 0x40f20e30, 0, (nil), 0) trace:ole:CoGetStandardMarshal ({00000001-0000-0000-c000-000000000046},0x40f20e30,0,(nil),0,0x41932d80) trace:ole:StdMarshalImpl_MarshalInterface (...,{00000001-0000-0000-c000-000000000046},...) trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x41932d1c trace:ole:WINE_StringFromCLSID 0x40a5d794->{00000001-0000-0000-C000-000000000046}
4832,1817960d4832 < trace:ole:CoUnmarshalInterface (0x40396028,{00000001-0000-0000-c000-000000000046},0x40682370) < trace:ole:WINE_StringFromCLSID 0x40681ec4->{0000030B-0000-0000-C000-000000000046} < trace:ole:CoGetClassObject < CLSID: {0000030b-0000-0000-c000-000000000046}, < IID: {00000001-0000-0000-c000-000000000046} < trace:ole:COMPOBJ_DLLList_Add < trace:ole:StdMarshalImpl_UnmarshalInterface (...,{00000001-0000-0000-c000-000000000046},....) < trace:ole:CoGetPSClsid () riid={00000001-0000-0000-c000-000000000046}, pclsid=0x40681e60 < trace:ole:WINE_StringFromCLSID 0x40a13754->{00000001-0000-0000-C000-000000000046} < trace:ole:__CLSIDFromStringA {00000320-0000-0000-C000-000000000046} -> 0x40681e60 < trace:ole:CoGetPSClsid () Returning CLSID={00000320-0000-0000-c000-000000000046} < trace:ole:WINE_StringFromCLSID 0x40681e60->{00000320-0000-0000-C000-000000000046} < trace:ole:CoGetClassObject < CLSID: {00000320-0000-0000-c000-000000000046}, < IID: {d5f569d0-593b-101a-b569-08002b2dbf7a} < trace:ole:COMPOBJ_DLLList_Add < trace:ole:DllMain 0x409d0000 0x2 (nil) < trace:ole:_StubMgrThread Stub Manager Thread starting on (\.\pipe\WINE_OLE_StubMgr_08072fb0) < trace:ole:CFProxy_CreateInstance ((nil),{91814ebf-b5f0-11d2-80b9-00104b1f6cea},0x40682e04) < trace:ole:PipeBuf_GetBuffer (0x4068231c,{00000001-0000-0000-c000-000000000046}), slightly wrong. < trace:ole:PipeBuf_SendReceive () < trace:ole:DllMain 0x40a20000 0x2 (nil) < trace:ole:_StubReaderThread STUB reader thread 80e15b8 < trace:ole:CFStub_Invoke ->CreateInstance({91814ebf-b5f0-11d2-80b9-00104b1f6cea})
On Sat, Feb 08, 2003 at 03:48:37AM -0800, Dan Kegel wrote:
Dan Kegel wrote:
An installer made with plain old Installshield 6.
...
Start the installer (SETUP.EXE) with the command $ wine --dll compobj,storage,ole,ole2,ole32,oleaut32,rpcrt4=n SETUP.EXE
OK, I have more data. wine-20030115 works without any DLL overrides; cvs wine requires overrides, otherwise it hangs after a while. This is a regression.
Yes, someone else spotted it already. One patch is breaking named pipes.
Ciao, Marcus
fre, 2003-02-07 kl. 18:09 skrev Gregory M. Turner:
On Thursday 06 February 2003 03:08 am, Mike Hearn wrote:
fixme:win:GetProcessWindowStation (void): stub
You can ignore lines that refer to window stations I think, it's a part of the NT window security system.
fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x77a7abc8,pFormat = ^0x77a7ac1a,...): semi-stub
hmm.... that should be changed, it's a 100% stub now.
I'd guess this is the more crucial one.
So, try finding out what gets passed into StringFromCLSID(), i expect there is a debug channel for it.
all the rpc stuff is still +ole, so that's your channel.
Implementing NdrClientCall2 is going to be pretty difficult I think. Getting it to work for installshield seems like a good pet project for Ove & me...
That should be next on my list of things to do... I also have to work on reducing resource consumption in rpcrt4 and my dcom stuff (since with my current code, installshield starts getting ERROR_TOO_MANY_OPEN_FILES errors at some point), but I'll probably have to implement NdrClientCall2 too once I get some bugs cleared out. I already have a bunch of unsubmitted bugfixes for rpcrt4 in my tree which I'll probably have to submit soon anyway...
-
Dan Kegel -
Dan Kegel -
Gregory M. Turner -
Marcus Meissner -
Mike Hearn -
Ove Kaaven -
Roderick Colenbrander -
Tony Lambregts -
Vincent Béron