🚀 go-pugleaf

In article <1990Jun4.205834.13661@cbnewsc.att.com>, tjr@cbnewsc.att.com (thomas.j.roberts) writes:

> 1) TC returns 4-byte results in AX/DX; MC uses AX/BX (float/double
> 	are returned in 8087 Top-Of-Stack register). This will make any
> 	large-pointer function misbehave dangerously, and will give
> 	erroneous results from any long function.

This is not the case.  Both compilers return long/large pointers in DX:AX


> 2) TC and MC use different names for the various segments.
> 	This will probably prevent it from linking properly (except for
> 	huge model programs), and will cause subtle errors in a
> 	huge-model program.

Since TC 1.5, Borland have been using identical segment naming conventions
to Microsoft.  Besides, they can be changed in TC to suit.


> 3) TC and MC package library routines differently, so you cannot
> 	use both the MC and the TC run-time libraries. If the third-party
> 	library depends upon the MC run-time library, this may cause
> 	link and/or run-time problems.

By and large, they are similar.  The problem really arises in the "help
functions" used by the compiler for, say long division, multiplication
and shifting.  They are named and called differently and each library
compiled with it's own compiler will of course use only it's version.


> 4)	TC and MC have different requirements for subroutines to preserve
> 	register contents. This will cause a serious disaster during
> 	execution (write-protect those disks before executing!).

Not at all true.  Both compilers require preservation of _only_ DS, SI,
DI and BP.


> 5) The TC run-time library screws around with the console hardware
> 	(even if you don't call any of its TEXT or GRAPHICS routines);
> 	this can often be minimized by setting directvideo=0.

Which has little to do with the compatibility between compilers...


david

-- 
  Unique Computing Pty Ltd, Melbourne, Aust.
  david@csource.oz.au  3:632/348@fidonet  28:4100/1@signet