As is the case when any independent software modules are combined into a single program, care must be taken that on entry a module saves the state of the current environment and sets up its own defaults. The original environment must then be restored on exiting from the module. This applies to saving and restoring registers when making a subroutine call no more than saving and restoring (parts of) the GKS State List and Workstation State Lists when entering a graphics module. For example, two modules of graphics code may use the same Normalization Transformation indices. If module B sets different windows and viewports than module A, then on re-using routines in A after calling module B the transformations will no longer produce the expected results.
GKS provides a mechanism to handle this situation in the form of a large set of inquiry functions. These enable a module of code to inquire at run time the values of those parameters it intends to modify in order that they may be correctly restored afterwards. In particular, functions exist to inquire attribute values and bundle table entries, values of the aspect source flags, and the normalization and viewing (for GKS-3D) transformations corresponding to a particular normalization or view index. As an example:
----
REAL WINDOW(4)
REAL VIEWPT(4)
----
C Inquire current window and viewport for Transformation Number X
C
CALL GQNT(TNX, ERRIND, WINDOW, VIEWPT)
CALL GSWN(TNX, WXMINA, WXMAXA, WYMINA, WYMAXA)
----
C Restore window which was modified for Transformation Number X
C
CALL GSWN(TNX, WINDOW(1), WINDOW(2), WINDOW(3), WINDOW(4))
----
If several modules of code which are to be combined use GKS segments then
clearly they must not both attempt to use the same segment names.
Either one can agree before hand on the allocation of a range of names
to each module, or else code can be written which assigns segment names
at run time after checking that the values are not in use
(see section on Page 
).