Wine 1.1.20 crashes while installing Photoshop CS4

This commit make the installer fail when it's starting.

b8965ee7c90a687af4c84ad0ede73b1df901e16c is first bad commit
commit b8965ee7c90a687af4c84ad0ede73b1df901e16c
Author: Hans Leidekker <email address hidden>
Date: Tue Mar 24 10:26:24 2009 +0100

    msi: Don't initialize COM for custom action threads.

:040000 040000 e3395252ab46bf3c623252deb94ceba713c0596a 7e7d74822b91c0a5981893f375a05c22bb144360 M dlls

Adding Hans to the bug.

Please attach a +msi,+msidb trace.

Created an attachment (id=20480)
Console Output

I'd like to see a +msi,+relay,+seh trace. Custom actions execute
arbitrary code, so +msi may not reveal enough information.

The +msi,+relay,+seh trace was more than 1 MB so I upload it to RapidShare.

The link is: http://rapidshare.com/files/222695971/log.txt.tar.bz2.html

Hello,

well the custom action thread tries to use MSXML6 COM inproc server and fails because there is no apartment (COM not initialized).
There are basically two problems here.
One part (reuse of existing MTA) is covered by my bug 17902 though CoGetClassObject() is the culprit there.

As for the other part, I found the following blog containing useful information regarding custom actions and COM: http://blogs.msdn.com/astebner/archive/2005/02/07/368917.aspx

--- quote ---
...
This question rang a bell so I dug into some of the emails that have gone across our internal Windows Installer question-n-answer alias and here is the official answer from the Windows Installer team:

"One of the first things that a custom action server does when it is created is to call CoInitializeEx(0, COINIT_MULTITHREADED).

However, the thread on which a DLL custom action is run is different from the main thread (on which COM is initialized) and COM will not be initialized on it. It is up to the custom action to initialize COM to its liking."
--- quote ---

Because the custom action thread which executes "Adobe_ProcessPropertyFile" CA doesn't initialize COM explicitly (not creating apartment), the MTA from the main thread has to be used.

The problem is: there is no custom action server the blog talks about here which does this.
Msi will be called in the context of installer threads which might have or have not initialized COM in various ways.

One solution could be to have Wine's Msi create a dedicated thread serving as "fake" CA server main thread which creates an MTA if not already exist by calling CoInitializeEx(NULL, COINIT_MULTITHREADED).
All custom action threads that don't explicitly initialize COM would be then part of that MTA (which is guaranteed to be an MTA, not relying on installer STA threads).

Regards

Hello,

although Hans implemented reuse of existing MTA part now (commit bd4975acb0b682bbf2b4934d12f942ea629f5bbb) which fixes my bug 17902 *g* this still might not be enough for Adobe and possibly other installers.

Wine needs to ensure there _is_ an MTA present for CA's
If the app installer only consists of single threaded apartments or the installer didn't initialize COM at all, custom actions will still fail.
An indication might be messages like that:

--- snip ---
err:ole:CoCreateInstance apartment not initialised
...
err:msi:ITERATE_Actions Execution halted, action "foo" returned "bar"
--- snip ---

Maybe you can take up my suggestion about creating an msi (internal) thread solely for the purpose of ensuring MTA present which CA's can reuse.
Don't use the app/installer own threads to initialize the COM MTA, it would backfire when the app later decides to initialize COM with a different model (STA).

Regards

*** Bug 18228 has been marked as a duplicate of this bug. ***

*** This bug has been confirmed by popular vote. ***

*** Bug 17070 has been marked as a duplicate of this bug. ***

Good analysis, affects many apps, key subsystem -> nominating for 1.s

*** Bug 16795 has been marked as a duplicate of this bug. ***

When will this error been fixed?

I have now, not been able to install Photoshop CS4 from wine-1.1.18 to wine-1.1.22 how many versions do you think of coming before it gets fixed?

(In reply to comment #13)
> When will this error been fixed?
> I have now, not been able to install Photoshop CS4 from wine-1.1.18 to
> wine-1.1.22 how many versions do you think of coming before it gets fixed?

Feel free to send patches.

(In reply to comment #13)
> When will this error been fixed?

Not repeating the somewhat acidulous "feel free to send patches"-comment of Dmitry, it seems to have been nominated to be done before the next major stable release, which would be 1.2.
Hopefully, a solution will be available in earlier releases.

Thing is that this does not seem to be simply a bug, but also a design issue, which makes it a bit bigger.

*** Bug 18938 has been marked as a duplicate of this bug. ***

Making title more generic, reported to affect all CS3/CS4 applications.

Patch sent, http://www.winehq.org/pipermail/wine-patches/2009-June/074531.html
I just typed it in and only very lightly tested it, but it seems to
work. At the very least it demonstrates that Anastasius was on target as usual.

thank you, this patch worked for me!
my wine version is 1.1.24

sory but for cs3 installer failed with "Critical errors were found in setup. Please see the Setup log file for details.
log file
...
Using cached language set
HTML data complete: personalization
Using cached language set
[ 44] Mon Jun 22 23:10:56 2009 FATAL
Critical errors were found in setup
Please see the Setup log file for details.
[ 44] Mon Jun 22 23:10:58 2009 INFO
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
END - Installer Session
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*

and cs4 installer failed with

Error message: Adobe Anchor Service CS4

Error 1603

*** Bug 19057 has been marked as a duplicate of this bug. ***

So is commit b8965ee7c90a687af4c84ad0ede73b1df901e16c a bad commit? or is it a step in the right direction it just breaks some installers currently?

It was probably a correct change that exposed a problem. It's probably a week's worth of work to fix the newly exposed problem correctly. Don't know for sure yet if Alexandre will insist on that, or if he'll accept something like my easy workaround patch (suitable improved).

At lest the reason was finally found :]
Looking forward to seeing a fix/workaround soon.

> So is commit b8965ee7c90a687af4c84ad0ede73b1df901e16c a bad commit?
> or is it a step in the right direction it just breaks some installers
> currently?

It's a step in the right direction. Before that commit office 2007
service pack 1 and other installers would fail because of custom
actions with conflicting demands for COM initialization.

FWIW, I think an improved version of Dan's patch would be acceptable,
after testing with some more installers. MS installers are good
candidates since they seem to consistently check the result of
CoInitialize().

(In reply to comment #26)
> FWIW, I think an improved version of Dan's patch would be acceptable,
> after testing with some more installers. MS installers are good
> candidates since they seem to consistently check the result of
> CoInitialize().

I'd be happy to run my application test suite on any candidate patches..

Hello,

you need to put more love into it else nothing will happen and people will suffer for a long time.
Sure, any solution that creates MTA helper thread within app process remains sort of a hack until Wine Msi can roll its own custom action server.

As already said: avoid using DllMain for dedicated threads.
Ideal would be a place where one can control the startup and shutdown of MTA helper thread within same function scope while avoiding/minimizing the need for recreation it due to multiple custom actions.

Have a look at MSI_InstallPackage. All applicable custom actions are run from within that entry.
MTA helper thread creation should be done before any ACTION_ProcessExecSequence().
MTA helper thread shutdown should be done after ACTION_FinishCustomActions() to ensure deferred/pending custom actions have ended.
Use event signalling not only for shutdown but also for startup to prevent possible race condition between threads, ensuring CoInitializeEx() is called from MTA helper thread before any custom action is run.

Regards

Created an attachment (id=22139)
msi: Start a dummy thread to initialize an MTA.

Here's an improved version of Dan's patch. Please test.

Works for me, thanks.

How do we apply this patch? sorry patch newb...

(In reply to comment #31)
> How do we apply this patch? sorry patch newb...

http://wiki.winehq.org/Patching

Our FAQ didn't answer that question, so I added it:
http://wiki.winehq.org/FAQ#head-7ed3c3163e2b932ee2030a48f9c5e553dc41817b

i have the msi: Start a dummy thread to initialize an MTA patch tested. This is worked in 64 bit ubunutu jaunty. Thanks

(In reply to comment #29)
> Created an attachment (id=22139) [details]
> msi: Start a dummy thread to initialize an MTA.
>
> Here's an improved version of Dan's patch. Please test.

http://austinenglish.com/logs/appinstall-bug_18070_test/

Works fine for all the programs currently being tested.

On my gentoo x86_64 system, patching 1.1.25 with Hans' patch allows me to get farther in the Photoshop CS3 installer. I then run into bug 15590 but if I use Hans' workaround of bringing down all interfaces, I'm able to install completely. Thanks Hans!

I see 1.5.31 is available for testing, and this bug is still sticking it's ugly little head up and I'm not sure if the patch mentioned in comment #73 will work on 1.5. How's the progress looking for a more permanent fix?

Created attachment 45275
msi: Start a dummy thread to initialize an MTA (wine-1.6-rc5)

Still present, obviously.

Patch rebased to wine-1.6-rc5 works for me.

Note: We don't need any more console output or confirmation until a developer asks for it. This bug is well known.

I think this bug prevents any Adobe application from installing in fact (at least Acrobat XI). I can't believe such a nuisance is still there 5 years after being reported, with patches posted right here, without a dev taking a look at it?!

I think most Wine users would better have this fixed to be able to install the few major Windows software unmatched in Linux, rather than have DX10 fully implemented (which is for sure by far more complicated than this!).

Or maybe this bug is rooted deeper than it seems and a proper fix would need a huge rework? Anyway with a bug still being marked NEW after 5 years, hard to tell...

Corax made good point. To summarize:
- very old bug,
- blocks many other bugs (and thus applications),
- many observers,
- some patches already present.

Nevertheless no progress since long time.

Commenting on a bug is easy, coding is not. Wishing for the bug to be fixed doesn't make the work magically done.

The problem is known, and it's a lot of work to do. Patches are welcome (as with all bugs..).

Might I remind everyone that is following this bug something that has been said countless times:

[QUOTE]Anastasius Focht 2009-08-09 04:20:40 CDT

Hello,

there is no need to provide test data.
The problem is well known and a short-term hack-patch exists which was consequently rejected by AJ.

Until someone takes up the task to implement "remote" custom actions (custom action server) you'll have to use the hack-patch.

Unfortunately this whole bug is now messed up with many useless/irritating comments that have nothing to do with the original bug.

Regards
[/QUOTE]

Thank you

(In reply to Ken Sharp from comment #108)
> Created attachment 45275 [details]
> msi: Start a dummy thread to initialize an MTA (wine-1.6-rc5)
>
> Still present, obviously.
>
> Patch rebased to wine-1.6-rc5 works for me.
>
> Note: We don't need any more console output or confirmation until a
> developer asks for it. This bug is well known.

How well will this patch work with the 1.7x branch?

Hello folks,

adding another "test-case", 'Windows Live ID Sign-in Assistant 6.5' required for newer GFWL (Games For Windows Live) 3.x clients.

Download: https://www.microsoft.com/en-us/download/confirmation.aspx?id=15106

COM is not initialized in any main/CA thread hence the failure of 'ole32.CoCreateInstance' in CA thread.

--- snip ---
$ WINEDEBUG=+tid,+seh,+relay,+msi wine msiexec -i wllogin_32.msi >>log.txt 2>&1
...
002b:trace:msi:HANDLE_CustomType1 Calling function L"CAPerformMUOptin" from L"C:\\users\\focht\\Temp\\msid8c6.tmp"
...
002b:Call KERNEL32.CreateThread(00000000,00000000,7ecf3c96,001b18a4,00000000,00000000) ret=7ecf3eab
002b:Ret KERNEL32.CreateThread() retval=000000a8 ret=7ecf3eab
002b:trace:msi:wait_thread_handle waiting for L"CAPerformMUOptIn"
...
002d:Starting thread proc 0x7ecf3c96 (arg=0x1b18a4)
002d:trace:msi:DllThread custom action (2d) started
002d:trace:msi:ACTION_CallDllFunction {ef9499af-7bcd-4aac-ad13-ebfa5220026c}
002d:trace:msi:DllGetClassObject {ba26e6fa-4f27-4f56-953a-3f90272018aa} {00000001-0000-0000-c000-000000000046} 0x9ce854
002d:trace:msi:MsiCF_CreateInstance 0x7edda178 (nil) {56d58b64-8780-4c22-a8bc-8b0b29e4a9f8} 0x9ce850
...
002d:Call KERNEL32.LoadLibraryW(00b28f4c L"C:\\users\\focht\\Temp\\msid8c6.tmp") ret=7ecf3907
002d:Ret KERNEL32.LoadLibraryW() retval=00d10000 ret=7ecf3907
...
002d:trace:msi:ACTION_CallDllFunction calling L"CAPerformMUOptin"
...
002d:Call ole32.CoCreateInstance(00d112d0,00000000,00000001,00d112b0,009ce830) ret=00d16c7c
002d:Call ntdll.RtlAllocateHeap(00110000,00000008,000000fc) ret=7eac6d64
002d:Ret ntdll.RtlAllocateHeap() retval=001edfe8 ret=7eac6d64
002d:err:ole:CoCreateInstance apartment not initialised
002d:Ret ole32.CoCreateInstance() retval=800401f0 ret=00d16c7c
...
002d:Call msi.MsiRecordSetStringW(00000003,00000000,001ee138 L"PPMSI_ERROR: CAPerformMUOptin: Could not Check for MU opt in. nReturn = -2147221008") ret=00d14d35
...
002d:trace:msi:DllThread custom action (2d) returned -2147221008
...
002b:err:msi:ITERATE_Actions Execution halted, action L"CAPerformMUOptIn" returned 1603
--- snip ---

$ sha1sum wllogin_32.msi
f477f8abc4519532ef2921b1343a06f2ac546c2c wllogin_32.msi

$ du -sh wllogin_32.msi
4.5M wllogin_32.msi

$ wine --version
wine-1.7.19-71-g94ccd61

Regards

Hello folks,

while visiting bug 16940 I made a trace log with 'Adobe Indesign CS4'.

There is nothing new, just for getting more search engine hits... so please ignore :)

--- snip ---
...
002a:Ret PE DLL (proc=0x100dc2c6,module=0x10000000 L"msid91c.tmp",reason=THREAD_ATTACH,res=(nil)) retval=1
002a:Starting thread proc 0x7be18b2a (arg=0x29e89b4)
002a:trace:msi:DllThread custom action (2a) started
002a:trace:msi:ACTION_CallDllFunction {a18ece91-2e21-4d3f-b36d-92bfac358582}
...
002a:trace:msi:ACTION_CallDllFunction calling L"Adobe_ProcessPropertyFile"
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b4a1bf0 L"19:58:17:970 -(Adobe)- -*-*-*-*-*-*-*-*-*-*-*-*- BEGIN - Adobe_ProcessPropertyFile -*-*-*-*-*-*-*-*-*-*-*-*- ") ret=10010ecc
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b49e048 L"19:58:17:971 -(Adobe)- Requesting property: PROPERTY_FILE ") ret=10002eac
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b4a1b10 L"19:58:17:973 -(Adobe)- Value C:\\users\\focht\\Temp\\adbd633.tmp ") ret=10002eac
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b49e048 L"19:58:17:974 -(Adobe)- Processing property file ") ret=10002eac
...
002a:Call ole32.CLSIDFromProgID(0b49e2a0 L"MSXML2.DOMDocument.6.0",0b79e054) ret=100909f1
...
002a:Ret ole32.CLSIDFromProgID() retval=00000000 ret=100909f1
002a:Call ole32.CoCreateInstance(0b79e054,00000000,00000017,1014c6d4,0b4971f0) ret=10090a15
...
002a:err:ole:CoCreateInstance apartment not initialised
002a:Ret ole32.CoCreateInstance() retval=800401f0 ret=10090a15
002a:Call ole32.CLSIDFromProgID(0b49de90 L"MSXML2.DOMDocument.5.0",0b79e054) ret=100909f1
...
002a:Ret ole32.CLSIDFromProgID() retval=800401f3 ret=100909f1
002a:Call ole32.CLSIDFromProgID(0b49e118 L"MSXML2.DOMDocument.4.0",0b79e054) ret=100909f1
...
002a:Ret ole32.CLSIDFromProgID() retval=00000000 ret=100909f1
002a:Call ole32.CoCreateInstance(0b79e054,00000000,00000017,1014c6d4,0b4971f0) ret=10090a15
002a:err:ole:CoCreateInstance apartment not initialised
002a:Ret ole32.CoCreateInstance() retval=800401f0 ret=10090a15
002a:Call ole32.CLSIDFromProgID(0b4a19b8 L"MSXML2.DOMDocument.3.0",0b79e054) ret=100909f1
...
002a:Call ole32.CoCreateInstance(0b79e054,00000000,00000017,1014c6d4,0b4971f0) ret=10090a15
...
002a:err:ole:CoCreateInstance apartment not initialised
002a:Ret ole32.CoCreateInstance() retval=800401f0 ret=10090a15
002a:Call ole32.CLSIDFromProgID(0b4a19f0 L"MSXML.DOMDocument",0b79e054) ret=100909f1
...
002a:Call ole32.CoCreateInstance(0b79e054,00000000,00000017,1014c6d4,0b4971f0) ret=10090a15
...
002a:err:ole:CoCreateInstance apartment not initialised
002a:Ret ole32.CoCreateInstance() retval=800401f0 ret=10090a15
...
002a:Call msi.MsiRecordSetStringW(00000003,00000000,0b4a19c0 L"19:58:17:976 -(Adobe)- Unable to load file: C:\\users\\focht\\Temp\\adbd633.tmp ") ret=10002eac
...
002a:Call msi.MsiRecordSetStringW(00000004,00000000,0b49e048 L"19:58:18:111 -(Adobe)- #_AdobeError_# 1603 ") ret=100114b7
...
002a:trace:msi:MsiCloseHandle 1
002a:trace:msi:DllThread custom action (2a) returned 1603
002a:trace:msi:MsiCloseAllHandles
002a:trace:msi:MsiCloseHandle 3
002a:t...

Created attachment 49557
msi: Start a dummy thread to initialize an MTA (wine-1.7.26)

Created attachment 50758
msi: Start a dummy thread to initialize an MTA (wine-1.7.36)

Adobe Premiere Pro CS3 installer works fine with the patch from comment #73 applied to Wine 1.7.36 (see attachment). However, winetricks stuff which is still necessarily required (msxml3 msxml6 ie6 vcrun6).

*OT* You can also run Adobe Premiere Pro CS3 with Wine 1.7.36. There's serious GUI issues, though (Bug 38073). *OT*

*** Bug 40278 has been marked as a duplicate of this bug. ***

Created attachment 53943
Patch for running dummy MSI thread, updated for wine 1.9.5

action.c Patch for running dummy MSI thread, updated for wine 1.9.5

Could the dummy MSI thread patch at least get put in Staging?

Created attachment 58400
action.c Patch for running dummy MSI thread, updated for wine 2.10

I don't know if anybody still cares, but this patch works on wine 2.10

(In reply to Seann from comment #121)
> Created attachment 58400 [details]
> action.c Patch for running dummy MSI thread, updated for wine 2.10
>
> I don't know if anybody still cares, but this patch works on wine 2.10

I still care about Fireworks. If you have some free time, please take a look at this bug to see if you can do anything about it: https://bugs.winehq.org/show_bug.cgi?id=39086

(In reply to Seann from comment #121)
> Created attachment 58400 [details]
> action.c Patch for running dummy MSI thread, updated for wine 2.10
>
> I don't know if anybody still cares, but this patch works on wine 2.10

Thanks for keeping this up-to-date.

I submitted the patch to Wine Staging: https://dev.wine-staging.com/patches/132/
Let's hope this gets accepted.

(In reply to Qwerty Chouskie from comment #123)
> (In reply to Seann from comment #121)
> > Created attachment 58400 [details]
> > action.c Patch for running dummy MSI thread, updated for wine 2.10
> >
> > I don't know if anybody still cares, but this patch works on wine 2.10
>
> Thanks for keeping this up-to-date.
>
> I submitted the patch to Wine Staging:
> https://dev.wine-staging.com/patches/132/
> Let's hope this gets accepted.

It has been accepted into Staging. Yay!

(In reply to Qwerty Chouskie from comment #124)
> (In reply to Qwerty Chouskie from comment #123)
> > (In reply to Seann from comment #121)
> > > Created attachment 58400 [details]
> > > action.c Patch for running dummy MSI thread, updated for wine 2.10
> > >
> > > I don't know if anybody still cares, but this patch works on wine 2.10
> >
> > Thanks for keeping this up-to-date.
> >
> > I submitted the patch to Wine Staging:
> > https://dev.wine-staging.com/patches/132/
> > Let's hope this gets accepted.
>
> It has been accepted into Staging. Yay!

Shouldn't the status be set to "staging" along with the accepted patchset?

(In reply to fjfrackiewicz from comment #125)
[...]
> > > I submitted the patch to Wine Staging:
> > > https://dev.wine-staging.com/patches/132/
> > > Let's hope this gets accepted.
> >
> > It has been accepted into Staging. Yay!
>
> Shouldn't the status be set to "staging" along with the accepted patchset?

The description of the patch above says it's only a workaround to make the apps work until there is a proper fix.

I can't see a policy for this in https://wiki.winehq.org/Bugs
but I assume that a bug can be marked as "fixed on staging" only if it's a proper fix, even if it hasn't been merged into the main codebase yet because it needs reviewing and some improvements.

(In reply to Giacomo Orlandi from comment #126)
> (In reply to fjfrackiewicz from comment #125)
> [...]
> > > > I submitted the patch to Wine Staging:
> > > > https://dev.wine-staging.com/patches/132/
> > > > Let's hope this gets accepted.
> > >
> > > It has been accepted into Staging. Yay!
> >
> > Shouldn't the status be set to "staging" along with the accepted patchset?
>
> The description of the patch above says it's only a workaround to make the
> apps work until there is a proper fix.
>
> I can't see a policy for this in https://wiki.winehq.org/Bugs
> but I assume that a bug can be marked as "fixed on staging" only if it's a
> proper fix, even if it hasn't been merged into the main codebase yet because
> it needs reviewing and some improvements.

That's not such an easy distinction to make. If the fix is proper, it wouldn't be in staging anyway, but in vanilla Wine.

If the bug exists in vanilla wine, but not wine-staging, it is reasonable to make the status 'STAGED'.

Side note: the staging version is less hacky than the original submission..

(In reply to Austin English from comment #127)
> (In reply to Giacomo Orlandi from comment #126)
> > (In reply to fjfrackiewicz from comment #125)
> > [...]
> > > > > I submitted the patch to Wine Staging:
> > > > > https://dev.wine-staging.com/patches/132/
> > > > > Let's hope this gets accepted.
> > > >
> > > > It has been accepted into Staging. Yay!
> > >
> > > Shouldn't the status be set to "staging" along with the accepted patchset?
> >
> > The description of the patch above says it's only a workaround to make the
> > apps work until there is a proper fix.
> >
> > I can't see a policy for this in https://wiki.winehq.org/Bugs
> > but I assume that a bug can be marked as "fixed on staging" only if it's a
> > proper fix, even if it hasn't been merged into the main codebase yet because
> > it needs reviewing and some improvements.
>
> That's not such an easy distinction to make. If the fix is proper, it
> wouldn't be in staging anyway, but in vanilla Wine.
>
> If the bug exists in vanilla wine, but not wine-staging, it is reasonable to
> make the status 'STAGED'.
>
> Side note: the staging version is less hacky than the original submission..

The staging version looks good. I'm going to test it this weekend.

It's good to see activity in an issue related to Fireworks.

Could any of you who worked on this take a look at https://bugs.winehq.org/show_bug.cgi?id=39086 or at least mark it as confirmed? Fireworks CS6 is completely unusable because of it.

I've been looking at a proper solution for this.

We already have the MSIServer service already implemented—it just doesn't do anything yet. I think the best way to fix this is to register the IWineMsiRemote* classes in the server process with REGCLS_MULTIPLEUSE, so not much change in infrastructure at all. I see two ways of doing this: either move all of the COM objects into msiexec.exe, or add an internal function in msi.dll. I like the first one for the sake of separation, but it does mean we need an internal idl.

Any thoughts on this from anyone else?

(In reply to Zebediah Figura from comment #130)
> I've been looking at a proper solution for this.
>
> We already have the MSIServer service already implemented—it just doesn't do
> anything yet. I think the best way to fix this is to register the
> IWineMsiRemote* classes in the server process with REGCLS_MULTIPLEUSE, so
> not much change in infrastructure at all. I see two ways of doing this:
> either move all of the COM objects into msiexec.exe, or add an internal
> function in msi.dll. I like the first one for the sake of separation, but it
> does mean we need an internal idl.
>
> Any thoughts on this from anyone else?

Did you try to investigate how that's done in Windows, so you wouldn't need
to invent custom interfaces?

(In reply to Dmitry Timoshkov from comment #131)
> (In reply to Zebediah Figura from comment #130)
> > I've been looking at a proper solution for this.
> >
> > We already have the MSIServer service already implemented—it just doesn't do
> > anything yet. I think the best way to fix this is to register the
> > IWineMsiRemote* classes in the server process with REGCLS_MULTIPLEUSE, so
> > not much change in infrastructure at all. I see two ways of doing this:
> > either move all of the COM objects into msiexec.exe, or add an internal
> > function in msi.dll. I like the first one for the sake of separation, but it
> > does mean we need an internal idl.
> >
> > Any thoughts on this from anyone else?
>
> Did you try to investigate how that's done in Windows, so you wouldn't need
> to invent custom interfaces?

Windows appears to have its own set of internal interfaces, e.g. {000c101c-0000-0000-c000-000000000046} "Msi install server". We actually have an IDL for these in msi.dll, since evidently some program tries to create one. But these interfaces are all internal; we don't even know the vtbls. It would appear that this approach would be close enough to replicating that one.

(In reply to Zebediah Figura from comment #132)
> Windows appears to have its own set of internal interfaces, e.g.
> {000c101c-0000-0000-c000-000000000046} "Msi install server". We actually
> have an IDL for these in msi.dll, since evidently some program tries to
> create one. But these interfaces are all internal; we don't even know the
> vtbls. It would appear that this approach would be close enough to
> replicating that one.

Does this help?
https://www.winehq.org/pipermail/wine-cvs/2007-January/029786.html
https://msdn.microsoft.com/en-us/library/windows/desktop/aa369432(v=vs.85).aspx

(In reply to Dmitry Timoshkov from comment #133)
> Does this help?
> https://www.winehq.org/pipermail/wine-cvs/2007-January/029786.html
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa369432(v=vs.85).
> aspx

Unfortunately, no. It seems pretty clear that IInstaller & co. aren't the interfaces to the server, since they can still be created and used while the service is disabled. Rather, I suspect, the interface labeled IMsiServer (and probably also the unlabeled 000C1094) are the interfaces, and these are not documented either as coclass or IDispatch.

Actually, on further testing, it seems that the server creates a separate process to run custom DLLs, so it's not necessarily true that we need a proper implementation of the server process.

Can anyone share exactly where this patch is staged? Is it available on 3.x staging builds for example? Or 2.21?

(In reply to Andy P from comment #136)
> Can anyone share exactly where this patch is staged? Is it available on 3.x
> staging builds for example? Or 2.21?

The patch should be included in 2.x and 3.x builds since 2.12.

Thanks, Zebediah. Does that mean -staging builds from then on? Or -devel too?

(In reply to Andy P from comment #138)
> Thanks, Zebediah. Does that mean -staging builds from then on? Or -devel too?

Just staging.

Thanks, Austin.

I've not found the patch to help with the dotnet40 issues related to msi's installing only 32 bit DLLs. My suspicion is that because the Executables involved are 32 bit themselves, they are loading msiexec through 32 bit. When I manually trigger msiexec on 64 bit, the correct DLLs are loaded - but only for 64 bit... and I think there are also some important steps loaded through the .exe that I then miss in the case.

In case it helps anyone, here's the command to run msiexec manually (and work around the prompt telling you only to use setup.exe):

wine64 'msiexec' '/i' 'c:/dotnet40/netfx_Core_x64.msi' 'EXTUI=1'

Fixed by https://source.winehq.org/git/wine.git/commit/85d1fb62b321e890004bc8d0ded7a0183216c42d. Please file new bugs for further problems.

I take it this does not apply to Wine development release 3.6, so I'll have to build from a fresh git or use the patch?

(In reply to Seann from comment #142)
> I take it this does not apply to Wine development release 3.6, so I'll have
> to build from a fresh git or use the patch?

It does not apply to 3.6, but it'll be included in 3.7, which is released tomorrow.

Hello folks,

that's actually a great milestone after all the years analysing all the apps affected by this and collecting them here ;-)

*** NOTE ***

Currently it won't work because the MSI custom action server process crashes on all custom actions. See bug 45073 for details.
I hope a fix makes it in before the Wine 3.7 release - otherwise expect gazillion of bug reports.

I've tested with some smaller installers I could quickly get hold of (Windows SDK 2008) and they work as expected (after applying fix for bug 45073).

Regards

(In reply to Zebediah Figura from comment #143)
> (In reply to Seann from comment #142)
> > I take it this does not apply to Wine development release 3.6, so I'll have
> > to build from a fresh git or use the patch?
>
> It does not apply to 3.6, but it'll be included in 3.7, which is released
> tomorrow.

Excellent! Thanks for the hard work!

Closing bugs fixed in 3.7.