🚀 go-pugleaf

In article <42447@cup.portal.com> David_Dave_Tamashiro@cup.portal.com writes:
>
>It seems that when I compile C (not C++) DLL functions, I have to use
>the PASCAL calling convention or else the linker will not find my DLL's
>in my *.lib file.    I can get around this problem by setting the linker
>to ignore upper/lower case; the code seems to work in any case.

Well, you don't really have to use the PASCAL calling convention.
However, the PASCAL calling convention has the side effect of
uppercasing your symbol names.  You are running into a
case-sensitivity problem (as you no doubt realized).  There are two
switches to govern the various combinations.  TLINK's /c switch
governs whether TLINK will *force to upper case* symbols read in from
PUBDEF, EXTDEF, and COMDEF records -- it /c is set, it won't do this.
TLINK's /C switch governs whether TLINK will *force to upper case*
symbols read in from IMPDEF (import definition) and EXPDEF (export
definition) records, or from symbols in the IMPORTS or EXPORTS section
of the module definition file.  The default, /C-, is to force all
these symbols to UPPERCASE.  So if you use /c /C- (BCC's defaults),
you will run into case-sensitivity problems because your symbols are
in mixed case in the EXE (PUBDEFs, EXTDEFs, and COMDEFs) and the
symbols are in uppercase in the imports and exports.  Thus, there
isn't a match.  If you use /C (to force imports and exports to be case
sensitive), your problem will go away.

Note this weirdness is due to TLINK's notion of case-sensitivity.  As
mentioned above, TLINK forces to uppercase all symbols when treated
case insensitively.  In the TLINK source code, the /c and /C switches
are called "uppercase flags" rather that "case-sensitive" flags.

>I have a question regarding the use of the huge and _export keyword:
>When I  compile C DLL's, do I still have to declare my DLL's 
>as "huge" in my main application code?  I have succesfuly compiled my
>main program(and linked it) using header files which alternatively
>declared my DLL's as "huge" and "_export".  Is the linker going to do
>something strange if it see's the "_export" function prototype in both
>the DLL *.c file and the main app *.c file?

Yes, you need to use "huge" in your EXE and "_export" in your DLLs.
_export implies huge, but has the additional effect of exporting the
member functions (probably only public and protected ones, but I'm not
sure).  What we do here (at Borland) is to define a macro __CLSTYPE__ 
which when compiling for a DLL expands to "_export" and when compiling
for an EXE expands to "huge."  

The reason you need "huge" in the EXE is to force the compiler to
assume far vtable and far this pointers.  This is what the code in the
DLL will be expecting.

>Also, does anyone know why Borland decided to use the huge keyword when
>defining DLL classes?  Whats wrong with the good ole FAR keyword.

I wasn't involved in this design decision, so please don't flame at
me, but... "far" means that the class will be allocated far and thus,
the this pointer is forced to be far.  "huge" means "far", but
additionally, the vtable pointer is forced far.  

>Does
>their huge keyword still mean normalized far pointers (i.e. 1Mbit pointers)
>or does it really mean their  pointers can access 2^32 memory locations?
>  ...And... if it does, who cares??? 

No, huge just means that the vtable pointer and this pointer are 16:16
pointers (far) rather than near.  Note than in the far data models
(compact and large), this will be the case anyway.

-- Eric Swenson (ejs@borland.com)