Status of MSI

[Mike McCormack]

Hi All,

I've completed the merge of the work Aric and I have done to date on 
MSI.  Some programs that use and do not package the MSI installer may 
start to work.  We still have no implementation of msiexec.exe, so there 
is still no method to install .msi files directly, however not all MSI 
based installs require msiexec.exe.  (It's fairly easy to implement if 
anybody wishes to volunteer...)

Consider adding "msi" = "native, builtin" to your Wine configuration 
files, and not installing the MSI redistributables straight away when 
you encounter an installer that uses msi.dll :)  Let us know what bugs 
that turns up.

thanks,

Mike

[Michael Stefaniuc]

Hi Mike,

how much of msi.dll do you think is now implemented?
For http://www.winehq.org/site/status_dlls

bye
    michael

On Sat, Jul 10, 2004 at 01:15:16PM -0500, Mike McCormack wrote:
> I've completed the merge of the work Aric and I have done to date on 
> MSI.  Some programs that use and do not package the MSI installer may 
> start to work.  We still have no implementation of msiexec.exe, so there 
> is still no method to install .msi files directly, however not all MSI 
> based installs require msiexec.exe.  (It's fairly easy to implement if 
> anybody wishes to volunteer...)
>
> Consider adding "msi" = "native, builtin" to your Wine configuration 
> files, and not installing the MSI redistributables straight away when 
> you encounter an installer that uses msi.dll :)  Let us know what bugs 
> that turns up.

[Mike McCormack]

Michael Stefaniuc wrote:
> how much of msi.dll do you think is now implemented?

About 40%, I'd guess.

Mike

[Tom]

Mike McCormack wrote:
> Michael Stefaniuc wrote:
> > how much of msi.dll do you think is now implemented?
>
> About 40%, I'd guess.
>
> Mike

Nice, I plan to update the status pages in the next week or so.
I'll change it to 40% and list both Aric and Mike as workers.

Tom

[Vincent Béron]

Le sam 10/07/2004 à 14:15, Mike McCormack a écrit :
> Hi All,
>
> I've completed the merge of the work Aric and I have done to date on 
> MSI.  Some programs that use and do not package the MSI installer may 
> start to work.  We still have no implementation of msiexec.exe, so there 
> is still no method to install .msi files directly, however not all MSI 
> based installs require msiexec.exe.  (It's fairly easy to implement if 
> anybody wishes to volunteer...)

I do volunteer.

Vincent

[Mike Hearn]

On Sat, 10 Jul 2004 13:15:16 -0500, Mike McCormack wrote:
> Consider adding "msi" = "native, builtin" to your Wine configuration 
> files, and not installing the MSI redistributables straight away when 
> you encounter an installer that uses msi.dll :)  Let us know what bugs 
> that turns up.

Random thought: we really need a better way to manage default DLL
overrides. We want to use native,builtin for DLLs in our tree that are
little more than stubs and need a big push to get them off the ground, and
builtin,native for DLLs like MSI which are good enough to go into
production.

Asking people to manually fiddle with their config on wine-devel really
isn't a good way to do this.

We already have a hard coded list that we can use for this, but last time
I tried to change it Alexandre said it was only for things like user,
ntdll and so on. Is that a good policy?

thanks -mike

[Hans Leidekker]

On Saturday 10 July 2004 20:15, Mike McCormack wrote:
> Consider adding "msi" = "native, builtin" to your Wine configuration 
> files, and not installing the MSI redistributables straight away when 
> you encounter an installer that uses msi.dll :)  Let us know what bugs 
> that turns up.

When I do this:

WINEDEBUG="trace+msi" WINEDLLOVERRIDES="msi=b" wine msiexec /i tippfix.msi

msi seems to loop endlessly. These are the first lines of the trace. Notice
the second line showing a single space command line string:

trace:msi:MsiSetInternalUI 00000005 (nil)
 trace:msi:MsiInstallProductA "tippfix.msi" " "
 fixme:msi:MsiInstallProductW L"tippfix.msi" L" "
 trace:msi:MsiVerifyPackageW L"tippfix.msi"
 trace:msi:MsiOpenDatabaseW L"tippfix.msi" (null) 0x197fe6ac
 trace:msi:MSI_OpenDatabaseW L"tippfix.msi" (null)

Later, when the command line is searched for property/value pairs, the trace
shows this:

trace:msi:ACTION_DoTopLevelINSTALL Looking at L" "
 trace:msi:ACTION_DoTopLevelINSTALL Found commandline property (L"\ffff\ffff") = (L"\deb0\197f\5ce6\1aa0\0f00\4fcc\87c7
 \1aa0\dea4\197fC\197f\87ec\1aa0\dea4\197f")
 trace:msi:MSI_SetPropertyW Setting property (L"\ffff\ffff" L"\deb0\197f\5ce6\1aa0\0f00\4fcc\87c7\1aa0\dea4\197fC\197f\
 87ec\1aa0\dea4\197f")
 trace:msi:MSI_DatabaseOpenViewW L"select Value from _Property where _Property=`\ffff\ffff`" 0x197fcbc8

Clear signs of uninitialised memory being used. The patch below fixes this
and also strips any leading whitespace off the property name.

-Hans

Changelog:
  Fix command line parsing.