As of 3a884c2ef the server is started on the main thread, so this is no
longer a valid assumption. In particular, we disable WoW64 redirection while
running standard actions, including the top-level INSTALL action.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45663
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is unnecessary, and may have always been so. The struct will either be
freed after it completes synchronously, or after it has completed
asynchronously in ACTION_FinishCustomActions().
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Asynchronous custom actions don't wait for custom_client_thread() to
terminate, so it's possible for two consecutive actions to both try to start
the server at once, causing failures when the second action e.g. receives
ERROR_PIPE_BUSY from CreateNamedPipe().
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We use a named pipe to communicate between the client (i.e. the process that
called MsiInstallProduct() and the custom action server. The naïve approach
has the client send custom action GUIDs to the server and the server send
back the results of executing the action, but this fails in the case of
nested custom actions, so instead we send back handles of threads for the
client to wait on.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is a no-op as is, but is necessary as of the next patch in the case of
nested custom actions.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This patch is effectively a no-op by itself, but makes the next patch
architecturally much simpler. We need the main thread to be non-blocking
to allow nested custom actions to work, so creating the thread inside of
msiexec allows the custom action thread to write the result of the action to
the server pipe while the main thread simply reads from it.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This has no effect anymore, and won't work if the architecture doesn't match.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The bitness depends solely on the bitness of the DLL (tested manually).
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Commit 036f007e241b95498964c53365300a3332a92c5a (which reverts
86bc556f9fd4a964cbaa66bc1fd67e4603ecd450) is not sufficient to
fix the Office installers because MsiGetMode(MSIRUNMODE_SCHEDULED)
no longer does the right thing after the revert.
That is caused by "msi: Store the current script in the package.",
which, in hindsight, should have been part of the first commit.
This reverts e1e668d41fce1dbd0270cd9de0d880a236ddb869.
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
