Exporting C++ classes as ordinals (via a def file)

[2b|!2b==?]

I want to export my C++ classes in a DLL, using ordinal # - rather than
by name. Will anyone care to enumerate through the steps required to do
this?

I am already failiar with exporting classes and symbols (both C++ and C)
from a DLL. In the case of C functions, i also know how to export them
by ordinal # - my main problem revolves around how to do the ff:

1). Obtaining the mangled names from the C++ DLL
2). How to map them (if any mapping is required) to the names in the def
file.

 

[Ben Voigt]

I want to export my C++ classes in a DLL, using ordinal # - rather than by
name. Will anyone care to enumerate through the steps required to do this?

I am already failiar with exporting classes and symbols (both C++ and C)
from a DLL. In the case of C functions, i also know how to export them by
ordinal # - my main problem revolves around how to do the ff:

1). Obtaining the mangled names from the C++ DLL

Dependency Walker is your friend.

 

[2b|!2b==?]

Dependency Walker is your friend.

Surely, there must be a better way than manually going through (copy and
paste?) over 100+ (Class::methods) PER Dll ?


Do I use the same decorated names in the .def file, or do I need to
"munge" (i.e. transform) the names into something else using another
tool for example ?

 

[Willy Denoyette [MVP]]

Surely, there must be a better way than manually going through (copy and paste?) over 100+
(Class::methods) PER Dll ?



Do I use the same decorated names in the .def file, or do I need to "munge" (i.e.
transform) the names into something else using another tool for example ?

Are you talking about class members? If yes, stop here, you can't call methods from managed
code, only C style exports can be called via PInvoke, you need to wrap them in managed
classes using C++/CLI.
If you are talking about C style functions, you'll have to find the export ordinals using -
dumpbin /exports <dllname> and add them manually into your DllImports, IMO there is no tools
to do this automatically.

Willy.

 

[2b|!2b==?]

Are you talking about class members? If yes, stop here, you can't call
methods from managed code, only C style exports can be called via
PInvoke, you need to wrap them in managed classes using C++/CLI.
If you are talking about C style functions, you'll have to find the
export ordinals using - dumpbin /exports <dllname> and add them manually
into your DllImports, IMO there is no tools to do this automatically.

Willy.

Hmmm, neither of the above. I'm not using C# (I was under the impression
that this was a C++ specific ng). This is a C++ only framework.

I am already exporting my classes etc by name - but I want to export the
classes using ordinal numbers (for consumption by other C++ projects).

As I mentioned before, I already know this involves using .def file
(again I have experience of using def files to export C functions by
ordinal). My SPECIFIC question is how may I export C++ classes by
ORDINAL #, for use in other C++ libraries ?

 

[Guest]

Do I use the same decorated names in the .def file, or do I need to

Hmmm, neither of the above. I'm not using C# (I was under the impression
that this was a C++ specific ng). This is a C++ only framework.

I am already exporting my classes etc by name - but I want to export the
classes using ordinal numbers (for consumption by other C++ projects).

As I mentioned before, I already know this involves using .def file
(again I have experience of using def files to export C functions by
ordinal). My SPECIFIC question is how may I export C++ classes by
ORDINAL #, for use in other C++ libraries ?

Hi,

Maybe I am missing something, but why would you want to export by ordinal if
you are going to use it in other C++ projects anyway?
Why don't you simply export your C++ class by name?

Classes are nothing but a collection of functions. A class does not really
exist in binary, only mangled functions do.
To export by ordinal you'd have to somehow export each member by ordinal in
the correct order, and hope that you never have to insert a new member
because therwise the ordinals will all be messed up.
I don't think this is possible at all.

 

[Ben Voigt]

Hi,

Maybe I am missing something, but why would you want to export by ordinal
if
you are going to use it in other C++ projects anyway?
Why don't you simply export your C++ class by name?

Classes are nothing but a collection of functions. A class does not really
exist in binary, only mangled functions do.
To export by ordinal you'd have to somehow export each member by ordinal
in
the correct order, and hope that you never have to insert a new member
because therwise the ordinals will all be messed up.
I don't think this is possible at all.

I think the problem is going to be *importing* the functions by ordinal, is
there some syntax akin to __declspec(dllimport, ordinal)?

Certainly, as long as the ordinals are assigned manually, the "insert a new
member" problem goes away. Indexes are certainly a feasible way to call
member functions because this is how COM works, it's an index into the
v-table instead of into the import table, but as long as you can control the
ordering and preserve it across versions, that should protect you against
changes in the name-mangling convention between compiler versions as long as
the calling convention doesn't change. And name-mangling changes are
coming, because they're needed to fix
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=100917

 

[adebaene]

I think the problem is going to be *importing* the functions by ordinal, is
there some syntax akin to __declspec(dllimport, ordinal)?

Indeed. It would be usefull if the OP explained us how it intends to
*use* this DLL in client code, because I do not believe it would be
possible to call methods on those classes using normal C++ syntax.
It would probably be possible to import them as "C" style functions,
and call them by passing explicitely the "this" argument, but I do not
see any interest to the exercise.

Btw, one should also consider other aspects, such as stack unwinding
across a DLL boundary in case of exception....

Arnaud
MVP - VC

 

[Jeff Partch]

Indeed. It would be usefull if the OP explained us how it intends to
*use* this DLL in client code, because I do not believe it would be
possible to call methods on those classes using normal C++ syntax.
It would probably be possible to import them as "C" style functions,
and call them by passing explicitely the "this" argument, but I do not
see any interest to the exercise.

Btw, one should also consider other aspects, such as stack unwinding
across a DLL boundary in case of exception....

I don't have any experience doing it, but it's got to be possible as the MFC
dlls do exactly this: export the class member functions using
[decorated_fname @ ordinal NONAME] in a def file, and I assume the import
libs take care of the linking requirements.

 

[Ben Voigt]

I don't have any experience doing it, but it's got to be possible as the

MFC dlls do exactly this: export the class member functions using
[decorated_fname @ ordinal NONAME] in a def file, and I assume the import
libs take care of the linking requirements.

Entries in import libraries are resolved based on the linker matching the
mangled name, but the mangled name is prone to change even when the function
signature is compatible.

 

[Jeff Partch]

I don't have any experience doing it, but it's got to be possible as the
MFC dlls do exactly this: export the class member functions using
[decorated_fname @ ordinal NONAME] in a def file, and I assume the import
libs take care of the linking requirements.

Entries in import libraries are resolved based on the linker matching the
mangled name, but the mangled name is prone to change even when the
function signature is compatible.

But wouldn't that be the same situation either with named exports or
NONAME'd ordinals?

 

[2b|!2b==?]

I don't have any experience doing it, but it's got to be possible as the MFC
dlls do exactly this: export the class member functions using
[decorated_fname @ ordinal NONAME] in a def file, and I assume the import
libs take care of the linking requirements.

Thi sis precisely what I intend to do - from the info on the MS website
and comments so far, I think the way forward is to use dumpbin to obtain
the mangled names for use in the def file.

 

[Ben Voigt]

I don't have any experience doing it, but it's got to be possible as the
MFC dlls do exactly this: export the class member functions using
[decorated_fname @ ordinal NONAME] in a def file, and I assume the
import libs take care of the linking requirements.

Entries in import libraries are resolved based on the linker matching the
mangled name, but the mangled name is prone to change even when the
function signature is compatible.

But wouldn't that be the same situation either with named exports or
NONAME'd ordinals?

If there was a __declspec(dllimport, ordinal) notation, it would be
independent of mangling changes between compiler versions.