:Larry Bonham, Xerox Corporation
Dennis E. Hamilton, InfoNuovo
Hitoshi Tanaka, Hitachi Corporation, Ltd.
Changes needed:
- Bring in the newer sections of architectural change proposals and align more with that structure. It will provide a place to mention the library implementation, definition of values, etc.
- Illustrate the basic string-model usage.
- Populate the indicated sections in this version (0.02) of the boilerplate.
Version 0.02 - 2000-02-24 Minor adjustment for published MNCS project on the web (Dennis Hamilton)
- There is still no significant content here. It is a placeholder for further effort.
- The sections were collapsed to those that will require content.
Version 0.01 - 1999-06-09 Original Proposal skeleton (Dennis Hamilton)
- a version of the Architectural Change boilerplate (in HTML) with minor markup for this topic.
Content
1. Functional Overview / Description
2. New/Changed Data Types and Values
3. New/Changed Classes and Properties
4. New/Changed Interfaces
5. Architectural Impacts
6. Reference Materials
7. Existing Systems and Related Experiences
8. Compliance and Conformance Considerations
9. Sample Usage
10. Glossary / Nomenclature
11. Impact on Existing Systems
12. Performance Considerations
13. Backwards Compatibility and Legacy Considerations
14. Incorporation Into DMA Specifications
15. Implementation and Deployment
The MNCS library provides programming support for creation of string-format independent programs that can be built to operate with one MNCS string-format or another simply by changing some macro definitions. The library provides recommended macros and their usage. The use of the MNCS Library is entirely optional. It is implemented and provided so that developers can use a portable, common solution readily available to all of the DMA community.
The MNCS library depends on the MNCS extensions being present. The library is not required for the extensions; the extensions are required for the library.
[remember to point out that the library can also be used without the extensions, but the application must limit itself to the default, DmaString configuration.
point out that the library allows the same source code to be compiled for one or more different string models using the _T suffix and an #include definition.
point out that the library also allows any and all of the string models to be used at the same time, in those applications which find that valuable.
point out that the library also allows a service element to be created that uses multiple string models or that is compiled into different copies from a single source, once for each model to be supported.]
not applicable
not applicable
not applicable. Interface changes are part of the extension proposal.
not applicable.
Thie library is confined to source-language mechanisms that make it easier to select and then conform to one or more string models. The architectural impacts are a consequence of the extensions themselves, not the library.
Note: This material and that of section 5.8 needs to be moved to a different level in the outline, and then addressed separate from Architectural Impact.
to be defined
to be defined
acknowledge the custom for _T modeling of different string models in Microsoft Win32 libraries.
not applicable.
to be defined
to be defined
to be defined (short comment on the impact of recompilation)
no impact (short comment on how the macros employ standard idioms for the functions)
not applicable (point out existing DMASTR usage is preserved and additions are all in the DMA name space)
to be defined
to be defined
$$Author: Orcmid $
$$Date: 00-03-12 12:13 $
$$Revision: 3 $