(Extended MAPI in DELPHI - MAPI Service Providers)
AKA MAPI Inferno

This section of our DEVELOPMENT site is for MAPI Service Providers. That means that you have to cover the following requirements: Very good (expert) DELPHI knowledge (this does not includes knowledge for working with third party components and VCLs), good understanding of Low-Level Microsoft API (functions, structures, pointers, memory managements, etc..), very good Extended MAPI background, and not last - strong will to learn more and investigate further.

After a few years of investigating and building MAPI clients applications, we shifted part of our development team to the "MAPI inferno" - the service providers. This area of MAPI cannot be done with any kind of third-party custom MAPI components we know - they all have proved inapplicable here. Each MAPI service provider is unique, and moreover - they work in opposite sides.

As suggested by some of our readers, this part of MAPI is not well documented. The reason? It is in the background of many Microsoft commercial products (including Microsoft Exchange Server). You can find basic information in MSDN, but the essentials are hidden. If you are "strong-headed" enough, maybe after a few weeks of digging, you could find some scraps at Google. There are only very few publications - one from Microsoft, dating from 1996, and another good is "Inside MAPI" - Microsoft (again) Press book (1996) - out of print. In June 11, 1996 Microsoft shipped the first version of Exchange server (Exchange Server 4.0) and stopped any development of documentation and also stopped producing any examples. Only some revisions of published web pages (if they are not removed).

There are three common types of MAPI service providers:

- Address book providers
- Message store providers
- Transport providers

We'd translated from the old C (not C++), these three fundamental MAPI service providers. They have only a basic functionality, but if you have enough enthusiasm - you can improve then further.

You can see also Delphi & ADO & MAPI Together - our implementation of some Extended MAPI service providers, that mix ADO DB (Active Data Objects) and Extended MAPI.

See a few screen shots!

DELPHI Flat File Address Book Provider

Upported Features:
Table restrictions. The sample address book implements the two most commonly used types of restrictions for an address book: prefix match and ANR. It does not implement the full MAPI restriction language, and restrictions are supported only on the display name.

You can see also our Address Book Provider - our implementation of service provider, that mix ADO DB (Active Data Objects) and Extended MAPI.

See a few screen shots!

DELPHI Peer Transport Provider

Not Peer-to-Peer
If peer-to-peer transmission is disabled (this is a configuration option), the transport simply leaves outbound messages in the outbound directory and collects inbound messages from the inbound directory. It does not attempt delivery. This mode can be used as the first of two stages, where the second stage moves messages to and from the network.

Addressing
In peer mode, the network path of the user's inbound directory is the e-mail address. Network paths are normally Universal Naming Convention (UNC) paths, but an MS-DOS drive and directory path can also be used.

Message in TNEF
A small set of message properties, including recipients, subject, and message text, are encoded as text for transmission. Other message properties are encapsulated in a binary file in the Transport Neutral Encapsulation Format (TNEF), using functions supplied in TNEF.DLL. This division approximates the division of properties that real transports must often make, where those properties understood by non-MAPI clients must be encoded in a transport-specific format and the remainder can be left to the TNEF.

Interface Lifetime and Cross-Referencing
Interfaces created by the transport in response to service provider interface (SPI) calls, including status interfaces, are hooked to the transport logon object and invalidated when MAPI logs off the transport. The provider INIT object is an exception, as you might expect.

Address Type and UID
The transport handles a single e-mail address type, which is configurable. It does not handle any UIDs, that is, it does not call SetProviderUID.

Per-recipient and per-message Option Support

The transport supports deferred delivery of messages on a per-recipient basis, as well as on a per-message basis.

Supported Features 
Basic features. The sample transport supports sending, receiving, and polling for new messages.
Configuration. Interactive and programmatic configuration of 14 parameters is supported.
Status interface. The sample transport supports all methods of the IMAPIStatus interface, except property setting.

Multithread safety. MAPI carefully limits the exposure of transports to access by multiple threads of execution on Win32 platforms. The sample transport protects itself against concurrency problems in the remaining cases where they might arise (in the status interface, for instance).

Cross-platform support. The sample transport generates executable files for Windows 95, Windows 98, Windows NT 3.5, Windows NT 4, Windows 2000, Windows XP and later from a single set of source files.

Event logging. The sample transport supports event logging to a text file. The file is automatically limited to a specified size. All transport sessions use the same file.

Unsupported Features
Asynchronous detection of incoming messages. The transport design does not lend itself to asynchronous detection because the file system does not notify the transport when new messages arrive.

Address Format
This transport supports a single address type whose name is configurable. MSPEER is commonly chosen; this is the type supported by the sample address book. When creating new one-off entries in an address book (i.e. the Personal Address Book), this is the value for the Address Type field. Email addresses for this transport look like DOS file paths. They can be either UNC paths, or ordinary fully qualified paths.

Configuration
The sample transport has a three-page property sheet interface for interactive configuration, which is accessible through service provider logon, through the ServiceEntry call, and through the IMAPIStatus.SettingsDialog method. The configurable parameters appear following. The sample transport also defines a property tag for each parameter so that parameters may be set programmatically through ServiceEntry calls.

Download DEMO

DELPHI Sample Message Store

Some of the things, that make possible for DSEMPMS32 to work with the other Outlook versions.
Even it doesn't support Extender Searches, we "cheated" Outlook 2003/2007. Of course, these have side effects, for example, you won't receive notifications, when there is an event in the Calendar.

Ability to create "contacts. The original code doesn't support this. Notice that the "contacts in the realization of this Message Store, doesn’t allow to be used as e-mail recipients in the Address Book, despite, they are shown there.

- Ability to have fully functional Calendar, with records and events.
- To make Tasks functional
- To create Notes.
- Support of Named Properties
- Support of Associated folders and messages - with their help you can create different Custom Views of the folders.
- Etc.

Despite it doesn’t support all possible Outlook extras, this DELPHI Sample Message Store can serve as an excellent instrument, that you can explore how Outlook communicates with Message Store, do extend it with additional functionality, and to create your own message store.

DELPHI Sample Message was started with Delphi 5, developed with Delphi 6, and in the moment the source code is fully compatible with Delphi 5/6/7/2005/2007. Where it was possible were used try..finally..end, TCriticalSection were used to insure Multithread safety.

Download DEMO

If you expect "Mickey Mouse fee" for source code licensing, please do not bother us!