-----Original Message----- From: wine-devel-admin@winehq.org [mailto:wine-devel-admin@winehq.org]On Behalf Of Andreas Rosenberg Sent: 04 December 2003 18:21 To: wine-devel@winehq.com Subject: Status of InstallShield-Setup Engine
Hi!
Hi!
I'm new to this list. The company I'm working for, is developing software for Windows and as a personal Linux fan I was testing our software with Wine from time to time. The last tries (several month ago) were still pretting bad, but with the Wine from Suse 9.0 (snapshot from August 2003) there were only "trivial" errors (mostly conformance) which we were able to circumwent in our software.
I'm glad to here that we have improved that much.
I tracked all problems and reported them als bugs: (1844, 1845, 1847, 1848) together with a patch for two of them.
They all look like valid bugs and the solutions you have proposed for each one look sane (although I haven't looked at the source of the functions affected). You should make a patch for each one and submit them all to wine-patches, where they will be reviewed.
We have a customer, who already asked for a version of our software being able to run on Linux. What's seems to be a big problem, is the InstallShield Setup Engine we are using (like many others). A played around with it and it crashed in different ways. I looked into the bug list and found the rather old "meta bug" #170. Unfortunately the link inside is broken.
There is a lack of lack of detail in that bug. I believe there is at least one bug with a lot of detail on the subject.
Perhaps we can contribute in making the InstallShield Setup Engine work. Has anybody tracked what's causing the problem?
I belive that it is our lack of proper ThreadingModel support in COM. We currently ignore the registry parameter HKCU\CLSID{GUID}\InprocServer32\ThreadingModel. I believe we do that right thing in the case of that value being Apartment and the application calling CoInitializeEx(NULL,COINIT_APARTMENTTHREADED). However, we don't do the right thing in any of the other combination of flags. I belive the right course of action is to use stubless proxies to marshal the interface across boundaries in certain cases. These cases are listed in the books "Inside OLE" and "Inside DCOM" by Microsoft Press. Our Local Server COM also leaves a lot to be desired but that may or may not be needed for InstallShield.
I read about "global window handles", but this didn't gave me the right clue. Is it related with the API call FindWindow? Is the IS Setup Engine using multiple processes and trying to communicate via window messages or DDE?
I can't remember whether the FindWindow calls are crucial, but AFAIK they are just graphical issues. I.e. you will see some text missing here and there.
If anybody could point me in the right direction, this would be great. Otherwise it would be a waste of resources to debug/search stuff others already did.
If the main issues for you are with the installer I would get my hands on the book mentioned earlier "Inside DCOM" from Microsoft Press. Also, Ove Kaaven has done a lot of work on this so he may be able to help.
Regards
Andy
Rob