#exports/DLL's
8 messages in this thread
I've looked at that. I have exported some class libraries now. Things appear
to be working. Now ny concerns are that I am in for entirely to much work if I
try to use Microsofts CObject container classes. The problem none of there
stuff is exported therefore I cannot compile my classes to export them.
Therefor I cannot get a map file mangled name to use in my def file and remove
the _export.
I am in the middle of a frustrating experience. I cannot _export
my subclasses of CObject because they are not _export. I cannot export classes
containing CString's because CString's are not exported.
So how can I really export with class???
Mike
Concievably, you could rebuild MFC and _export all of the classes, and then you
would be able to export derived classes. But, unfortunately, MS says this is a
no go. In fact as you have noticed they manually _export member functions by
ordinal number. I don't know of a good solution other than to look at some
alternative to exporting the classes.
Michael
Mike,
If anyone is interested, I've written an AWK script that allows you to somewhat
painlessly built the exports section of a DEF file for a DLL that has
MFC-derived classes (ie. MFC extension DLL).
JT
JT
Please post that baby, I think we could use it and maybe there are others.
Michael
Mike,
Okay, here is the AWK script. It takes a map file for an argument and outputs
the exports section (with comments) of the DEF file EXPORTS section.
I don't know how to Upload to a library using TapCIS so this will have to do
unfortunately…
———- # # EXPORT.AWK # # # # command line arguements: #
# fp=1 -> filter private
functions of a class # fp=2 ->
filter private and protected functions of a class # #
fr="<regular expression>" -> filter based on regular
expression # # fd=1 ->
filter global data objects # fd=2 ->
filter global data objects except CRuntimeClass information for C++ objects # #
fo=1 -> filter 'new' and 'delete' operators # #
fv=1 -> filter virtual function table entries #
#
$1 == "Address" && $2 == "Publics" && $4 == "Name" {
print "; EXPORT.AWK output using directives:\n;\t\t" "fp=" fp ";\tfr='"
fr "';\tfd=" fd ";\tfo=" fo ";\tfv=" fv "\n;\n"
Inside = 1
getline }
Inside == 1 && $1 ~ /[0-9]+:[0-9]+/ && $2 != "Imp" && $2 ~ /\?/ {
#print alias first
funcDescriptor = "\t\t" $2
getline
funcAlias = LTrim($0)
if ( PassedFilterTest( funcAlias ) )
print ";\t" funcAlias "\n" funcDescriptor "\n" }
Inside == 1 && $1 == "Address" {
Inside = 0 }
# – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
function LTrim( str ) {
sub(/^[ \t]+/, "", str)
return str }
function PassedFilterTest( str ) { # fp=1
-> filter private functions of a class
if ( fp == 1 || fp == 2 )
if ( str ~ /^([thunk]:)*private:/ )
return 0
# fp=2 -> filter private
and protected functions of a class
if ( fp == 2 )
if ( str ~ /^([thunk]:)*protected:/ )
return 0
# fd=1 -> filter global
data objects
if ( fd == 1 )
if ( str !~ /\(.*\)/ )
return 0
# fd=2 -> filter global
data objects except CRuntimeClass information for C++ objects
if ( fd == 2 )
if ( str !~ /\(.*\)/ && str ~! /CRuntimeClass.*::class/ )
return 0
# fr="<regular expression>" ->
filter based on regular expression
if ( fr != "" )
if ( str ~ ek )
return 0
# fo=1 -> filter 'new' and
'delete' operators
if ( fo == 1 )
if ( str ~ /operator new/ || str ~ /operator delete/ )
return 0
# fv=1 -> filter virtual
function table entries
if ( fv == 1 )
if ( str ~ /\`vftable\'/ )
return 0
return 1 } w
Hi Michael,
> Concievably, you could rebuild MFC and _export all of the classes,
> and then you would be able to export derived classes. But,
> unfortunately, MS says this is a no go. In fact as you have noticed
> they manually _export member functions by ordinal number. I don't
> know of a good solution other than to look at some alternative to
> exporting the classes.
PMJI, I know MFC TechNote #33 doesn't go into a lot of Detail as to why
"class _export" syntax was not used for MFC250x.DLL. It states:
Using "class _export" may be a viable alternative for
building smaller DLLs, but in the case of a large DLL
like MFC, the default exporting mechanism has
efficiency and capacity limits.
The efficiency limit is the function name lookup speed. A function
can be found in a DLL's exported names table much more quickly
if it is exported by ordinal rather than by name (note that the
"class _export" syntax exports member functions by name).
The capacity limit is referring to the 64K limit on a module's
resident name table. If all of the MFC classes were exported
using "class _export" syntax then the name table would be filled
beyond capacity.
Best Regards,
Don Schmitt
Microsoft Developer Support
Don
Thanks for the detailed explanation.
Michael
Hi Mike,
> …The problem none of there stuff is exported therefore I cannot
> compile my classes to export them. Therefor I cannot get a map file
> mangled name to use in my def file and remove the _export.
A map file will show the decorated names of your classes regardless
of whether you mark them with _export. Maybe I am misunderstanding
you here?
Best Regards,
Don Schmitt
Microsoft Developer Support