Hello all!!
I have a kernelmode DLL which exports some classes using __declspec(dllexport). Now I want to change exporttype to NONAME to save size of DLL and drivers which are linked to it.
What I did: I run dumpbin /exports, converted output to apropriate format and created DEF-file.
Then I added NONAME switch to every export (and DATA switch where neccessery).
Then I added this DEF to my project and removed __declspec(dllexport) from declaration of exported classes.
Now if I try to build my DLL, I have “unresolved external error” for every export.
Why this can be? Does __declspec(dllexport) has an influence on decorated names? Or may be I do something wrong?
Thanks in advance.
Vladimir
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>I have a kernelmode DLL which exports some classes using __declspec(dllexport). Now I
want to change exporttype to NONAME to save size of DLL and drivers which are linked to
I know several companies in Russia who will fire a developer for implementing such ideas
(at least for calling GetProcAddress by ordinal) :-)))
Are you short of memory? Or of disk space? You are not writing the embedded software or some low-DOS-memory drivers. For NT kernel
mode binaries, the idea of saving space on PE image exports is surely strange.
How many pages will they take? 2? Or 3?
Exporting classes by __declspec(dllexport) is also a forbidden practice in some teams, who use C++ extensively BTW. “Use
undecorated exports or use COM” - their style.
Then I added this DEF to my project and removed __declspec(dllexport) from declaration of
exported classes.
You was happy that no names clashed after this. C++ allows several functions to have the same names if they differ in signatures.
Nonamed exports do not allow this. 
Why this can be? Does __declspec(dllexport) has an influence on decorated names?
No, but I never saw the successful story of exporting the “extern “C++”” functions via .DEF file.
IIRC .DEF requires C name decoration style, which is achieved by “extern “C”” directive.
If you want undecorated export names - forget about __declspec(dllexport) at all, just write a C function (in C++, declare it
“extern “C””) and list its name in .DEF.
Maybe you will succeed with noname exports too in this case.
Max
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> I know several companies in Russia who will fire a developer for
implementing such ideas
(at least for calling GetProcAddress by ordinal) :-)))
;))
I use implicit linkage to exports only so I dont think exporting by ordinals
is such a bad idea
Are you short of memory? Or of disk space? You are not writing the
embedded software or some low-DOS-memory drivers. For NT kernel
mode binaries, the idea of saving space on PE image exports is surely
strange.
How many pages will they take? 2? Or 3?
Well it’s not critical surely. But I have some spare time (hehe) and I just
tried to implement ordinal exports and faced strange problems. I know it’s
possible and it is the exact way MFC exports classes. Of course my dll is
not MFC but…
Exporting classes by __declspec(dllexport) is also a forbidden practice
in some teams, who use C++ extensively BTW. “Use
undecorated exports or use COM” - their style.
Well… Actually I dont see reasons why not to export classes.
You was happy that no names clashed after this. C++ allows several
functions to have the same names if they differ in signatures.
Nonamed exports do not allow this.
Hmmm… Didn’t get it.
No, but I never saw the successful story of exporting the “extern “C++””
functions via .DEF file.
IIRC .DEF requires C name decoration style, which is achieved by “extern
“C”” directive.
I saw successful story. MFC is the one
If you want undecorated export names - forget about __declspec(dllexport)
at all, just write a C function (in C++, declare it
“extern “C””) and list its name in .DEF.
Of course it is solution when exporting a set of functions. But I want to
export classes
Well I think I have found the reason for “unresolved external error”. I was
wrong when I said that “unresolved external error” was for every export. I
checked this one more time and now I see it was for inline functions only.
So if I remove inline functions from DEF file I think problem will be
solved.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com