Using a standard library

Using a standard library

The reason that porting software from one environment to another is often complicated and time consuming is the difference in run-time library support. If a common set of system calls were available and only this set was used by the compiler to interface to the operating system, it would be very easy to move software across from one platform to another — all that would be required would be a simple recompilation. In addition, using a common library would take advantage of common knowledge and experience.

If these improvements are so good, why is this not a more common approach? The problem is in defining the set of library calls and interface requirements. While some standards have appeared and are used, such as UNIX System V interface definition (SVID), they cannot provide a complete set for all operating system environments. Other problems can also exist with the interpretation and operation of the library calls. A call may only work with a 32 bit integer and not with an 8 or 16 bit one. Others may rely on undocumented or vaguely specified functions which may vary from one system to another, and so on. Even after taking these considerations into account, the ability to provide some standard library support is a big advantage. With it, a real-time operating system can support SVID calls and thus allow UNIX software to be transferred through recompilation with a minimum of problems.

There have been several attempts to go beyond the SVID type library definitions and provide a system library that truly supports the real-time environment. Both the VMEexec and ORKID specifications tried to implement a real-time library that was kernel independent with the plan of allowing soft-ware that used these definitions to be moved from one kernel to another. Changing kernels would allow application soft-ware to be reused with different operating system characteris-tics, without the need to rewrite libraries and so on. The POSIX real-time definitions are another example of this type of ap-proach.

It can be very dangerous to pin too much hope on these types of standards. The first problem is that they are source code definitions and are therefore subject to misinterpretation not only by the user, but also by the compiler, its run-time libraries and the response from the computer system itself. All of these can cause software to exhibit different behaviour. It may work on one machine but not on another. As a result, the use of a standard library does not in itself guarantee that software will work after recompilation and that it will not require major engineering effort to make it do so. What it does do, however, is provide a better base to work from and such work should be encouraged.