You can also control the mangling of exported names to various
degrees through .def files (totally) or the "  EXTERN "C" "
specifier (partially), etc.

The MS Developer Network is a good place to start.
Also, I have half a dozen VC++ books and all the large ones
have good sections on building DLL's. (Unfortunately, they
tend to focus examples on the complicated COM stuff it sounds like
you are interested in (type libraries, and what not), rather than the
simpler interfaces I wanted ;)

- Matt

In the past I have hooked C DLL's created in MS Visual C 1.5 to VB 4
programs.  Now I have to do the same with VB and VC 5.  

I have heard some rumors that this is not easy now since VC 5 mangles even
the straight C function names.  What is happening?  How do you get around
the name mangling?

Is VB 5 still restricted to only calling C functions and not C++ objects?

Bart Torbert

Bart -
    It's not that hard.  Yes, using the _stdcall convention, required by VB,
does result in exported names that are "decorated" (not mangled), but the
decoration is simple and predictable, and easy to get around.

    If you can control the build of the DLL, just make sure that the exported
functions use the _stdcall convention, and that the build environment
includes a DEF file naming the exported functions.  The decoration will
disappear, and the functions can be DDeclared and called just as they're
named.

    If you can't control it, you can use the decorated name in an Alias
clause in the VB Declare.  Decoration is simple: the base function name

of parameters.  So a function named Bart that takes one string and one long

--
     Jim Mack
     MicroDexterity, Inc
     PO Box 5372
     Plymouth, MI  48170-5372

     http://www.microdexterity.com

     Fax:  +1 734-453-8942

Bart;
    Jim is right. I usually use a DEF file so the names are
more aesthetically pleasing, but you can always alias
if you prefer.
    Regarding your question about VB still being restricted to
calling C functions and not C++ objects, if the object is
a COM object, VB can use it. If your talking about MFC
class objects in DLLs, no, VB can't and probably never will.
    C++ class objects really aren't meant to be exported
via DLLs; it can be done in VC++, but it has problems
even across versions of VC++, let alone different languages.

--
Ron Ruble
Raffles Software Development, Inc.