Re: [Fwd: Re: [otlkcon-devel] undocumented MAPI in Outlook]

2005-01-27 Thread jason
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> [EMAIL PROTECTED] wrote:
>>
>> I haven't looked into the SapiMapi subproject too much, but it looks
>> like
>> it is basically intended for similar purposes.
>
> SapiMapi is a testing utility put together to analyse
> Mapi objects and properties in memory.  I couldn't use
> OutSpy because it relied on Outlook properly loading
> the Mapi plugin before it can do anything.  That's a
> problem if the plugin has not got to that point yet.

Yes, I know of that problem as well :)

> I haven't seen any open-source Mapi inspectors yet.

Are you familiar with the message store viewer from Microsoft? I wouldn't
call it open-source, but I do have source code for a version of it.
Unfortunately, due to M$ licensing, I don't think I can publicly
redistribute the sample source code. Ugh. Perhaps I can dig up the
location of it.

I found the message store viewer from Microsoft to be helpful for calling
one MAPI function at a time. Very helpful when the message store is
crashing Outlook (yes, I admit to having caused this to happen more than a
few times).

With the source code, you can put a breakpoint in the Message Store
viewer, have it just load the message store, then put a breakpoint in the
message store code itself, then actually step through the message store
code. A madenning process without any code at all from a message store
viewer. Prior to finding the Message Store viewer source code, I started
constructing my own sample MAPI client primarily for debugging purposes.

Speaking of debugging, were you ever able to locate a debug version of the
MAPI DLLs?

Oh, and I do agree that there are very few GPL or LGPL MAPI tools
available, present company excluded of course :)

> I also needed something that can do scripted testcases
> and something that can easily be installed by users.
> For example, we can ask someone to install SapiMapi then
> run some stock data retrivial scripts for diagnosis.

Sounds quite useful. I ran into a situation where someone told me a MAPI
service provider didn't work, only to find out that it was never
installed. Very frustrating...

> I big issue is displaying objects for inspection during
> debugging.  If, say, a table you are returning to
> MAPI is crashing Outlook, then you need to inspect
> that table to see if any data is off or missing.
> Since most Mapi browsing programs work *through* Mapi,
> that is hard to do.  Sapimapi has a client-side library
> routines that serialize the Mapi properties and tables
> in XML and sends them via a shared memory segment.

Very cool indeed. Much better than the simple logging I was doing to
gather similar information.

> -
> Kervin

Regards,
Jason Nocks

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFB+UjM3CryLfCgqRkRAj/BAJ96GKqQ/dpCLUbwTD6wSjE/16JshgCfSI0l
r++tKCLghaHpr7saoUO1QOk=
=k7/o
-END PGP SIGNATURE-


---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
otlkcon-devel mailing list
otlkcon-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/otlkcon-devel


Re: [Fwd: Re: [otlkcon-devel] undocumented MAPI in Outlook]

2005-01-26 Thread Kervin L. Pierre
[EMAIL PROTECTED] wrote:
I haven't looked into the SapiMapi subproject too much, but it looks like
it is basically intended for similar purposes.

SapiMapi is a testing utility put together to analyse
Mapi objects and properties in memory.  I couldn't use
OutSpy because it relied on Outlook properly loading
the Mapi plugin before it can do anything.  That's a
problem if the plugin has not got to that point yet.
I haven't seen any open-source Mapi inspectors yet.
I also needed something that can do scripted testcases
and something that can easily be installed by users.
For example, we can ask someone to install SapiMapi then
run some stock data retrivial scripts for diagnosis.
I big issue is displaying objects for inspection during
debugging.  If, say, a table you are returning to
MAPI is crashing Outlook, then you need to inspect
that table to see if any data is off or missing.
Since most Mapi browsing programs work *through* Mapi,
that is hard to do.  Sapimapi has a client-side library
routines that serialize the Mapi properties and tables
in XML and sends them via a shared memory segment.
-
Kervin
---
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
___
otlkcon-devel mailing list
otlkcon-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/otlkcon-devel


[Fwd: Re: [otlkcon-devel] undocumented MAPI in Outlook]

2005-01-25 Thread jason
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I don't think this actually went to the list. Sorry if it did and this
results in a duplicate response.

Regards,
Jason Nocks

-  Original Message 
Subject: Re: [otlkcon-devel] undocumented MAPI in Outlook
From:[EMAIL PROTECTED]
Date:Tue, January 25, 2005 6:11 pm
- --

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> [EMAIL PROTECTED] wrote:
>> Implementing *all* of the MAPI
>> interfaces for every MAPI object you want to implement would simply be
maddening. Reverse-engineering which MAPI interfaces Outlook is going
to use is almost, but not quite, as madenning.
>
> Jason,
> this last sentence is quite scary :-)

Sorry about that. Just don't want to paint an overly optimistic view. The
road ahead is a bit long and arduous. Fortunately, there seem to be a few
key ingredients starting to come together (more than 1 or 2 people and
possibly some people with some time to dig into some of the more time
consuming elements).

> It's _surely_ too early for me to think of it: I would better go on
studying and practicing MAPI.

Not necessarily. Ideas are always welcome (speaking for myself at least).
They are free and always worth at least that much.

> So pardon me if I dare to give a suggestion: what about a "MAPI
sniffer"? A piece of software that presents itself as a MAPI provider
and just forwards Outlook requests to the Exchange MAPI provider and
passes back the answers, logging all the traffic.

We had exactly the same thought when we started working on a message store
about a year and a half ago. This could definitely be done either "on the
wire" or at the MAPI API level, like a proxy. We haven't done either of
these. Even stubbing the entire MAPI API and having it wrap another
message service seems like still a lot of work.

It turns out that there's a fairly easy way to get much of the information
you need. There are a number of MAPI message store viewers available,
commercial and non-commercial, with and without source.

MAPI is all about MAPI properties. MAPI objects are essentially just one
or more MAPI properties with some functions to get or modify those MAPI
properties. And MAPI properties are primarily available through the
message store. In fact, I would call Outlook basically a "message store
viewer". The main exception is address books, but they were moved into the
message store when the "Contacts" folder appeared.

So, a message store viewer (other than Outlook) lets you view *most* of
the information you need, in a more controlled fashion. The biggest
remaining problem is figuring out what the MAPI properties actually mean.
Some of the MAPI properties are documented. Many of the *interesting* ones
are not.

The trick is making sense out of the 160 MAPI properties Outlook requests
when it wants to display one MAPI object. Guess how many of the 160 MAPI
properties are documented... For added confusion, a number of the
properties are really the same. Plus, things get complicated due to
Outlook trying to be smart, the way named properties work, etc. I don't
want to dump too much low-level technical details in this particular
email, just trying to give you an idea of what problems are faced. Also, I
don't remember all of the details in exact detail off the top of my head.
MAPI sometimes gets a bit more complicated down at the nitty-gritty
detailed level.

Reverse engineering Outlook's expectations isn't really difficult work,
just incredibly time consuming. So, for those doing it in their spare
time, well, there's just not tons of time to spare. Pardon the pun.

There are some websites with some very helpful documentation about some of
the undocumented properties, but much of what we found we have to do is
trial and error, observe and make educated guesses, spray and pray, etc.

Perhaps just documenting these MAPI properties would be an area where you
could get a better understanding of how MAPI works while contributing some
time if you have it. I'd be happy to share the properties I'm aware of to
get the list started if this idea seems worthwhile.

I would think that the same MAPI properties would also be transmitted
"over the wire" for anyone working on the "over the wire" exchange
replacement project.

> You could see the properties Outlook requests and try to clue from the
answers what is their semantics.

Right, you can also just log what Outlook is trying to do to your service,
do the same thing to exchange, observe what exchange does and try to mimic
it. This is what we were doing. It works, but takes a lot of time.

We also started working on writing automated validation tests for the
message store we were working on. Basically, using a tool that would parse
text files, reading expected MAPI properties and comparing them to actual
MAPI properties in the message store. We called this a "Mapi Property
Inspector".