Path: utzoo!attcan!uunet!isc-br!tau-ceti!cims2!proto!joe From: joe@proto.COM (Joe Huffman) Newsgroups: comp.sys.ibm.pc.programmer Subject: Re: Using Turbo C with libraries compiled with Microsoft C Summary: It is possible for libraries to work across compilers. Message-ID: <1306@proto.COM> Date: 7 Jun 90 17:47:37 GMT References: <10760@medusa.cs.purdue.edu> <1990Jun4.205834.13661@cbnewsc.att.com> <2533@dataio.Data-IO.COM> Organization: Prototronics; Sandpoint, Idaho Lines: 59 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: > tjr@cbnewsc.att.com (thomas.j.roberts) writes: > < 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