If your message store provider allows read-only access to the underlying storage mechanism, then client applications and the MAPI form manager will be unable to do certain things. Specifically, clients will be unable to add or modify custom views, and the MAPI form manager will be unable to install forms in the associated contents tables of the store's folders.
For many read-only message stores, that may not be a problem. If that is the case, then the message store provider does not need to support associated contents tables at all. However, if your message store provider must be read-only and it must also support a predefined set of views or forms, then it will need to support associated contents tables.
The most common strategy for doing this, since clients and the MAPI form manager cannot install the views or forms into the message store themselves, is for the message store provider to hard-code them into the message store. This means that the associated contents table or tables containing the views or forms will exist in the message store when it is created, before any clients or the MAPI form manager ever access it. Then, when a client requests an associated contents table to get custom views from a form or the MAPI form manager requests an associated contents table in order to launch a form, the message store provider can provide one.
This requirement that the associated contents tables be created and populated when the message store itself is created implies that your message store provider will need to obtain information about the format of the special messages that clients and the MAPI form manager use in order to store views and forms. What those formats are will depend on the client and MAPI form manager being used, and so a description of them cannot be provided here. If you do not have access to that information, it is very likely that you will have to reverse engineer those formats from existing message stores that have views and forms installed into them. The MAPI SDK includes a utility called MDBVIEW.EXE which you can use to view the properties and their values of objects in message stores to help with this reverse engineering.
The danger in implementing forms and views by reverse engineering the form and view descriptor format of a MAPI client is that if the client changes that format when it is upgraded, the forms and views in your message store will no longer function. This problem will persist until a universal format for form and view descriptors, defined by MAPI, is available. For this reason, reverse engineering form and view descriptors should only be done as a last resort.