Re: [Fwd: Re: [otlkcon-devel] undocumented MAPI in Outlook]
-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]
[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]
-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".
