On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons:
- The test is already testing a full product install (installs files,
services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing.
Changelog:
* msi: Make MsiInstallProduct conformance test depend on proper UIlevel processing.
You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases.
If the full UI is started (incorrectly)
* the InstallUISequence table will be used, and the install will fail. If the full UI is* not started (correctly) the InstallExecuteSequence table will be used.
Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed.
On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons:
- The test is already testing a full product install (installs files,
services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing.
Changelog:
* msi: Make MsiInstallProduct conformance test depend on proper UIlevel processing.
You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases.
If the full UI is started (incorrectly)
* the InstallUISequence table will be used, and the install will fail. If the full UI is* not started (correctly) the InstallExecuteSequence table will be used.Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa
Weird, because it does indeed fail when running in full UI mode.
Do you know a better (more proper) way to do this then? I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message. The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests. Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test?
Thanks Misha
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons:
- The test is already testing a full product install (installs files,
services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing.
Changelog:
* msi: Make MsiInstallProduct conformance test depend on proper UIlevel processing.
You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases.
If the full UI is started (incorrectly)
* the InstallUISequence table will be used, and the install will fail. If the full UI is* not started (correctly) the InstallExecuteSequence table will be used.Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa
Weird, because it does indeed fail when running in full UI mode.
It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer.
Do you know a better (more proper) way to do this then?
Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch.
I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message.
Why do you want the install to fail?
The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests
Correct. No user intervention.
Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test?
I don't know why you want the install to fail, so I don't have any suggestions.
On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons:
- The test is already testing a full product install (installs files,
services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing.
Changelog:
* msi: Make MsiInstallProduct conformance test depend on proper UIlevel processing.
You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases.
If the full UI is started (incorrectly)
* the InstallUISequence table will be used, and the install will fail. If the full UI is* not started (correctly) the InstallExecuteSequence table will be used.Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa
Weird, because it does indeed fail when running in full UI mode.
It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer.
Do you know a better (more proper) way to do this then?
Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch.
I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message.
Why do you want the install to fail?
The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests
Correct. No user intervention.
Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test?
I don't know why you want the install to fail, so I don't have any suggestions.
Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the "child" MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account.
This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install. Thus, to test this check one would set the UI level to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine MSI to install the package. If the package succeeded, that means that MSI_InstallPackage was checking the UI level correctly (as it does now since my patch that fixed bug 6992), and everything would be installed. Otherwise, it would fail, nothing would be installed, and we would know that the consistency check failed and wine MSI was not properly checking UI level flags (as it was before my patch and as it would if some regression occurred, e.g., changes in the MSI_InstallPackage code that used the UI level without regard for the flags). So that is what I am trying to do. Just write a conformance test that fails (in some kind of proper way) in UI install but does not in the non-UI install in a way that would be easy to determine with an ok(soemthing) statement.
Any advice would be appreciated. Thanks.
Misha
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons:
- The test is already testing a full product install (installs files,
services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing.
Changelog:
* msi: Make MsiInstallProduct conformance test depend on proper UIlevel processing.
You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases.
If the full UI is started (incorrectly)
* the InstallUISequence table will be used, and the install will fail. If the full UI is* not started (correctly) the InstallExecuteSequence table will be used.Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa
Weird, because it does indeed fail when running in full UI mode.
It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer.
Do you know a better (more proper) way to do this then?
Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch.
I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message.
Why do you want the install to fail?
The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests
Correct. No user intervention.
Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test?
I don't know why you want the install to fail, so I don't have any suggestions.
Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the "child" MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account.
This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install. Thus, to test this check one would set the UI level to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine MSI to install the package. If the package succeeded, that means that MSI_InstallPackage was checking the UI level correctly (as it does now since my patch that fixed bug 6992), and everything would be installed. Otherwise, it would fail, nothing would be installed, and we would know that the consistency check failed and wine MSI was not properly checking UI level flags (as it was before my patch and as it would if some regression occurred, e.g., changes in the MSI_InstallPackage code that used the UI level without regard for the flags). So that is what I am trying to do. Just write a conformance test that fails (in some kind of proper way) in UI install but does not in the non-UI install in a way that would be easy to determine with an ok(soemthing) statement.
You can't do this test by making the install fail, because you have no way to check why the install failed. Anything you test with the UI sequence cannot present a UI to the user. Why don't you just use a custom action 51 in the install ui seq to set a property to some value, and then make the condition of the component of an install file the value of the property? That way you can check if the file was installed or not. Either way, you're going to have to write a new test function for this.
On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
Hi, here is my proposed patch to the current msi MsiInstallProduct consistency test that will make it's success depend on proper process of UI flags (as well as everything else it depends on to make a successful install). It seems to me like this is the simplest way to add this test (it is only 5-6 lines added total), and it seems fair to me to add it to this existing test for two reasons:
- The test is already testing a full product install (installs files,
services, registry values, etc) and my modification will simply result in either no modification to these actions if UI level processing is good or complete failure if it is bad, which will make the problem very easy to diagnose. 2. Looking through instructions on msdn it seems that there isn't a kosher way to make a very simple MSI file that just, say, writes a registry value (without doing costing, install validation, having a full features table, installing some features, etc.) which would make a separate function easy to implement and it does not really seem necessary to copy and paste the whole test_MsiInstallProduct (or similar) function just to check UI level processing.
Changelog:
* msi: Make MsiInstallProduct conformance test depend on proper UIlevel processing.
You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases.
If the full UI is started (incorrectly)
* the InstallUISequence table will be used, and the install will fail. If the full UI is* not started (correctly) the InstallExecuteSequence table will be used.Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa
Weird, because it does indeed fail when running in full UI mode.
It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer.
Do you know a better (more proper) way to do this then?
Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch.
I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message.
Why do you want the install to fail?
The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests
Correct. No user intervention.
Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test?
I don't know why you want the install to fail, so I don't have any suggestions.
Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the "child" MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account.
This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install. Thus, to test this check one would set the UI level to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine MSI to install the package. If the package succeeded, that means that MSI_InstallPackage was checking the UI level correctly (as it does now since my patch that fixed bug 6992), and everything would be installed. Otherwise, it would fail, nothing would be installed, and we would know that the consistency check failed and wine MSI was not properly checking UI level flags (as it was before my patch and as it would if some regression occurred, e.g., changes in the MSI_InstallPackage code that used the UI level without regard for the flags). So that is what I am trying to do. Just write a conformance test that fails (in some kind of proper way) in UI install but does not in the non-UI install in a way that would be easy to determine with an ok(soemthing) statement.
You can't do this test by making the install fail, because you have no way to check why the install failed. Anything you test with the UI sequence cannot present a UI to the user. Why don't you just use a custom action 51 in the install ui seq to set a property to some value, and then make the condition of the component of an install file the value of the property? That way you can check if the file was installed or not. Either way, you're going to have to write a new test function for this.
That sounds good. I actually made a new function doing what you said, and in testing under the wine MSI it works perfectly (writes specific file in UI mode but not in execute only mode, returns success, everything okay), but when I tried in XP I got a very weird behavior (or maybe not so weird). Specifically, XP MSI seems to reset the property between the UI sequence and execute sequence (no errors occur, but the file does not get written in UI sequence; if I take the condition out the file does get written; in fact I decided to make a custom action called StopMessage that displays the value of my property, that is simply a custom action 19, and in Wine MSI it displays my modified property value if I put it in the UI table or the execute table, but in Win XP MSI it only displays my modified value in the UI table, but in the Execute table it goes back either to blank or to the initial value if I define it in Properties; I even tried adding it to the SecureCustomProperties property but it did not help). Is this just a weird XP thing that I should just ignore and post my code as is, or is there some other way to set a property in the UI sequence that retains its value in the execute sequence in wine and XP? What if wine MSI decides to copy this behavior at a later date, my conformance test would not work anymore.
Thanks Misha
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 16:46 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 13:23 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
On Wed, 2007-02-07 at 12:30 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote: > Hi, here is my proposed patch to the current msi MsiInstallProduct > consistency test that will make it's success depend on proper process of > UI flags (as well as everything else it depends on to make a successful > install). It seems to me like this is the simplest way to add this test > (it is only 5-6 lines added total), and it seems fair to me to add it to > this existing test for two reasons: > 1. The test is already testing a full product install (installs files, > services, registry values, etc) and my modification will simply result > in either no modification to these actions if UI level processing is > good or complete failure if it is bad, which will make the problem very > easy to diagnose. > 2. Looking through instructions on msdn it seems that there isn't a > kosher way to make a very simple MSI file that just, say, writes a > registry value (without doing costing, install validation, having a full > features table, installing some features, etc.) which would make a > separate function easy to implement and it does not really seem > necessary to copy and paste the whole test_MsiInstallProduct (or > similar) function just to check UI level processing. > > Changelog: > > * msi: Make MsiInstallProduct conformance test depend on proper UI > level processing. >
You need to put whatever you're trying to test into a new test function. As-is, it's not clear what you're testing and we need to keep the tests logically separate. Test both a success and a failure case, plus all the in between cases.
> If the full UI is started (incorrectly) > + * the InstallUISequence table will be used, and the install will fail. If the full UI is > + * not started (correctly) the InstallExecuteSequence table will be used.
Why does the install fail if we run the InstallUISequence action?. Also, InstallExecuteSequence runs no matter what so this comment would need to be fixed. a fa
Weird, because it does indeed fail when running in full UI mode.
It's failing because you don't have the InstallUISequence set up correctly. I suggest you read through msdn about Windows Installer.
Do you know a better (more proper) way to do this then?
Like I said before, I don't know what you're trying to do. It wasn't obvious from the last patch.
I was researching this last night and I found either custom action 19 (this number is off the top of my head) that will fail the install and display a message or a failed Launch Condition which will also fail install and display a message.
Why do you want the install to fail?
The custom action 19 (?) worked beautifully in my tests, but the problem is that it display a dialog box if it thinks it is in full UI mode and waits for the user to press okay, and if I understand correctly user input like this is a no no in writing wine conformance tests
Correct. No user intervention.
Do you have any suggestions for how to fail an install in full UI mode without displaying a dialog box, or would this be okay in the case of this specific conformance test?
I don't know why you want the install to fail, so I don't have any suggestions.
Ok sorry, I will make it clearer. The reason I am writing this conformance test is to tickle the bug that my patch fixed earlier (6992) in which the Vector NTI installer failed because MSI_InstallPackage was not properly checking the UI level (using the mask) and so having any flags such as INSTALLUILEVEL_SOURCERESONLY on top of INSTALLUILEVEL_NONE was making it think a full graphical install was wanted (because INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY > INSTALLUILEVEL_REDUCED), and since this particular MSI was designed so that it would only work for a non-UI install (initiated by the actual main MSI/installer which first sets the internal install level, and not be the user clicking on one of the "child" MSIs), it would quit with a message (custom action 19). I would like to make a consistency check that checks this to make sure that MSI_InstallPackage does in fact check the UI level correctly, taking the mask on the UILevel property into account.
This, my original idea was to have a full install in the ExecuteSequence, and have just one action in the UISequence that would fail the install. Thus, to test this check one would set the UI level to INSTALLUILEVEL_NONE | INSTALLUILEVEL_SOURCESONLY and then ask wine MSI to install the package. If the package succeeded, that means that MSI_InstallPackage was checking the UI level correctly (as it does now since my patch that fixed bug 6992), and everything would be installed. Otherwise, it would fail, nothing would be installed, and we would know that the consistency check failed and wine MSI was not properly checking UI level flags (as it was before my patch and as it would if some regression occurred, e.g., changes in the MSI_InstallPackage code that used the UI level without regard for the flags). So that is what I am trying to do. Just write a conformance test that fails (in some kind of proper way) in UI install but does not in the non-UI install in a way that would be easy to determine with an ok(soemthing) statement.
You can't do this test by making the install fail, because you have no way to check why the install failed. Anything you test with the UI sequence cannot present a UI to the user. Why don't you just use a custom action 51 in the install ui seq to set a property to some value, and then make the condition of the component of an install file the value of the property? That way you can check if the file was installed or not. Either way, you're going to have to write a new test function for this.
That sounds good. I actually made a new function doing what you said, and in testing under the wine MSI it works perfectly (writes specific file in UI mode but not in execute only mode, returns success, everything okay), but when I tried in XP I got a very weird behavior (or maybe not so weird). Specifically, XP MSI seems to reset the property between the UI sequence and execute sequence (no errors occur, but the file does not get written in UI sequence; if I take the condition out the file does get written; in fact I decided to make a custom action called StopMessage that displays the value of my property, that is simply a custom action 19, and in Wine MSI it displays my modified property value if I put it in the UI table or the execute table, but in Win XP MSI it only displays my modified value in the UI table, but in the Execute table it goes back either to blank or to the initial value if I define it in Properties; I even tried adding it to the SecureCustomProperties property but it did not help). Is this just a weird XP thing that I should just ignore and post my code as is, or is there some other way to set a property in the UI sequence that retains its value in the execute sequence in wine and XP? What if wine MSI decides to copy this behavior at a later date, my conformance test would not work anymore.
Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table?
http://msdn2.microsoft.com/en-us/library/aa370912.aspx
Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table?
First of all, I added the Property to the Property table, which is, what I understand from that link (paragraph three I think) all that it takes to make it public (in fact, what happens when you go from UI to Execute is that the value of the property seems to be reset back to the value from the Properties table).
Two things: 1) I am testing the behavior in UI mode to make sure the test works, but the actual "test" is to test the mode NONE | otherflags, which, before the bug fix, would result in a UI install, whereas in Windows (all versions) it would result in an execute-only install. This test breaks on wine without the patch to fix it, whereas it would execute on all Windows version without error, thus in this sense it "conforms" to Windows. The question is whether we are able to detect a failure to conform. 2) I tried on Win98 and in Win98 it works the same way it does on Wine.
I will play with it some more, but because of these points it seems to me that it is still a reasonable test (it will succeed on all version of Windows, on Wine that properly detects UI flags, but fail on wine that does not detect UI flags; however, in the future, if wine MSI is made more like Win XP MSI, it would be possible that we will not be able to detect failure anymore).
Misha
Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table?
Aha, google search figured it out:
* Property name ALL CAPS - passed from UI to execute. * otherwise not.
Too bad it's not documented on msdn (you think they would...)
Misha
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table?
Aha, google search figured it out:
- Property name ALL CAPS - passed from UI to execute.
- otherwise not.
Too bad it's not documented on msdn (you think they would...)
"Properties with names containing no lowercase letters are public properties..."
http://msdn2.microsoft.com/en-us/library/aa370905.aspx
On Wed, 2007-02-07 at 23:46 -0600, James Hawkins wrote:
On 2/7/07, Misha Koshelev mk144210@bcm.tmc.edu wrote:
Well, by definition, that's not really a conformance test because it doesn't conform to windows. Did you make the property public and add the property to the Property table?
Aha, google search figured it out:
- Property name ALL CAPS - passed from UI to execute.
- otherwise not.
Too bad it's not documented on msdn (you think they would...)
"Properties with names containing no lowercase letters are public properties..."
Too bad I don't read things carefully enough :)
Anyway, I am sending the patch to wine-patches now. It is able to determine UI level properly (UI vs execute-only) on Win98, WinXP, and wine. Phew, time to go to bed.
Misha
-
James Hawkins -
Misha Koshelev