3.2.2.2 Main Program Objects

As mentioned above, Cogsys extensions are dynamically loaded in a "two-way" mechanism: not only can the main program call the extension, but the extension can call the main program. Because the Cogsys runtime linker will fixup references to the main program using the `COGSYS3x.BIM' file, the extension writer can access any Cogsys data structure or function with a simple external declaration.

The most common data structure accessed is the gVars[] array, which stores the values of the Cogsys user variables. For example, if we wanted our shape extension to use the contents of Cogsys variable 90 (set by the user with a call to $AV90=20, for example) for the circle of the radius, as opposed to (or perhaps as an alternative to) the passed argument, we could write something like this before the delcaration of the function extension:

extern long gVars[];

And then use gVars as we would any other variable:

case CIRCLE: radius = gVars[90]; ...

We can also use functions that are part of the main program. Normally, functions called are not Cogsys functions, but rather standard C library routines that were statically linked into the Cogsys executable. It is important to remember that the extension is never linked by a standard C linker. The only program than can load it is the Cogsys runtime linker (invoked by the Load Extension Routine command). Just like the C linker will complain if it sees a reference to an object it can't resolve (say, sin() was called without including the math library), so too will Load Extension Routine fail if your extension calls functions that it doesn't know about. Since the only functions it does "know about" are those that were statically linked into the Cogsys executable (or more specifically, those which are listed in `COGSYS3x.BIM', it follows that the only external objects an extension may access must be a part of Cogsys.

Fortunately, because an extension rarely needs a function that Cogsys didn't need, this is rarely an issue. However, several functions are often needed in extensions which aren't a part of Cogsys, most notably sin(), cos() and rand().

To work around this, Cogsys 3.0.15 currently has an internal, unreachable dummy() function which deliberately references these functions. When the Cogsys developer builds the `COGSYS.EXE' executable, dummy() "fools" the Borland C linker into including the code for these functions. They are in turn now available to any extension that needs them.

Future versions of Cogsys will most likely solve this problem more elegantly, either by 1) improving the COGXRG program to attach the code for objects not part of main Cogsys to the extension, or, more ideally by 2) moving to a platform which natively supports dynamically linked libraries. For now, however, the extension writer should be aware that if his code uses a function not part of the main Cogsys program, the Cogsys developer can easily add a call to that function in dummy() and the extension will load.