🚀 go-pugleaf

In article <2533@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) writes:
> In article <1990Jun5.134159.9577@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
> <In article <1990Jun4.205834.13661@cbnewsc.att.com> tjr@cbnewsc.att.com (thomas.j.roberts) writes:
> <<There are several (many ?) differences between Turbo C and Microsoft C.
.
.
.
> In other words, the most practical courses of action are:
> 1. Only buy libraries that come with source, and recompile it for the
>    compiler you're using.
> 2. Call the library vendor and request a version for the compiler you're
>    using.

One thing that I expected Walter to say but didn't, is that it is
possible for library vendors to supply a single library that will work 
across MSC, TC, and Zortech C/C++.  This is not possible in all cases, but in
many it is.  Walter had suggested I do this (and provided considerable help)
with the graphics library that is shipped with Zortech C/C++ (we have since
removed this feature, it now only works with Zortech).  It is also
possible to make this single library work with all memory models.

The basics of the procedure for doing this is:

1) Use patchobj (from Zortech) on all .OBJ modules to remove references to 
the memory model the library was compiled under and default library searches.

2) Declare all functions and pointers as 'far'.  Compile the library in
"Large" memory model.

3) Provide all your own low level functions.  Have NO unresolved externals
from your library (use libunres supplied by Zortech to find them).
This is a subtle problem, because the compiler generates function calls for 
things you didn't explicitly call, like long arithmetic.  I achieved this
by compiling my library with Zortech C and includeing the run time long
arithemetic module (with the functions renamed) in my library.  Use  
patchobj to rename all the long arithmetic functions to the new names. 

Hints, warnings, etc:

In the FG graphics library I had to supply a few odds and ends functions
like strcpy() and strcmp(), etc.  These were either made static or given
a new name (like fg_strcmp()).  If I had needed file I/O I would have had to
go directly to DOS and bypass the standard runtime library.  The math
library (sin(), pow(), etc) would be a major code size hit if it had been
necessary to duplicate them.  Fortunately my application didn't need this.  
Another major thing to watch out for is memory allocation.  Do you need 
malloc() and siblings?  Walter built in support for special versions in the 
runtime libraries for this, but it wouldn't be difficult for third party 
vendors to have their users supply the hooks for this.

I explain this with the hope that more third party vendors to support more 
compilers (especially Zortech of course).  It wasn't really that hard, and
all the strange stuff (patchobj) is handled in the makefile once it is 
figured out.

-- 
joe@proto.com
uunet!proto!joe
FAX: 208-263-8772