It was always called with source parameter set to TRUE.
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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 036f007e24 (which reverts
86bc556f9f) 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 e1e668d41f.
Signed-off-by: Hans Leidekker <hans@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Hans Leidekker