| 2 |
7u83 |
1 |
<!-- Crown Copyright (c) 1998 -->
|
|
|
2 |
<HTML>
|
|
|
3 |
<HEAD>
|
|
|
4 |
<TITLE>TDF and Portability: Conclusions</TITLE>
|
|
|
5 |
</HEAD>
|
|
|
6 |
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
|
|
|
7 |
<A NAME=S51>
|
|
|
8 |
<H1>TDF and Portability</H1>
|
|
|
9 |
<H3>January 1998</H3>
|
|
|
10 |
<IMG SRC="../images/no_next.gif" ALT="next section">
|
|
|
11 |
<A HREF="port4.html"><IMG SRC="../images/prev.gif" ALT="previous section"></A>
|
|
|
12 |
<A HREF="port1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
|
|
|
13 |
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
|
|
|
14 |
</A>
|
|
|
15 |
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
|
|
|
16 |
<HR>
|
|
|
17 |
|
|
|
18 |
<H1>4. Conclusions</H1>
|
|
|
19 |
The philosophy underlying the whole TDF approach to portability is
|
|
|
20 |
that of separation or isolation. This separation of the various components
|
|
|
21 |
of the compilation system means that to a large extent they can be
|
|
|
22 |
considered independently. The separation is only possible because
|
|
|
23 |
the definition of TDF has mechanisms which facilitate it - primarily
|
|
|
24 |
the token mechanism, but also the capsule linkage scheme.<P>
|
|
|
25 |
The most important separation is that of the abstract description
|
|
|
26 |
of the syntactic aspects of the API, in the form of the target independent
|
|
|
27 |
headers, from the API implementation. It is this which enables the
|
|
|
28 |
separation of target independent from target dependent code which
|
|
|
29 |
is necessary for any Architecture Neutral Distribution Format. It
|
|
|
30 |
also means that programs can be checked against the abstract API description,
|
|
|
31 |
instead of against a particular implementation, allowing for effective
|
|
|
32 |
API conformance testing of applications. Furthermore, it isolates
|
|
|
33 |
the actual program from the API implementation, thereby allowing the
|
|
|
34 |
programmer to work in the idealised world envisaged by the API description,
|
|
|
35 |
rather than the real world of API implementations and all their faults.<P>
|
|
|
36 |
This isolation also means that these API implementation problems are
|
|
|
37 |
seen to be genuinely separate from the main program development. They
|
|
|
38 |
are isolated into a single process, TDF library building, which needs
|
|
|
39 |
to be done only once per API implementation. Because of the separation
|
|
|
40 |
of the API description from the implementation, this library building
|
|
|
41 |
process also serves as a conformance check for the syntactic aspects
|
|
|
42 |
of the API implementation. However the approach is evolutionary in
|
|
|
43 |
that it can handle the current situation while pointing the way forward.
|
|
|
44 |
Absolute API conformance is not necessary; the TDF libraries can be
|
|
|
45 |
used as a medium for workarounds for minor implementation errors.<P>
|
|
|
46 |
The same mechanism which is used to separate the API description and
|
|
|
47 |
implementation can also be used within an application to separate
|
|
|
48 |
the target dependent code from the main body of target independent
|
|
|
49 |
code. This use of user-defined APIs also enables a separation of the
|
|
|
50 |
portability requirements of the program from the particular ways these
|
|
|
51 |
requirements are implemented on the various target machines. Again,
|
|
|
52 |
the approach is evolutionary, and not prescriptive. Programs can be
|
|
|
53 |
made more portable in incremental steps, with the degree of portability
|
|
|
54 |
to be used being made a conscious decision.<P>
|
|
|
55 |
In a sense the most important contribution TDF has to portability
|
|
|
56 |
is in enabling the various tasks of API description, API implementation
|
|
|
57 |
and program writing to be considered independently, while showing
|
|
|
58 |
up the relationships between them. It is often said that well specified
|
|
|
59 |
APIs are the solution to the world's portability and interoperability
|
|
|
60 |
problems; but by themselves they can never be. Without methods of
|
|
|
61 |
checking the conformance of programs which use the API and of API
|
|
|
62 |
implementations, the APIs themselves will remain toothless. TDF, by
|
|
|
63 |
providing syntactic API checking for both programs and implementations,
|
|
|
64 |
is a significant first step towards solving this problem.<P>
|
|
|
65 |
<!-- FM pgf ignored -->
|
|
|
66 |
[1] <I>tcc User's Guide</I>, DRA, 1993.<BR>
|
|
|
67 |
[2] <I>tspec - An API Specification Tool</I>, DRA, 1993.<BR>
|
|
|
68 |
[3] <I>The C to TDF Producer</I>, DRA, 1993.<BR>
|
|
|
69 |
[4] <I>A Guide to the TDF Specification</I>, DRA, 1993.<BR>
|
|
|
70 |
[5] <I>TDF Facts and Figures</I>, DRA, 1993.<BR>
|
|
|
71 |
[6] <I>TDF Specification</I>, DRA, 1993.<BR>
|
|
|
72 |
[7] <I>The 80386/80486 TDF Installer</I>, DRA, 1992.<BR>
|
|
|
73 |
[8] <I>A Guide to Porting using TDF</I>, DRA, 1993.<BR>
|
|
|
74 |
[9] <I>The TDF Notation Compiler</I>, DRA, 1993.<P>
|
|
|
75 |
<!-- FM pgf ignored -->
|
|
|
76 |
<HR>
|
|
|
77 |
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
|
|
|
78 |
Copyright © 1998.</I></P>
|
|
|
79 |
</BODY>
|
|
|
80 |
</HTML>
|