Version 1.5 and up no longer work in Wine

[jethrogb]

With lessmsi 1.4:

$ wine lessmsi.exe x pkg.msi 
fixme:mscoree:CLRMetaHost_GetRuntime Unrecognized version L"v4.0"
fixme:mscoree:CLRMetaHost_GetRuntime Unrecognized version L"v4.5"
Extracting 'Z:\...\pkg.msi' to 'Z:\...\pkg'.
fixme:ver:GetCurrentPackageId (0x32f6d8 (nil)): stub

(success) With lessmsi 1.5, 1.5.1, 1.6:

$ wine lessmsi.exe x pkg.msi 
fixme:mscoree:CLRMetaHost_GetRuntime Unrecognized version L"v4.0"
fixme:mscoree:CLRMetaHost_GetRuntime Unrecognized version L"v4.5"
Extracting 'Z:\...\pkg.msi' to 'Z:\...\pkg'.
fixme:advapi:EventRegister {5eec90ab-c022-44b2-a5dd-fd716a222a15}, 0x1c01123, 0x1c2a070, 0x1c2a088
fopen error:13

Error: System.Exception: Failed to open cabinet. Last error:MSPACK_ERR_OPEN
  at LibMSPackN.MSCabinet..ctor (System.String cabinetFilename) [0x00000] in <filename unknown>:0 
  at LessMsi.Msi.Wixtracts.MergeCabs (IList`1 cabInfos) [0x00000] in <filename unknown>:0 
  at LessMsi.Msi.Wixtracts.ExtractFiles (Path msi, System.String outputDir, LessMsi.Msi.MsiFile[] filesToExtract, System.AsyncCallback progressCallback) [0x00000] in <filename unknown>:0 
  at LessMsi.Msi.Wixtracts.ExtractFiles (Path msi, System.String outputDir, System.String[] fileNamesToExtract) [0x00000] in <filename unknown>:0 
  at LessMsi.Cli.Program.DoExtraction (System.String msiFileName, System.String outDirName, System.Collections.Generic.List`1 filesToExtract) [0x00000] in <filename unknown>:0 
  at LessMsi.Cli.ExtractCommand.Run (System.Collections.Generic.List`1 allArgs) [0x00000] in <filename unknown>:0 
  at LessMsi.Cli.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0 

Usage:
lessmsi <command> [options] <msi_name> [<path_to_extract\>] [file_names]

Commands:
  x  Extracts all or specified files from the specified msi_name.	
  l  Lists the contents of the specified msi table as CSV to stdout. Table is
     specified with -t switch. Example: lessmsi l -t Component c:\foo.msi
  v  Lists the value of the ProductVersion Property in the msi 
     (typically this is the version of the MSI).
  o  Opens the specified msi_name in the GUI.
  h  Shows this help page.

For more information see http://lessmsi.activescott.com

fixme:advapi:EventUnregister deadbeef: stub
fixme:advapi:EventUnregister 0: stub

(failure)

I've tried several different MSI packages, they all show the same behavior. I'm using wine 1.6.2.

[activescott]

I'm guessing this is due to this line which was added in this commit. Apparently some problem loading LessIO on Wine. LessIO uses a several Win32 native methods so I suspect that is at play here. Someone needs to debug though.

@jethrogb Is this something you're up for investigating further? @jgstew Is this something you might be able to take a look at?

[jethrogb]

“aspires to be platform independent” :smiley:

I'm happy to provide help debugging and testing, but I don't have a Windows/.Net toolchain setup.

[mirh]

... Wouldn't this be best reported on wine bugzilla?

[activescott]

@mirh I think since it worked in older versions of lessmsi it is likely we've introduced something that wine supports. I don't use it on wine, so I haven't taken the time to investigate yet. If you have, please let me know what's going on and I'll be happy to support you resolving it (either in lessmsi or reporting to wine).

[jgstew]

I am not sure if/when I'll have time to investigate this, but lessmsi is actively being used on OS X in a project I helped with a bit, but haven't spent time with recently.

• https://github.com/autopkg/hansen-m-recipes/blob/master/SharedProcessors/MSIVersionProvider.py

I do wonder if it is possible to detect running in Wine and use the previous function.

• Related: https://github.com/activescott/lessmsi/issues/3 , https://github.com/activescott/lessmsi/issues/50 , https://github.com/activescott/lessmsi/issues/75

FYI/CC: @hansen-m , @rustymyers

[mirh]

Finding which functions we are talking about in the first place, then check for bug reports on wine appdb, wouldn't hurt.

[Bl4Cc4t]

I’m on v1.6.1 and getting the same error. Despite the error, it works! :3

[hackathi]

So... I am still affected by this. I don't know the actual problem yet, however it seems to fail to close the handle to the cab correctly after writing:

009f: create_file( access=c0100000, sharing=00000000, create=5, options=00000060, attrs=00000080, objattr={rootdir=0000,attributes=00000040,sd={},name=L""}, filename="/root/.wine/dosdevices/z:/root/testfiles/ext2/foobar.cab" )
009f: create_file() = 0 { handle=00dc }
009f: get_handle_fd( handle=00dc )
009f: *fd* 00dc -> 129
009f: get_handle_fd() = 0 { type=1, cacheable=1, access=0012019f, options=00000060 }
009f: close_handle( handle=0000 )
009f: close_handle() = INVALID_HANDLE
009f: close_handle( handle=0000 )
009f: close_handle() = INVALID_HANDLE

Which then results in a sharing violation as it should:

009f: create_file( access=80100000, sharing=00000003, create=1, options=00000060, attrs=00000080, objattr={rootdir=0000,attributes=00000042,sd={},name=L""}, filename="/root/.wine/dosdevices/z:/root/testfiles/ext2/foobar.cab" )
009f: create_file() = SHARING_VIOLATION { handle=0000 }

wine --version reports wine-3.10.

I don't know who's at fault here beacuse as far as I can tell the cab gets written correctly. We'll see.

[activescott]

In case anyone wants to investigate this (😉) I'd start by look at the ExtractFiles method in Wixtracts. This calls into two areas that are worth investigating:

• LessIO is my library for doing all the File I/O for everything but the cab files themselves (since as it turns out the System.IO .NET File I/O library was full of critical limitations/bugs).
• My libmspack4n project which does the dirty work of dealing with cabs in C. That is also possibly an issue, but less likely as IIRC doesn't use WINE at all and instead uses the standard c lib for all i/o.

[hackathi]

FWIW, I think the problem is this call https://github.com/activescott/lessmsi/blob/master/src/LessMsi.Core/Msi/Wixtracts.cs#L386 resulting in this handle being allocated https://github.com/activescott/libmspack4n/blob/master/libmspack4n/MSCabinet.cs#L44 but not properly closed. I have no further Idea what is going on as I most probably can't contribute code back for legal reasons and therefore have not bothered to set up a debug environment, sorry about that. I think that this is a bug in wine, but I'm seriously lacking the capabilities to bisect. If anyone with wine hacking expierience besides me is interested in bisecting, feel free to do so :)

[mirh]

Latest version works just fine in wine, at least once you install dotnet45. If there is a problem, this is inside mono.