🚀 go-pugleaf

In article <1992Aug11.195534.3249@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
>Rather than edit the .h files (which gets messy if the headers are
>updated in the future - you'd have to re-update them), it's easier to
>define them as "C" in your application like this:
>
>extern "C" {
>  #define ....
>  #include <os2.h>
>}

Actually, if you are using gcc/2 as your C++ compiler, it is unneccesary
to use extern "C" {} since the header files already solve this problem
for both C and C++ by explicit use of the asm directive.

[All extern "C" does is remove the type-safe linkage (i.e. name mangling)
 from the functions listed within the curly brackets.  But since gcc
 expects there to be no underscores in front of symbols, and DLLs have no
 underscore, gcc comes with header files that explicitly name (via the
 asm directive) the symbols that represent each function.

 For example for DosOpen you will see a line in the header file that looks
 something like:
	ULONG DosOpen(woof, woof) asm("DosOpen");
 This line tells gcc C that DosOpen is represented by the symbol "DosOpen"
 rather than the normal "_DosOpen".

 For gcc C++, it tells the compiler to use the symbol "DosOpen" instead of
 the crazy name-mangled C++ name that would be used by default.
]

Disclaimer: This probably is not true for EMX/GCC, but since I don't use EMX,
except for Emacs :-), I can't say for sure.
-- 
Colin Jensen (cjensen@ampex.com)