1.3 Domino s platform independence

---

1.3 Domino's platform independence

Questions are sometimes asked about differences in features and functions of Domino on various platforms; these questions might be phrased as:

• "What do I lose if move Domino to a non-Windows operating system?"

• "What do I gain if I run Domino on a UNIX-type operating system?"

The answer is: nothing; that is, Domino is full-functioned and platform-independent across all platforms. We asked a Domino developer to comment on this in more detail; he responded with an explanation in two parts: source code, and application environment.

1.3.1 Domino source code

The Domino source is made up of multiple layers of code. The top-most layers of code are platform-independent and are developed on whichever architecture the developer is most familiar with (UNIX, PC, or Mac), and tested on all architectures. These layers use no platform-specific code.

There is another layer which is client-side only, and this is coded on Windows with an emulation layer providing the identical functionality on the Mac.

Finally, there is the OS-specific layer. This layer consists of a platform-independent API which is coded and created for each supported architecture of Domino, and gives Domino access to features which are platform-dependent in a platform-neutral behavior.

For example, OSLoadProgram is used by Domino to load a program with no knowledge of the underlying architecture. The code for OSLoadProgram itself abstracts out the architectural differences to the caller, even though it itself is doing platform-specific operations. When Domino is ported to an additional platform, it is this OS layer which must be ported and which is the majority of the development work for the port. (There are always exceptions to this, usually specific to compiler behaviors.)

Of significant note, it can actually be the QE effort which takes up the largest amount of time during a port due to the fact that the entire product must be tested on the new platform, and with millions of lines of code, this can and does take a considerable amount of time.

1.3.2 Domino API application porting

The complexity of porting a Domino C/C++ API application to a new platform is for the most part dependent on how the program was initially designed and created. If the program was created in such a way as to use the Domino OS layer API for all of its access to platform-specific functionality, then the development portion of the port should be minor.

It is when API programs use platform-specific code within their product instead of using the Domino OS API that the development portion of the port becomes a major effort. For example, if instead of using the Domino OSMemoryAllocate() API to obtain shared memory, a program uses the native platform API, then this will have to be ported to each separate architecture/platform, as it does vary greatly.

One other item of complexity to porting between platforms concerns the compilers and flags needed to build Domino. Lotus is working on making this easier by providing a text file as part of the SDK includes which would include all compilation information—OS levels, compiler levels, compilation flags, and linker flags. In the meantime, this information is nestled somewhere within the SDK documentation.

Once again, it can actually be the QE effort that takes the largest amount of time during a port (if the application has been coded to use the Domino OS layer; otherwise, development can take longer). This is due to the fact that the entire application must be tested on the new platform which can take a considerable amount of time, depending on the size of the application.

---