At the outset I must apologize for the length of this post. This situation is intricately convoluted and, currently, I cannot interpret the information that I have collected. Right now I can only relay information that I think is relevant. I would be more than happy to generate more info, but I will need some specific direction for commands and so forth. Right now I have reached the limit of my current troubleshooting skills.
My overall goal is to get Edit Studio 4, a video editing application, running in wine. It depends on the IE6 Help Engine. There are other situations with this app and that's why I don't depend on an older version of wine to run it. Right now, if I can't get IE6 to run its help engine, I can't get my app to work. Here goes on my problems with IE6.
Conventions: 1013 implies wine compiled from the cvs update on October 13 and a .wine, created from that update
aug implies wine version compiled from the cvs update on October 13 and a .wine from a wine version, compiled from my repository, before the 20040824 16:00:16 CDT commit
Symptoms: 1. with wine from 1013 and .wine from 1013, IE6 exits with no window--this started sometime after the September snapshot 2. with wine from 1013, any version of wine that I compile, and .wine from aug, IE6 runs and Help works 3. with wine from September snapshot and .wine from 1013, IE6 creates a segmentation fault
My original symptom was that I couldn't get IE6 Help to work after the September snapshot. I did a regression and identified the commit of 20040824 16:00:16 CDT as causing the problem. The commit edits this patch:
http://cvs.winehq.org/patch.py?id=13475
Among other things this patch changes wine/dlls/Makefile.in wine/configure.ac wine/configure
it also changes itss.dll. However, my symptoms still persist whether I use a native or builtin version of itss. I include this information because I don't know if the symptoms are separate problems or are related.
I am not able to pin point the cause of Symptom 1 because I do not yet know how to update my repository to do a regression. I must wait for the archive after the October snapshot.
I have reasoned, since I can get IE6 to work completely using a ~/.wine created before that August commit, that the problem lies somewhere in the "fake windows" directory. There are differences in the registry, win.ini and system.ini files, but I do not know how to diagnose them.
The following excerpt, from one of the logs I created, shows that there is a completely different sequence, between the working and non-working situations, when shell32 loads for the first time:
trace:loaddll:load_dll Loaded module L"c:\windows\system\shell32.dll" : builtin -trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\windows\system\shell32.dll" : builtin -trace:loaddll:load_dll Loaded module L"c:\windows\system\shell32.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\windows\system\ole32.dll" : native trace:loaddll:load_dll Loaded module L"C:\windows\system\BROWSEUI.dll" : native err:shell:ReadCabinetState Initializing shell cabinet settings trace:loaddll:load_dll Loaded module L"C:\windows\system\browselc.dll" : native -trace:loaddll:load_dll Loaded module L"C:\windows\system\RPCRT4.DLL" : native +trace:loaddll:load_dll Loaded module L"C:\windows\system\shdoclc.dll" : native +err:rebar:REBAR_WindowProc unknown msg 200b wp=00000000 lp=71180f00 +trace:loaddll:load_dll Loaded module L"c:\windows\system\uxtheme.dll" : builtin +trace:loaddll:load_dll Loaded module L"C:\windows\system\RPCRT4.dll" : native +trace:loaddll:load_dll Loaded module L"c:\windows\system\lz32.dll" : builtin +trace:loaddll:load_dll Loaded module L"c:\windows\system\version.dll" : builtin +trace:loaddll:load_dll Loaded module L"C:\windows\system\urlmon.dll" : native trace:loaddll:load_dll Loaded module L"C:\windows\system\MSOSS.dll" : native trace:loaddll:load_dll Loaded module L"C:\windows\system\CRYPT32.dll" : native trace:loaddll:load_dll Loaded module L"C:\windows\system\OLEAUT32.dll" : native trace:loaddll:load_dll Loaded module L"C:\windows\system\WININET.dll" : native
I stopped the excerpt here because this is the point at which the non-working situation exits. I have generated a log from +relay "grepped" for shell32 but do not know how to interpret it to see if I can glean any more information. This log and all the others are contained in the tarball that I have attached. It creates a directory called "wine-trouble" and contains all the information that I have generated. The README contains specifics of what I have done.
As I was composing the README for inclusion here, I realized that I had not done two things. I forgot to copy shell and shell32 to my fake windows directory so that all of my tests were conducted with builtin shell and shell32. Additionally, I have not run wine compiled before the August commit with a fake windows created on October 13. I will do both of these and see if I get differenet results.
I'm really interested in resolving this and would rather that I had been able to supply better information. However, my knowlege of winedbg, windows and cvs does not currently allow me to proceed further. If anyone wants me to do more, I would appreciate being pointed in the right direction, but I will need some specifics.
I have found no documentation on any of the wine mailing lists or other forums to indicate that anyone else is having this problem. It could be something that I am doing. This is why I haven't yet submitted a bug report. If a bug report would be more appropriate, I will do that.
Thanks, Dan