[Bug 8945] Adobe Indesign CS3 and Photoshop CS3 fail to install

http://bugs.winehq.org/show_bug.cgi?id=8945

--- Comment #21 from Jeremy White   2008-02-04 20:48:43 ---
I've spent a fairly substantial amount of time looking into the current
Photoshop CS3 installer failure, all with no joy to this point.

So, current results (as of 1/31/2008) are that with wsh56js and msxml3
installed, you get a rapid failure of the installer.  You get a child process
that exits with an error code 4.

Sometimes you also get a 'This installer is already running' message which
appears to be a timing bug, most probably in the Installer itself.  That is,
the sequence is something like 
   Process 1:  CreateMutex(xxx), MsiInstall(yyy), ReleaseMutex(xxx).
   Process 2:  If (CreateMutex(xxx) fails) put up error dialog
The catch being that Process 2 is started by the MsiInstal(yyy) process.  I
suspect that Wine may be releasing that process too early, but James is
skeptical, and even if I game the situation, I only reduce the frequency of
failure; I don't eliminate it.

However, that's a bit of a side show.  The core failure appears to be the exit
with error code 4.  From studying Windows behavior, the default behavior is
supposed to be something like this:

User clicks on Autorun, autorun.exe starts
  User clicks on 'Install Photoshop CS3'
  Autorun.exe starts <cdrom>/Adobe CS3/Setup.exe
  That copy of Setup.exe runs and invokes 
    MsiInstall(<cdrom>/.../WinBootstrapped.msgi)
    That MsiInstall makes a 
      c:\program files\common files\adobe\installers\
      2ac...\
    directory.
    That directory contains a subset of the files from the
    CD including a bit for bit identical copy of Setup.exe.
  A part of the MsiInstall() includes a type 34 handler, which
    results in an invocation like this:
      ...\2ac...\Setup.exe --ExitWorkflow="0" --BootstrappedLaunched=1
         --record=""
  Note that this is a bit confusing, as there are two copies of
  Setup.exe running; both bit for bit identical to one another.
  However, one is started from the CD rom without parameters, and
  the other is started from the newly created directory on C:
  and has the parameters above.

Eventually, the second setup.exe tests for the existence of
  WinBootstrapped.msi, which doesn't exist, and then quickly thereafter does an
  ExitProcess(4).

My current best hunch is that there is some IPC mechanism used to signal
the second 'child' setup.exe process that it is in fact a child, and that
causes it to branch down a different path of execution than the first
process.  However, I can find no Mutex or any other IPC that is obvious.

Interestingly, if you experiment on Windows, you can create both
the exit code 4 condition as well as a success case.  
That is, if you start the setup, and then while it's on the EULA
screen, you kill the process.  Then, tarball the 2ac... directory.
Then, start setup.exe --ExitWorkflow (etc) by hand, and it will work.

Then let it run, cancel the EULA (which cleans up), untar the
2ac... directory, and try again, and you'll get the error code 4.

This may be as simple as the Adobe installer relying on some temporary
files or registry settings that are set by the Windows MSI that Wine does not
set.

I'm continuing to explore this and hope to eventually lick it, but it's a back
breaker.