Status of InstallShield-Setup Engine

[Andreas Rosenberg]

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

[Dimitrie O. Paun]

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.

[Uwe Bonnes]

> > > > > "Andreas" == Andreas Rosenberg  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 [e-mail]. Perhaps state also
the license, e.g. if your patches may be reused in wineX.

Bye

[Robert Shearman]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Andreas Rosenberg
> Sent: 04 December 2003 18:21
> To: [e-mail]
> 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

[Mike Hearn]

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).

[Mike Hearn]

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