Status of InstallShield-Setup Engine
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 tracked all problems and reported them als bugs: (1844, 1845, 1847, 1848) together with a patch for two of them. b.t.w I'm using a different eMail account with this mailing list as with the Wine Bugzilla. 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. Perhaps we can contribute in making the InstallShield Setup Engine work. Has anybody tracked what's causing the problem? 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? 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. Regards Andy
On December 4, 2003 01:20 pm, Andreas Rosenberg wrote:
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 tracked all problems and reported them als bugs: (1844, 1845, 1847, 1848) together with a patch for two of them.
Thank you for the bug reports! However, I'm sorry to say that at the moment not too many developers monitor Bugzilla, and they go rather unnoticed. For each of them I would also post a message on wine-devel, so people can discuss them. As for patches, always post them to wine-patches if you want them integrated in the tree. Alexandre never goes looking for them in Bugzilla. -- Dimi.
"Andreas" == Andreas Rosenberg <sonix2003(a)ctf-z.de> writes:
Andreas> Hi! I'm new to this list. The company I'm working for, is Andreas> developing software for Windows and as a personal Linux fan I Andreas> was testing our software with Wine from time to time. The last Andreas> tries (several month ago) were still pretting bad, but with the Andreas> Wine from Suse 9.0 (snapshot from August 2003) there were only Andreas> "trivial" errors (mostly conformance) which we were able to Andreas> circumwent in our software. I tracked all problems and reported Andreas> them als bugs: (1844, 1845, 1847, 1848) together with a patch Andreas> for two of them. Andreas> b.t.w I'm using a different eMail account with this mailing Andreas> list as with the Wine Bugzilla. Andreas> We have a customer, who already asked for a version of our Andreas> software being able to run on Linux. What's seems to be a big Andreas> problem, is the InstallShield Setup Engine we are using (like Andreas> many others). A played around with it and it crashed in Andreas> different ways. I looked into the bug list and found the rather Andreas> old "meta bug" #170. Unfortunately the link inside is broken. Andreas> Perhaps we can contribute in making the InstallShield Setup Andreas> Engine work. Has anybody tracked what's causing the problem? I Andreas> read about "global window handles", but this didn't gave me the Andreas> right clue. Is it related with the API call FindWindow? Is the Andreas> IS Setup Engine using multiple processes and trying to Andreas> communicate via window messages or DDE? Andreas> If anybody could point me in the right direction, this would be Andreas> great. Otherwise it would be a waste of resources to Andreas> debug/search stuff others already did. IS6 is supposed to work, also with a lot of warnings and visual glitches. Be sure you have the needed values in the wine registry. Look at winedefaults.reg. Also using native Ole/com related dlls may help, but is not an option in your case. Please resend you patch to wine-patches(a)winehq.org. Perhaps state also the license, e.g. if your patches may be reused in wineX. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
-----Original Message----- From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org]On Behalf Of Andreas Rosenberg Sent: 04 December 2003 18:21 To: wine-devel(a)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
On Thu, 2003-12-04 at 20:14, Robert Shearman wrote:
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.
This mostly affects visuals I think - the last "known good" point of InstallShield on Wine was that it did work, and installed without crashing, however it looked ugly because repainting didn't work well (due to the lack of proper interthread marshalling). There have been regressions since then though, Marcus fixed one bad one lately (in-place coercion of arguments to IDispatch::Invoke).
I belive the right course of action is to use stubless proxies to marshal the interface across boundaries in certain cases.
Oves work on interthread marshalling has been X11 licensed and I produced a patch that merged it with WineHQ (and fixed a minor bugs and such). I think Mike McCormack has a copy I sent him, but I never submitted it. I need to do that sometime really.
These cases are listed in the books "Inside OLE" and "Inside DCOM" by Microsoft Press.
"Essential COM" by Don Box is another good book, but a lot of the knowledge required is available on MSDN and MSJ articles, it's just scattered all over the net (the DCOM spec is a good reference too).
On Thu, 2003-12-04 at 18:20, Andreas Rosenberg wrote:
What's seems to be a big problem, is the InstallShield Setup Engine we are using (like many others).
One obvious solution then is to not use InstallShield. NSIS works quite well in Wine. If you are shipping a Linux version for a customer, simply using native installers (like RPM or Loki Setup) would work much better. Is there a hard requirement to use InstallShield, and if so, why?
Perhaps we can contribute in making the InstallShield Setup Engine work. Has anybody tracked what's causing the problem?
InstallShield is riddled with problems. As Uwe said, it *does* work with a bit of persuasion but there have been regressions in that area lately, and every InstallShield is subtly different. Using native DCOM may help.
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?
No, most of the InstallShield problems are related to its use of OLE and DCOM internally which we only partly implement (it's huge). thanks -mike
participants (5)
-
Andreas Rosenberg -
Dimitrie O. Paun -
Mike Hearn -
Robert Shearman -
Uwe Bonnes