5. ENVIRONMENT: UNIX, DOS, MAC

OrgC/C++ is highly portable, and requires only minor changes when running in different environments. The file environ.h, which contains only several #define statements, specifies the hardware, operating system, and the compiler for the whole system. You cannot recompile the library without properly setting this file. If your environ.h file is incorrect, you will get numerous strange errors when compiling or trying to use the library.

Typically, you need a different environ.h file for the main orgc directory, and for orgc/lib. The class generator/preprocessor and utility programs are written in C (both the K&R and ANSI forms are available). The file in orgc/lib/environ.h specifies the environment under which you plan to use the library. If you plan to use the library with C, you have to recompile it under C. If you plan to use C++, you have to recompile the library under C++.

In the environ.h file, the first define specifies the operating system: #define UNIX, #define DOS,  or #define MAC.

The second define specifies the hardware:  #define SUN, #define HP, #define AMDAHL, #define APOLLO, #define IBM (for RS6000).

The third define specifies the compiler: #define GNU, #define BORLAND4, or #define MICROSOFT7. When running with C++, three more defines are usually used:

#define ZZcplus .... specifies C++
#define ZZansi .... specifies ANSI standard
#define ZZ_INHERIT .... inheritance or member object

When using large memory model under DOS, you define:

#define LARGE_POINTER

Chap.8 describes all of the available options in more detail.

When porting to a new compiler, the key decision is on how to paste tokens. Look at the file lib/heading.h and select your defines depending on which of the macros ZZ_PASTE1 ... to ZZ_PASTE4 works with your compiler. If you change heading.h, you have to rerun zzcomb, which recreates zzcomb.h.

The directory orgc/lib contains all library source files, plus numerous env*.h files for various possible environments. It also contains script files that compile the library under different environments. If you look into those files, you will see which env*.h files they use.

Knowing the naming conventions will help you orient yourself in this relatively busy directory. The libraries are named in the following fashion:

File environ.h

The environment file describes the environment in which you are using the library: The operating system, physical computer, compiler, language (C or C++), memory model, and other parameters. Normally, the library administrator keeps a default file environ.h in the orgc/lib directory, which is then used by all programmers within the project or department. If you don't have the environ.h file in your current directory, all programs are automatically compiled with the default environment from orgc/lib/environ.h. However, if you have environ.h in your working directory, it overwrites the version in orgc/lib.

It is essential to have a correct environ.h file. If you have wrong defines, you get many strange compile errors. If you are starting with OrgC/C++ and you have a problem running the first test, first look at your environ.h files.

The directory orgc/lib contains many ready-to-use environment files; you have only to select the appropriate one and copy it into your current directory as environ.h. The names of these files relate to the environment for which they were designed. For example:

env0s.h	for C on SUN
env3z.h	for ZORTECH C++
env3g.h	for C++ using the GNU compiler
env3h.h	for the full HP C++
env3ca.h	for the latest version of BorlandC++
envmsft.h	for Microsoft Visual C++

and so on.

If you run with SUN 2.1 (or 3.0) compiler, modify files env0s.h, env1s.h, env2s.h, and env3s.h by replacing #define SUN with #define SUN2_1 (or #define SUN3_0).

If you are not sure which file to use, look at orgc/lib/readme or at the script files for the regression tests (next paragraph).

Examples of the environ.h file:

For Microsoft Visual C++ under Win95:

#define DOS
#define MICROSOFT8
#define LARGE_POINTER
#define ZZcplus
#define ZZansi
#define ZZ_INHERIT

For GNU on a SUN, using C++:

#define UNIX
#define SUN3_0
#define GNU
#define GNUPLUS
#define ZZansi
#define ZZcplus
#define ZZ_INHERIT

For Borland C++ Ver.4.5, medium memory model:

#define DOS
#define BORLAND4
#define ZZcplus
#define ZZansi
#define ZZ_INHERIT

For ZORTECH C++, large memory model:

#define DOS
#define ZORTECH
#define LARGE_POINTER
#define ZZcplus
#define ZZansi
#define ZZ_INHERIT

For AT&T C++ Ver.2.1 on a SUN

#define UNIX
#define SUN2_1
#define ZZcplus
#define ZZansi
#define ZZ_INHERIT

If you are running with C++ but using structures and not classes, the following statment will make your program more efficient:

#define ZZnoFriends

Testing your setup.

Your new orgc/test directory contains examples of script files for running the preprocessor/class generator and for compiling a single program (files try1 and ctry2, gtry2, or htry2 for UNIX, and files such as try1.bat, try2.bat, btry2.bat, or ztry2.bat for DOS). Before using these files, check that (inside these files) the compiler is called with a path reflecting your individual installation.

• Get the appropriate environment file

• Can you run the class generator?

cd test
try1 test0m

• Can you compile with OrgC++?

• Are the results correct?

Important

The preprocessor/code generator must be called with full pass (absolute or relative). For example:

..\zzprep test0m.c
or
c:\orgc\zzprep test0m.c
or
/home1/orgc/zzprep test0m.c

If the path is not given zzprep cannot operate properly and prints a message about an internal error in function ZZgetMaster(). Having the orgc directory is not sufficient in this case.

Regression tests

The orgc/test directory contains scripts for long regression tests that run over 60 programs that test all of the features currently in the library. These tests are gradually expanding with the library.

The tests are different for C and C++, and also differ slightly between different compilers. For example, the UNIX tests sometimes use larger data sets than the DOS tests limited by the 64k data space, or some tests are excluded because the DOS compilers choke on them (not enough space).

These regression tests are the ultimate test of your installation, but may take a long time to run (1/2hour on SUN SPARC2, up to several hours on an IBM 386, but just a few minutes on a Pentium). Each script invokes one test after another, compiles and runs it, and then compares the result (file res*) with the correct expected output (file out*).

If you start a regression run, watch for the first couple of test passes. If everything looks fine, you may leave the test running without supervision and when it is finished, you invoke a special script file that checks the results:

Expected output (files out*) may sligthly differ for different compilers or memory models. For example, you may find:

WARNING: Regression script files are quite long and, without a memory extender under DOS, their execution may be interrupted in the middle of a run because one of the DOS system limits is reached. If that happens to you, it still does not mean that your installation is wrong. Split the batch file into several sections, and run each separately.

Within each test run, file environ.h is reset several times. When splitting the batch file, make sure that environ.h is correctly set at the beginning of each section.

Examples of regression tests

Checking the results:

 ... and so on (replace `regr' by `chk' or `check')

Warning:

The environment file must not contain conditional defines. For example, the following sequence will not do what you may expect:

#ifdef ABC
#define ZZansi
#endif

Regardless whether ABC is defined or not, the code generator will work as if ZZansi is defined.

Chapter 4: OrgC++ Directories

Chapter 6: What is OrgC++?