Andrew Nguyen arethusa26@gmail.com writes:
This seemed to be the easiest and most trivial way to allow MAPIInitialize to succeed in the tests, which will be added in the next several patches.
That doesn't seem right. The tests should be able to work without an extended provider.
On Mon, Jan 18, 2010 at 8:46 AM, Alexandre Julliard julliard@winehq.org wrote:
Andrew Nguyen arethusa26@gmail.com writes:
This seemed to be the easiest and most trivial way to allow MAPIInitialize to succeed in the tests, which will be added in the next several patches.
That doesn't seem right. The tests should be able to work without an extended provider.
-- Alexandre Julliard julliard@winehq.org
Yes, the mapi32 prop and util tests on Wine don't require the extended MAPI provider, but on Windows a MAPI provider must exist in order for initialization to succeed. Without a provider, NT platforms simply skip:
prop.c:1380: Tests skipped: ScInitMapiUtil is not implemented
Currently, the unit tests do this with ScInitMapiUtil, but the problem with this approach is that on systems with the Outlook extended MAPI provider, initialization with ScInitMapiUtil result in some tests triggering a crash within the provider. I've tried to deal with this by having the tests initialize with MAPIInitialize, and to make the tests pass on Wine also I added the MAPIInitialize function to the winemapi provider. Is my approach the best way to achieve the task, or should I be doing something else?
Andrew Nguyen arethusa26@gmail.com writes:
Yes, the mapi32 prop and util tests on Wine don't require the extended MAPI provider, but on Windows a MAPI provider must exist in order for initialization to succeed. Without a provider, NT platforms simply skip:
prop.c:1380: Tests skipped: ScInitMapiUtil is not implemented
Currently, the unit tests do this with ScInitMapiUtil, but the problem with this approach is that on systems with the Outlook extended MAPI provider, initialization with ScInitMapiUtil result in some tests triggering a crash within the provider. I've tried to deal with this by having the tests initialize with MAPIInitialize, and to make the tests pass on Wine also I added the MAPIInitialize function to the winemapi provider. Is my approach the best way to achieve the task, or should I be doing something else?
The real question is what do we need to do to be able to run on Windows the tests that don't require an extended provider. If MAPIInitialize does it fine, but in that case it should do it on Wine too.
On 18/01/2010 08:46, Alexandre Julliard wrote:
This seemed to be the easiest and most trivial way to allow MAPIInitialize to succeed in the tests, which will be added in the next several patches.
That doesn't seem right. The tests should be able to work without an extended provider.
Indeed, unless we're actually going to implement some Extended MAPI functions in winemapi, we shouldn't really be adding MAPIInitialize - particularly as mapi32 will ignore winemapi for Extended MAPI purposes unless it's actually registered in the Clients section of the registry as an Extended MAPI provider.