Re: msi: InstallPackage check for UI level must not disregard flags (updated)
On 2/5/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote:
This is an update, a little less hacky thanks to advice from Dmitry Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was getting to the point where it was trying to launch the .msi files that do the actual install, but was quitting with the message "This module is not designed for direct execution." Install worked fine with native MSI. After a while of playing with it and disassembling the MSI file with dark.exe tool, I noticed that the .msi files ran in execute mode but not UI mode. Finally, I checked the UI level that wine msi was reading, and it was 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, MSI_InstallPackage was only checking if the uilevel >= INSTALLUILEVEL_REDUCED, which would have been true in this case as INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This patch fixes this check, and now the installer finished successfully (although it seems upon a quick check that there are more install bugs for this program in wine, as not all files that should be there seem to be there after this install).
Changelog:
* msi: InstallPackage check for UI level must not disregard INSTALLUILEVEL flags.
+ if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED )
Magic numbers are bad. What is 0xF? -- James Hawkins
On 2/6/07, James Hawkins <truiken(a)gmail.com> wrote:
On 2/5/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote:
This is an update, a little less hacky thanks to advice from Dmitry Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was getting to the point where it was trying to launch the .msi files that do the actual install, but was quitting with the message "This module is not designed for direct execution." Install worked fine with native MSI. After a while of playing with it and disassembling the MSI file with dark.exe tool, I noticed that the .msi files ran in execute mode but not UI mode. Finally, I checked the UI level that wine msi was reading, and it was 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, MSI_InstallPackage was only checking if the uilevel >= INSTALLUILEVEL_REDUCED, which would have been true in this case as INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This patch fixes this check, and now the installer finished successfully (although it seems upon a quick check that there are more install bugs for this program in wine, as not all files that should be there seem to be there after this install).
Changelog:
* msi: InstallPackage check for UI level must not disregard INSTALLUILEVEL flags.
+ if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED )
Magic numbers are bad. What is 0xF?
I just read the thread that this patch came from, but the fact that I had to ask in the first place shows that we need at least a comment or a descriptive constant variable/define. -- James Hawkins
So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere set to 0xf then? Should this be in msi.h (or would this be confusing as this is not defined in Windows I don't think) or just in the same file where the other change is being made? Thanks Misha -----Original Message----- From: James Hawkins [mailto:truiken(a)gmail.com] Sent: Tue 2/6/2007 1:57 AM To: wine-devel(a)winehq.org Cc: Koshelev, Misha Vladislavo Subject: Re: msi: InstallPackage check for UI level must not disregard flags (updated) On 2/6/07, James Hawkins <truiken(a)gmail.com> wrote:
On 2/5/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote:
This is an update, a little less hacky thanks to advice from Dmitry Timoshkov. This fixes bug #6992. The installer for Vector NTI 10 was getting to the point where it was trying to launch the .msi files that do the actual install, but was quitting with the message "This module is not designed for direct execution." Install worked fine with native MSI. After a while of playing with it and disassembling the MSI file with dark.exe tool, I noticed that the .msi files ran in execute mode but not UI mode. Finally, I checked the UI level that wine msi was reading, and it was 102 which is INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY. However, MSI_InstallPackage was only checking if the uilevel >= INSTALLUILEVEL_REDUCED, which would have been true in this case as INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED but the actual ui level is INSTALLUILEVEL_NONE which is < INSTALLUILEVEL_REDUCED. This patch fixes this check, and now the installer finished successfully (although it seems upon a quick check that there are more install bugs for this program in wine, as not all files that should be there seem to be there after this install).
Changelog:
* msi: InstallPackage check for UI level must not disregard INSTALLUILEVEL flags.
+ if ( (msi_get_property_int(package, szUILevel, 0) & 0xf) >= INSTALLUILEVEL_REDUCED )
Magic numbers are bad. What is 0xF?
I just read the thread that this patch came from, but the fact that I had to ask in the first place shows that we need at least a comment or a descriptive constant variable/define. -- James Hawkins
On 2/6/07, Koshelev, Misha Vladislavo <mk144210(a)bcm.tmc.edu> wrote:
So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere set to 0xf then? Should this be in msi.h (or would this be confusing as this is not defined in Windows I don't think) or just in the same file where the other change is being made?
The patch was accepted as-is, so I wouldn't worry about it. P.S. Please bottom-post on replies. -- James Hawkins
On Tue, 2007-02-06 at 19:23 +0100, Felix Nawothnig wrote:
Koshelev, Misha Vladislavo wrote:
So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere set to 0xf then?
Shouldn't that be 0x7?
I guess either one would work since the first flag is 0x20. Do I need to change it to 0x7 or leave as is? Misha
Misha Koshelev wrote:
So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere set to 0xf then? Shouldn't that be 0x7? I guess either one would work since the first flag is 0x20. Do I need to change it to 0x7 or leave as is?
So would 0x1f or 0xfffffe1f. Doesn't make it correct and could fail if there are undocumented flags (that gap before 0x20 looks suspicious to me...) - and that's more likely than undocumented levels imho (and even with 0x7 we cover another 2). Felix
On Tue, 2007-02-06 at 19:51 +0100, Felix Nawothnig wrote:
Misha Koshelev wrote:
So do you think I should add a define like INSTALLUILEVEL_NOFLAGS somewhere set to 0xf then? Shouldn't that be 0x7? I guess either one would work since the first flag is 0x20. Do I need to change it to 0x7 or leave as is?
So would 0x1f or 0xfffffe1f. Doesn't make it correct and could fail if there are undocumented flags (that gap before 0x20 looks suspicious to me...) - and that's more likely than undocumented levels imho (and even with 0x7 we cover another 2).
Felix
Ok, sent a patch update. Sound reasonable. Misha
participants (4)
-
Felix Nawothnig -
James Hawkins -
Koshelev, Misha Vladislavo -
Misha Koshelev