Directives for software development on non-platform systems.
A set of directives that will facilitate the porting of software developed on non-Ithaca systems to the Ithaca platform.
1. Realism in the art of programming.
The idea of having a platform for the project is for ensuring portability of the developed code. For this reason the platform was chosen to be a "standard" UNIX system, supported be different vendors. Applications running on the platform will be able to compile and run in (almost) any System V implementation, plus merging System V and BSD, like for example the SUN UNIX.
Although a UNIX platform has been selected for the Ithaca project, it is unlikely that software development will always take place on it. Most likely software will be developed on non-platform systems, and will then be ported on the platform for testing. In this scenario one of the major concerns of the programmer will be to ensure that the developed software conforms to the platform. This can be a very simple task, requiring just some minor modifications to be done on the original code, or an impossible one, requiring major modifications of the code and maybe of its logic, depending whether some simple directives were followed or not. Although these directives are well known and understood by any programmer, it would be useful to remind them once more. The idea behind these directives is that, if followed, software developed on non-platform systems should be portable on the platform, without any changes on the code. The most that it would be needed would be some simple changes of definitions in the makefile(s).
2. To do or not to do.
The following directives describe the most important things that you should and should not do, when developing software on non-Ithaca platform systems.
1. Use a standard version of C. The differences between ANSI C and the K&R C are
small, but enough to make you go all over your code and start changing procedure
declarations. The best way would be to use the K&R C, since ANSI C accepts old
style procedure declarations. If you need to have ANSI C programs I can provide
you with a program that automatically extracts from C sources the declarations
(procedure stubs) needed for ANSI C.
Similarly, if you use C++ verify which compiler version you have. The official C++ compiler for the platform is the GNU C++ release 1.36.1. If you do not have it, please ask for it! Note that the AT&T C++ rel. 1.2 compiler is upwards
Systems Group X June 25, 1990
Directives for software development on non-platform systems. Page 2
compatible with the GNU C++ compiler. That is, programs compiled with the AT&T C++ will, in general,?. compile with the GNU C++ compiler but not vice versa.
2. The X windows libraries provide a standard programming package. You can use them freely without any (or almost any) concern for conformance. Just remember that the official X package for the platform is X11 Rel. 3.
3. Use the programming manuals of the platform rather than those of the system onto which you develop your software. This way you will avoid using utilities not existing on the platform, plus you will be using the correct syntax and semantics for all system calls.
4. Use ifdefs whenever the functionality is different on the Ithaca platform and on the system you develop your software.
5. Do not use software packages that are not part of the platform (!). If you have to use them, then make sure they can be ported on the platform and distributed to the partners.
6. Do not base your programs' logic on features that are not supported by the platform. For example, "light weight processes" are now part of many UNIX systems but are not supported by the platform.
7. If your program makes use of some software that is available on your development system but not on the platform, do not say "I will find a way to port this latter". Try to port it before you start developing your application. Chances are that this package will not be trivially portable to the platform.
8. If you have doubts whether a feature is supported or not by the platform, feel free to ask. If you cannot ask, then do not use it!
9. Beware of the problems that might arise due to architecture dependencies, like byte ordering and alignment. Do not use "smart" tricks which are based on implicit assumptions of the arhitecture. For example, cashing of types, size and contents of structures etc.
? One problem that we are aware of is that the combination of X11R4 and GNU C++ (release 1.35, 1.36 and 1.37) cannot compile on a SUN workstation. This problem does not come up if X11R4 is used or the AT&T C++.
Systems Group X June 25, 1990