Back Home Up Next                 

    My efforts are dedicated to my "Source of Inspiration..."

MAPI       anim1058.gif (13911 bytes)  
Research Utelization ] WOSA ] SAPI ] TAPI ] [ MAPI ] ICA ] Operating Systems ] Prototype ]


Search for:

E-Mail 101

Messaging Application Programming interface:

MAPI is more than a handful of e-mail APIs,  it is a defined set of message services available to all programs that run in the Windows operating environment.

There are various kinds of applications and message types commonly used under MAPI services.

Here, you'll find about the three general types of MAPI messages: 

  1. Text Messages

  2. Formatted documents and binary files

  3. Control Messages

Each of these message types has a distinct set of properties and uses within the MAPI framework. This site describes each of the message types and shows how you can use them within the MAPI architecture.

There are also three common types of MAPI applications:

  1. Electronic Mail Clients

  2. Message Aware Applications

  3. Message Enable Applications

Each of these application types is defined and illustrated in this site. You'll also learn the relative strengths of each type of MAPI application.

MAPI Services and Windows

The MAPI service set is more than a set of API commands and functions that we can use to send e-mail from point to point. The MAPI interface is actually a carefully defined set of messaging services available to all Windows programs. This pre-defined set has three key attributes:




Because the MAPI service set contains these three characteristics, it has become the de facto messaging interface standard for Windows applications.

Access to MAPI services is the same for all versions of the Windows operating system. But even though your Windows programs use the same methods for accessing MAPI services, MAPI services can vary from system to system. Also, MAPI architecture allows software designers to create their own service providers (SPs) to support the MAPI service set.

These services are also available within all existing flavors of the Windows operating system. Even more important, the methods of access to these message services is the same, regardless of the version of Windows we are working with. This means that programs using MAPI services that were written under Windows 3.1 will still be able to access those same MAPI services under Windows 95.


Probably the most important aspect of the MAPI service architecture is its flexibility. Microsoft has implemented MAPI within the Windows Open Systems Architecture (WOSA). This architecture is designed to allow customization at both the client (user) side and the server (provider) side. In other words, we can use MAPI not only to create your own end-user software to read, write, create, and send messages, but also to construct custom server-side software to store and transport those same messages. As part of the WOSA model, MAPI services are implemented in a tiered format


The first layer is the client layer. This is what the end-user most often sees. At this level a set of well-defined services are available. These services are accessed when the client layer makes a service request to the second layer-the MAPI DLL. The MAPI DLL takes the service request from the client and forwards it on to the third layer in the tier-the service provider. The service provider is responsible for fulfilling the client request and sending the results of that request back to the DLL where it is then forwarded to the client that made the initial request. Throughout the process, the DLL layer acts as a broker between the client side and the server side.

The primary advantage of this layered implementation is the ease with which users can interchange client and server components. Since the only constant required in the mix is the DLL layer, any client can be matched with any server component to provide a working message service. It is very common to switch client-side components in a messaging service. Each e-mail reader is a MAPI client application. Any application that sports a send button is actually a MAPI client. Any specialized program written to manipulate messages at the end-user level is a MAPI client.

While interchanging MAPI clients is rather commonplace, interchanging MAPI service providers is not. In a network environment, a single service provider will usually be designated as the default provider of MAPI services. It is no longer rare to have several MAPI service providers available at the same time, however. In fact, the Microsoft Mail Exchange client that ships with Windows 95 is specifically designed to be able to access more than one service provider. It is possible to use the Windows Exchange client to access messages via Microsoft Mail Server, Microsoft FAX, or through the Microsoft Network (MSN). we can even install third-party service providers into the Exchange client (such as the one provided by CompuServe) to access messages stored in other mail systems.


The MAPI service set contains a set of services that encompasses all the basic messaging tasks:

Message service logon and logoff

Reading, creating, and deleting text messages

Adding and deleting message binary file attachments

Addressing and transporting the completed messages

The exact behavior and properties of each of these services are defined as part of MAPI. All vendors who supply a MAPI-compliant set of tools provide these services in the exact same manner. This way, any program that uses MAPI services can be assured that there are no special API variations to deal with when moving from one vendor's MAPI product to another. This means the programs we write today using your current implementation of MAPI services will function under other implementations of the MAPI service set.


This leads to the second strength of Microsoft's MAPI service set-portability. Microsoft supports MAPI services on all versions of its Windows operating systems. If we write a program for the Windows 3.1 version of MAPI services, that same program can still access the MAPI services under any other version of Windows that supports your executable program. This is a key issue when we consider how many versions of Windows are currently in use and how quickly new versions of the operating system are developed and deployed.

Not only will we be able to move your MAPI-related programs to various Windows platforms, we can also allow programs to access MAPI services from more than one platform at once. In other words, users of more than one version of Windows can all be accessing MAPI services from a central location at the same time.



Microsoft has announced plans to move several of its service sets (MAPI included) beyond the Windows operating environment, too. As this happens, Microsoft has pledged that the same set of functions and routines used under the Windows environment will be available in other operating systems.


The primary role of the MAPI service is to transport and store messages. This section identifies three common message types supported by MAPI services:

Text Messages

Formatted documents or binary files

Control messages

The most basic message form is the text message, commonly thought of as e-mail. Most electronic message systems also support the second type of message-formatted documents or binary files. These are usually included as attachments to a text message.

The third message type is a control message. Control messages are usually used by the operating system to pass vital information such as system faults, potential failure conditions, or some other type of status information. Control messages can also be passed between programs in order to implement a level of distributed processing in a computer network.

The following sections review each message type in more detail.

Text Messages

The text message is the most common MAPI message. In fact, all MAPI messages have a default text message component. A text message contains the letters and words composed by users to communicate with other message system users.

All MAPI service providers must supply a simple text message editor as part of their MAPI implementation. All MAPI message providers support plain ASCII text characters as a message body. Many also support rich-text messages that contain formatting characters such as font and color. The Microsoft Mail client supplied for Windows 3.11 and Windows for Workgroups supports plain ASCII text. The Microsoft Mail Exchange client supplied for Windows 95 supports rich-text formatting.

Formatted Documents and Binary Files

The second MAPI message type is the formatted document or binary file, which is usually a file containing non-printable characters such as a spreadsheet, a word-processing file, graphics, or even an executable program. Binary files are supported by MAPI services as attachments to text messages. The MAPI service set allows multiple attachments to a single text message. This means we can send several binary files to the same e-mail address using a single message body.

All MAPI service providers support the use of binary attachments to a message body. However, the transport of binary attachments across multiple message servers may not be supported. For example, if we compose a message that contains attached binary files, address it to an associate at a distant location, and attempt to send the message using a service provider that supports only Simple Mail Transfer Protocol (SMTP) format, your attached binary files will not be successfully transported to the recipient.

Control Messages

The third type of MAPI message is the control message. Control messages are usually used by the operating system to deliver system status information, such as a component failure or other system-related problem. These messages are usually addressed directly to the system administrator.

Control messages can also be used to pass data or other control information between programs. Control messages of this type can contain requests for information that is to be collected by one program and returned to another for further processing. Or the control message can contain actual data to be manipulated by another program. Since MAPI services can stretch across the LAN or across the globe, control messages can be passed to systems halfway around the globe as easily as to systems across the room.

It is possible to designate one or more workstations on a network as batch job computers. These machines wait for control messages that direct them to perform time-consuming tasks, such as extended database searches or generating long reports, thus freeing up users' workstations for more immediate business. Once the task is complete, the batch job machine can send a completion notice via e-mail to the user who sent the original request. While it is true that OLE Automation servers are beginning to replace batch job computers that are controlled by MAPI messages, MAPI services are still a very powerful alternative.

MAPI Applications

Just as there are three types of MAPI messages, there are three general types of MAPI applications:

Electronic mail clients

Message-aware applications

Message-enabled applications

Electronic Mail Clients

Electronic mail (e-mail) clients are the most common form of MAPI application. An e-mail client allows end-users direct access to the MAPI services supported by the back-end service provider.

Typical services provided by a MAPI e-mail client include

Message service logon and logoff

Reading, creating, and deleting text messages

Adding and deleting binary file message attachments

Addressing and transporting completed messages

Electronic mail clients can also provide additional services to make it easy to manipulate, store, and retrieve text messages and binary file attachments. Electronic mail clients may also have additional features for addressing and transporting messages, including the use of defined mailing lists and the capability to address messages as cc (courtesy copies) or Bcc (blind courtesy copies).

Message-Aware Applications

Message-aware applications are non-MAPI programs that allow users access to MAPI services. Typically, this access is implemented through the addition of a send option in a menu or button bar. Figure 3.6 shows the Microsoft Word 95 main menu with the Send menu item highlighted.

Message-aware applications usually treat e-mail services just like any other storage or output location, such as disk drives, printers, or modems. In these cases, the ability to send the standard output as an electronic mail message is an added feature for the application. As MAPI services become a standard part of the Windows operating system, message-aware applications will become the norm instead of the exception.

Message-Enabled Applications

The last category of MAPI applications is message-enabled applications. Message-enabled applications are programs that offer message services as a fundamental feature. While message-aware applications provide message services as an additional feature and can operate well without them, message-enabled applications are specifically designed to use message services and most will not run properly unless message services are available on the workstation.

Here are some examples of message-enabled applications:

Computerized service dispatch-Customer calls are handled by representatives at pc workstations where they fill out data entry forms outlining the repair needs and the location of the service call. When the data entry is complete, the program analyzes the information and, based on the parts needed and the service location, routes an instant electronic message containing the service request and a list of needed parts to the repair office nearest to the customer.

Online software registration-When a user installs a new software package, part of the installation process includes an online registration form that already contains the unique software registration code along with a data entry form for the user to complete. Once the form is completed, the results are placed in the user's e-mail outbox to be sent directly to the software company to confirm the user's software registration.

End-user support services-When network end-users have a question about a software package or need to report a problem with their workstation or the network, they call up a data entry form prompting them to state the nature of the problem. This program will also automatically load the user's system control files and add them as attachments to the incident report. Once the form is complete, it is sent (along with the attachments) to the appropriate network administrator for prompt action.

It is important to note that, in some cases, users of message-enabled applications may not even be aware that they are using the e-mail system as part of their application. MAPI services define properties and methods for logging users in and out of the message server without using on-screen prompts. MAPI also provides options for addressing and sending messages without the use of on-screen prompts or user confirmation. By using these features of MAPI services, we can design a program that starts a message session, reads mail, composes replies, addresses the new mail, and sends it to the addressee without ever asking the user for input.

Other Types of Message Applications

There are two more types of message-enabled applications that deserve comment here. These two application types are

Electronic forms applications

Message-driven applications

Electronic forms applications display a data entry screen that contains one or more data fields for the user to complete. These data fields act as full-fledged windows controls and can support all the events normally supported by Windows data entry forms. Once the form is completed, the data, along with additional control information, is sent to the addressee through MAPI services. When the addressee opens the new mail, the same formatted data entry form appears with the fields filled in.


The message-driven application looks for data contained in a message and acts based on the data it finds. Message-driven applications can use any aspect of the message as control information for taking action. Message-driven applications can inspect the message body or subject line for important words or phrases, check the sender's name or the date and time the message was sent, or even scan attachments for important data. These applications can then use the data to forward messages to another person automatically, to set alerts to notify the user of important messages, or to start other programs or processes at the workstation.

Below are some examples of message-driven applications:

Message filtering agent-Users can enter a list of important keywords into a list box. This list is used to scan all incoming text messages automatically. If the message contains one or more of the keywords, the user is notified immediately that an important message has arrived. Users could also set values to scan for the message sender's name. For example, if the message came from the user's boss, an alert could sound to warn the user that an urgent message has arrived. The same technique can be used to automatically forward specific messages when the user is away on a trip.

File transfer database update application-This program could be used by outlying sales offices to update a central database automatically. Each day the remote offices would enter sales figures in a database, then attach the binary database file to an e-mail message, and send the message to the corporate headquarters. There, a special workstation (logged in as the addressee for all sales database updates) would receive the message and automatically run a program that takes the binary database file and merges it into the central database. This same program could then provide summary data back to the remote offices to keep them up to date on their progress.

Electronic database search tool-Many companies have large libraries of information on clients, products, company regulations, policies and procedures, and so on. Often users would like to run a search of the information but don't have time to physically visit the library and pour through thousands of pages in search of related items. If the information is kept in online databases, users at any location around the world could formulate a set of search criteria to apply against the databases and then submit these queries, via MAPI messages, to one or more workstations dedicated to performing searches. After the search is completed, the resulting data set could be returned to the user who requested the data.

Filtering agents, remote update routines, and long-distance search tools are all examples of how MAPI services can be used to extend the reach of the local workstation to resources at far-away locations. The Windows MAPI services provide excellent tools for building programs that enable users to collect and/or disseminate data over long distances or to multiple locations.

Home ] Up ] Research Utelization ] WOSA ] SAPI ] TAPI ] [ MAPI ] ICA ] Operating Systems ] Prototype ]



Please sign my guest book:

Send mail to with questions or comments about this web site.
Copyright 2001 Engineered Station
Last modified: July 06, 2001

This site is been visited by Hit Counter    surfers