This is a fairly important first step, since if affects which features you can rely on and the extent to which you need to include conditional logic to support different runtime (or even compile-time) environments. At one extreme, you may want to maintain both compile and runtime compatibility across AMOS, UNIX (including dumb serial terminals), as well as Windows, taking advantage of GUI improvements only where appropriate. In this case you have to avoid using any language statements that won’t compile under AMOS, as well as including "IF TEXT THEN X ELSE Y" or similar conditional logic for runtime decisions on GUI versus text mode functions. You also have to avoid the use of SBX routines, unless you are willing to write AMOS equivalents in assembler.

At the opposite extreme, you may decide you only care about the Windows environment, in which case you can use every GUI enhancement available (and can skip the rest of this topic).

Somewhere in the middle are those that no longer care about AMOS compatibility, or who are willing to compile under A-Shell even run AMOS runtimes. If you don’t need AMOS compatibility even at runtime, then you should probably take advantage of SBX routines as much as possible to encapsulate the details of text vs. GUI methods. If you do need AMOS runtime compatibility, you can’t use SBX routines (unless you are willing to write them in AMOS assembler), but might use a scheme involving different sets of ++INCLUDE modules for different environments. If you don’t mind compiling under A-Shell and moving the RUN files to AMOS, then you can use TPRINT and DPRINT. The following table summarizes some of the compatibility relationships between features and environments.