From: kagel AT quasar DOT bloomberg DOT com
Date: Wed, 20 Nov 1996 14:17:23 -0500
Message-Id: <9611201917.AA04207@quasar.bloomberg.com >
To: panosts AT hiway DOT gr
Cc: djgpp AT delorie DOT com
In-Reply-To: <199611201954.RAA03155@cosmos.hiway.gr> (panosts@hiway.gr)
Subject: Re: DJGPP-to-Borland Compatibility.
Reply-To: kagel AT dg1 DOT bloomberg DOT com

   From: "Panos Platon Tsapralis" <panosts AT hiway DOT gr>
   Date: Wed, 20 Nov 1996 17:55:41 +0200

	   While trying to recompile, using DJGPP, a program, that was originally
   written in Borland-C++, along with some data-base & screen management
   libraries, I encountered error messages that indicate that DJGPP lacks
   functions like "ltoa" ( long-to-ascii ), "ultoa" ( unsigned-long-to-ascii
   ), "MK_FP" ( unknown - could not find in the Borland manuals anything about
   this function ), which admittedly are specific to the Borland's
   implementation of C/C++.


ltoa  -- you can substitute itoa() since on DJGPP an int is a long or like:
ultoa -- got to bite the bullet and use sprintf()
MK_FP -- This was a macro that took a 16bit memory segment and offset and
	returned a pointer.  Just #define this to take the offset only and
	return it.  Also not FP_SEG and FP_OFF which broke a pointer returning
	a segment or offset respectively.  These should be #defined such that
	FP_SEG returns zero(0) and FP_OFF just returns the pointer.  This will
	work together with MK_FP as defined.  Note that MOST of the code using
	these three macros will have to be rewritten as these are usually used
	to access physical memory addresses on expansion cards.  This cannot
	be accomplished in the same way in DJGPP due to the 32bit Virtual 
	Memory.  Read the FAQ for details in various sections (including
	section 18 which I believe deals with accessing expansion card memory
	buffers).  [BTW- MK_FP stands for make-far-pointer.]

Have fun.

-- 
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com

A proverb is no proverb to you 'till life has illustrated it.  -- John Keats