Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!umich!samsung!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.sys.ibm.pc.programmer
Subject: Re: Using Turbo C with libraries compiled with Microsoft C
Message-ID: <2533@dataio.Data-IO.COM>
Date: 6 Jun 90 02:17:21 GMT
References: <10760@medusa.cs.purdue.edu> <1990Jun4.205834.13661@cbnewsc.att.com> <1990Jun5.134159.9577@ux1.cso.uiuc.edu>
Reply-To: bright@Data-IO.COM (Walter Bright)
Organization: Data I/O Corporation; Redmond, WA
Lines: 42

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.
<<1)	TC returns 4-byte results in AX/DX;
<This I have no idea about.
<< MC uses AX/BX 
<WRONG!!! Microscoft C uses AX/DX

Zortech also uses AX/DX. In fact, Zortech follows exactly MSC's segment
conventions, register saved/destroyed conventions, return value conventions
(including struct returns), Pascal conventions, etc. The only difference
is in floating point returns, ZTC's is different in order to make it
reentrant.

This is not enough, however, to make a 3rd party MSC library work with ZTC.
Trouble areas are:
1.	Using floating point.
2.	Depending on 'compiler helper' functions in the rtl, like long divide.
3.	Depending on the exact size and layout of the _iob[] struct in
	stdio.h (they're different between most compilers). This can cause
	very subtle crashes.
4.	Using undocumented internal MSC library functions.
5.	Depending on non-standard behavior of library functions (like
	strange things in printf format strings).

This is not to say it's impossible. For example, ZTC programs can use
the Microsoft Windows SDK libraries and the OS/2 PM libraries. This
works because I made it work. It's just that you can't casually do this.

Sometimes, people try and make things work by linking in *both* the MSC
runtime libraries and the ZTC runtime libraries. This is nearly always
doomed to failure, the usual result is lots of multiply-defined symbols
from the linker. Even if it linked successfully, just imagine what would
happen when you get some modules thinking _iob[] has one layout talking
to other modules thinking something else... not a pretty thing to do
to your hard disk!

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.