🚀 go-pugleaf

In article <1990Mar11.013335.875@pds3> I asked:
>On a 386 using MSC5.1 and ndmake, can compile all modules (Large model,
>Compact gave >64K text error).  When linking, get:
>LINK: error L2029 Unresolved externals: _MK_FP in dos.c
>
>What's up?  I do all my normal compiling in unix.... Help!

I got answers from:
uunet!calvin.wa.com!richard (Richard Brittain) who said:
---------------------------------
MK_FP is a macro that generates a far pointer, given segment and offset as
the two (int) arguments - so it is pretty trivial
#define MK_FP(seg,ofs) (void far *)((unsigned long)(seg) << 16)|(unsigned)(ofs))

(plus or minus a few parens, but you get the idea)
How did you compile it when it has to include "ascii.h" which was missing
in the distribution (at least in what came to my site) ?
---------------------------------
AND
uunet!gtenmc!pilchuck!rwing!pat (Pat Myrto)  who said:
---------------------------------
What is happening with the _MK_FP is that somewhere in the code is a
call to a macro that (from the name) takes arguments (probably a
segment and an offset) and combines them to make a proper far pointer
that the compiler uses.  It happens that such a macro is not included
in the MSC header files for the MSC compiler.  On UNIX, at least most
systems, where ints are 32 bits, and pointers are also 32 bits, this
need to have far and near pointers doesn't exist like it does with the
segmented addressing scheme of the 8086, 80186, and 80286 chips (the
80386 chip and its 32 bit ints make the 'small' model capable of
addressing in the many megabytes, unlike the 64k limit for a segment
imposed by the pre-80386 chips).

What follows should work (you might need to modify it for your
situation).  I have no idea why Microsoft didn't include such a macro
in the dos.h file, they have the macros for the reverse operations,
FP_SEG, and FP_OFF which respectively return the segment and offset
portions of a far pointer.  The backslash after the #define line is
just to enhance readability - the macro has to look like one line to
the compiler (hence the 'hidden' line break via the backslash)  The
two only differ in the TYPE of pointer returned - the older standard
for generic pointers was to use (char *), but more recent stuff uses
the (void *).  Use whatever your compiler uses.  I think char * is
more portable - since all compilers grok that, but older ones don't
know about void *

Don't change the name to _MK_FP - that is what the compiler does to
all external references - prepend the underscore.  The missing
'function' link is looking for is indeed MK_FP - when it wasn't
defined in the source, the compiler naturally assumes it is a
reference to another module or the library, and generates the _MK_FP
name as an 'extern' reference, and link not finding it anywhere,
produced the error message you saw.  I would suggest either placing
the macro in dos.h next to the FP_SEG and FP_OFF macros in there, so
it will be available for future use (although it isn't used very
often) - usually if one needed to build a far pointer, it was just
done in the code.

/* macro def for MK_FP for compilers that don't grok void pointer */
#define MK_FP(seg, ofs) \
	((char far *) (((unsigned long) (seg) << 16) | (unsigned) (ofs)))

/* macro def for MK_FP for later compilers, such as MSC 5.x */
#define MK_FP(seg, ofs) \
	((void far *) (((unsigned long) (seg) << 16) | (unsigned) (ofs)))

Select the one that is appropriate.
---------------------------------
AND
uunet!beaver.cs.washington.edu!sumax!ole!ray (Ray Berry) who said:
---------------------------------
	from the TC dos.h file:
#define MK_FP(seg,ofs)	((void far *) \
			   (((unsigned long)(seg) << 16) | (unsigned)(ofs)))
---------------------------------
AND (lastly)
uunet!fluke.com!dcd (David Dyck) who said:
---------------------------------
MK_FP is a turbo C function that creates a far pointer given segment and offset.
---------------------------------

I did create a MK_FP macro in stevie.h, but the compiler still choked...now
because of "unsigned integer constants" (or something real close, anyway).
Upon examining the code, I discovered that the MK_FP macro only applied if the
machine was a TI-PRO (never happen here), so I just commented out the TI-PRO
cases.

I used the ascii.h from my XENIX 386 /usr/include/dos directory (after a bit of
massaging) to fake the missing ascii.h file.

Thanks for everyone's help.
-- 
==============
Robert A. Earl
uunet!pds3!bob