By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,949 Members | 946 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,949 IT Pros & Developers. It's quick & easy.

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

P: n/a
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.
Apr 18 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a

"2b|!2b==?" <ro**@your.box.comwrote in message
news:wc*********************@bt.com...
>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.
2). How to map them (if any mapping is required) to the names in the def
file.

Apr 18 '07 #2

P: n/a


Ben Voigt wrote:
"2b|!2b==?" <ro**@your.box.comwrote in message
news:wc*********************@bt.com...
>>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.
Surely, there must be a better way than manually going through (copy and
paste?) over 100+ (Class::methods) PER Dll ?

>
>>2). How to map them (if any mapping is required) to the names in the def
file.
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 ?
Apr 18 '07 #3

P: n/a
"2b|!2b==?" <ro**@your.box.comwrote in message
news:of******************************@bt.com...
>

Ben Voigt wrote:
>"2b|!2b==?" <ro**@your.box.comwrote in message news:wc*********************@bt.com...
>>>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.

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

>>
>>>2). How to map them (if any mapping is required) to the names in the def file.

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 <dllnameand add them manually into your DllImports, IMO there is no tools
to do this automatically.

Willy.

Apr 18 '07 #4

P: n/a


Willy Denoyette [MVP] wrote:
"2b|!2b==?" <ro**@your.box.comwrote in message
news:of******************************@bt.com...
>>

Ben Voigt wrote:
>>"2b|!2b==?" <ro**@your.box.comwrote in message
news:wc*********************@bt.com...

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.

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

>>>
2). How to map them (if any mapping is required) to the names in the
def file.


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 <dllnameand 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 ?
Apr 18 '07 #5

P: n/a
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 <dllnameand 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 ?
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.
--
Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"

Apr 19 '07 #6

P: n/a
>
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/Visual...dbackID=100917
Apr 19 '07 #7

P: n/a
On Apr 19, 4:36 pm, "Ben Voigt" <r...@nospam.nospamwrote:
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)?
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

Apr 19 '07 #8

P: n/a
<ad******@club-internet.frwrote in message
news:11*********************@q75g2000hsh.googlegro ups.com...
On Apr 19, 4:36 pm, "Ben Voigt" <r...@nospam.nospamwrote:
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)?

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.
--
Jeff Partch [VC++ MVP]
Apr 19 '07 #9

P: n/a
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 [VC++ MVP]


Apr 19 '07 #10

P: n/a
"Ben Voigt" <rb*@nospam.nospamwrote in message
news:ex**************@TK2MSFTNGP05.phx.gbl...
>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?

--
Jeff Partch [VC++ MVP]
Apr 19 '07 #11

P: n/a
>
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.
Apr 19 '07 #12

P: n/a

"Jeff Partch" <je***@mvps.orgwrote in message
news:eW**************@TK2MSFTNGP03.phx.gbl...
"Ben Voigt" <rb*@nospam.nospamwrote in message
news:ex**************@TK2MSFTNGP05.phx.gbl...
>>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.
>
--
Jeff Partch [VC++ MVP]


Apr 19 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.