From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!eos!aurora!labrea!decwrl!decvax!savax!winters
From: winters@savax.UUCP (Ada Bozo)
Newsgroups: comp.lang.ada
Subject: Re: Protection for Ada Binary Libraries
Message-ID: <699@savax.UUCP>
Date: 25 Feb 88 03:39:43 GMT
References: <324@ajpo.sei.cmu.edu> <1238@wayback.UUCP>
Organization: Sanders Associates Inc., Nashua, NH
Keywords: Ada, Libraries, Protection
Summary: Using VAX Ada for "binary" Ada releases.
List-Id: <comp.lang.ada>


I have recently faced a similar problem that I have only partially solved with
VAX Ada. Suppose that one wanted to provide a "subsystem" of packages to a
client where only a small set (perhaps only one) of the packages is "visible"
to the client. Such things as graphics support routines, database management
routines, and, even, the CAIS come to mind. Normal delivery of source code
to be compiled into the client's program library is out of the question. Can
the VAX Ada compiler and Ada Compilation System (ACS) provide any help?

My (partial) solution: tell VAX Ada to create a partially linked object module
containing the internal view of the subsystem via "ACS EXPORT" (making VAX Ada
think that the module will be called by a non-Ada program), and then compile
a "shell" of the subsystem and install the body of the previously linked
object (making VAX Ada think it is "importing" a non-Ada program). Thus, the
client can compile against the source code of the shell while linking against
the object code of the body. Example:

	package INTERNAL is
	   procedure INTERFACE;
	   pragma export_procedure (INTERFACE, "XXX_INTERFACE");
	end INTERNAL;
	package body INTERNAL is
	   procedure INTERFACE is
	   begin ... end INTERFACE;
	end INTERNAL;

$ ADA INTERNAL
$ ACS EXPORT INTERNAL

	package EXTERNAL is
	   procedure INTERFACE;
	   pragma interface (INTERFACE, ADA);
	   pragma import_procedure (INTERFACE, "XXX_INTERFACE");
	end EXTERNAL;

$ ADA EXTERNAL
$ ACS LINK EXTERNAL INTERNAL

This last command provides a mechanism to link against a specified object
file. (Yes, I know that I can also "install" the object file as the body
of the shell package EXTERNAL but I'm at home without my VAX Ada RM.) The
problem with this approach is two-fold. First, I (as developer) must maintain
two versions (INTERNAL and EXTERNAL) of the same interface. Second, the
VAX/VMS linker complains about "multiple definitions" because the first
(partial) link brings in many Ada pieces that are also brought in during
the second link. However, it appears that I can now ship the EXTERNAL
definition and the INTERNAL object file without requiring either the 
full source code or, for that matter, the Ada program library with all of
the internal symbol tables and object files to be shipped to the client.

Has anyone else tried this approach using VAX Ada and the ACS? Are there
better solutions using the ACS and/or the VAX/VMS linker? I don't have any
experience with other vendor library/linker mechanisms to know if this
approach works but clearly I am becoming VAX Ada dependent by using the
pragmas "import_procedure" and "export_procedure". However, sometimes
pragmatics must outweigh concerns for compilation system independence.

Daryl Winters
(603) 885-9226

uucp: decvax!savax!winters
arpa: winters@ajpo.sei.cmu.edu