XCMD ANSI Library
Volume Number: 6
Issue Number: 6
Column Tag: Programmer's Forum
By Gerry H. Kenner, David Burggraaf, Salt Lake City, UT
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
[Gerry Kenner is a conservative senior citizen who has been working with
computers and writing scientific papers since 1962 when the era first began. David
Burggraaf is a newcomer to the field who got his first computer (a Sinclair) in 1980
and hasn’t stopped being excited since. Suffice it to say that most of the ideas and all of
the work involved in this project were done by David.]
With their fixed methods of entering, retrieving and manipulating data, code
resource packages appear to be the ideal system of object oriented programming. In
this case, the object is the code resource. The popularity of this concept is shown by
the use of code resources under different names by 4th Dimension™(external objects),
Excel™ (DDLs) and Hypercard™ (XCMDs and XFCNs). Further, pioneer systems for
using code resources in standalone programs are becoming available, the first example
being Serius89™ but other programs are not far behind.
A problem with this type of programming is that the libraries must be replicated
whenever they are used in different code resources. Further, when doing code
resources at least some compilers link in all functions in a library and not just the
ones being used. This is in contrast to the smart linking which occurs when standalone
applications are generated. Experience has shown us that the size of most code
resources can be reduced by 50% while some can be reduced by as much as 70% or
more if the library routines are removed.
This paper reports on a method for installing the libraries and a jump table to
access them as a separate code resources and then using a simple series of calls to
access them from other code resources (Hypercard XCMDs in this case).
The Project
The project consisted of putting all the library functions in two code resources of
type “LIB “ called CodeLib and FCodeLib. Two code resources were used because the
dispatch routines for functions which return arguments longer than 32 bits are
different from the cases where the return value will fit in register D0. Included in
each library is the code of the library functions and a dispatch routine (main()) to
provide access to them. The “LIB “ type resources are loaded into Hypercard or stacks
using ResEdit.
The .h file
The CodeLib.h file includes the necessary definitions and macros for setting up
the libraries in XCMD projects. Included are the list of index variables for each
function call (i.e., CLatoi, CLatol, etc.), macro definitions for redefining return
parameters and library function call names (#define atoi(str) ((**idispatch)
(CLatoi,(char*)(str))), and typedef void (**Vfunch) (CodeLib,...);, etc.) and the
macro calls which are added to the XCMD project for incorporating the above material
in source code.
Perhaps the best method for understanding the contents of this file is to follow
the compilation and execution of the main routine of the XCMD following the addition of
the special library code. First of all, the contents of CodeLib.h are read in. In addition
to declaring the macros and index variables, this file defines the handles VFunch,
IFunch, etc and declares extern global variables of these types (dispatch, idispatch,
etc). When executed the macro CODELIB legitimitizes the extern declaration of these
variables by declaring them within the XCMD.
LOADCODELIB() is a function which appears as follows when unfolded.
/* 1 */
LOADCODELIB()
if (!initCodeLib())
return;
else
HLock(dispatch);
if (!initFCodeLib())
HUnlock(dispatch);
return;
else
HLock(ddispatch);
Its function is to determine whether the libraries are present, get handles to
them and then lock the handles so the libraries won’t move. Otherwise it returns with
nothing being done. The task of getting the handles is done by initCodeLib() and
initFCodeLib. The initCodeLib macro is expanded to show how this is done.
/* 2 */
initCodeLib()
fdispatch = (Ffunch)GetResource(‘LIB ‘, 18000);
pdispatch = (Pfunch)fdispatch;
cdispatch = (Cfunch)pdispatch;
ldispatch = (Lfunch)cdispatch;
idispatch = (Ifunch)ldispatch;
dispatch = (Vfunch)idispatch;
Note that all the handles point to the same address.
With the above code in place, execution of a code line such as
/* 3 */
TempInt = atoi(TempStr);
will result in the following at compilation time.
/* 4 */
TempInt = ((**idispatch)(CLatoi, (char*)TempStr)));
When executed, this code will pass the address of idispatch, the value of the index
CLatoi and the contents of TempStr to the library code resource.
A Special Case
An exception to the above ease of use are function calls such as sprintf which pass
variable numbers of arguments. In these cases, the definitions in the CodeLib.h file
serve as templates for inserting the code manually. For instance, the definition of
sprintf(s,f) is ((**idispatch)(CLsprintf, (s), (f), ...)). When a statement such as
sprintf(TempStr, “Good Day”) is encountered the programmer must replace it
manually with ((**idispatch) (CLsprintf, TempStr, “Good Day”) using the definition
as a guide.
CodeLibDispatch.c
This file shares the CodeLib.h file except it does not include the NOCODELIB
definitions for redefining the library function call names. Addressing the library
functions is taken care of by declaring the following code before the main routine is