Win32 and .def files
Erik Funkenbusch -- chucks@isd.net
Monday, October 28, 1996
Environment: Win95 VC++ 4.2b
I see to be running into a problem that i'm finding difficult to explain.
I was wondering if anyone had any ideas about this behavior.
I have an extension dll i've created, orignally i simply exported the
referenced symbols via the .def file. This created a valid .lib file and
everything linked up hunky dory. The problem was, once I tried to
dereference these symbols, i was getting Access Violations left and right.
The assembly output looked like it pointed to valid memory (but it wasn't),
and nothing looked strange (no null pointers, everything was initializing,
libraries were loading).
When I converted over to using __declspec(dllimport)/__declspec(dllexport)
the problem went away. I realize that __declspec is considered to be the
better way of doing things, but the .def method should still work,
shouldn't it?
BTW, the reason i wanted to use the .def file was so i could export
dynamically created classes such as CView derived classes that don't
actually have an object to declare.
Lior Messinger -- 100274.2607@compuserve.com
Wednesday, October 30, 1996
[Mini-digest: 4 responses]
RE: Copy of: RE: Win32 and .def files
"...BTW, the reason i wanted to use the .def file was so i could export
dynamically created classes such as CView derived classes that don't
actually have an object to declare...."
Do you mean "object to instantiate"? You can't export a thing that doesn't
exist... But seriously, you really don't export "an object" (I think. Am I
wrong?). You do export its member functions, and they exist in the code even if
the object is not instantiated.
I don't know aboout the DEF problem. What do you mean by "derefernce" the
exported functions?
Lior.
-----From: Dave_Rabbers@Quinton-Eng.CCMAIL.CompuServe.COM
declspec dllexport is equivalent to exporting in your .def file, though much
easier to do and automatic to maintain. However, you still need to declspec
dllimport when you use the exported stuff. There is no alternative, here. I
think your failure to declspec dllimport caused your errors.
-----From: "David J. Lloyd"
Erik,
Microsoft is trying to get rid of DEF files in win32.
It has been a source of headaches for a many people
(including me). Check Jeffery Richter's book for more
details. There are only 2 situations where you require
a DEF to produce a Win32 EXe or DLL
1.) When you want to use function fowarders
2.) When you want to import a function with a
differe name (not the exported name).
Most of the time, DEF files are no longer needed and should
not be an issue any more.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
David J. Lloyd
Software/Systems Engineer
1960 Bavaria Ste 208
Colorado Springs, CO 80918-8264
e-mail - sdjl@teal.csn.net
-----From: Mike Blaszczak
Using DEF files certainly works. MFC, its own self, uses huge DEF files
to guarantee that all symbols are correctly exported. Putting __declspec()
into the code would make it troublesome for us to build both static and
dynamic versions of the library.
>BTW, the reason i wanted to use the .def file was so i could export
>dynamically created classes such as CView derived classes that don't
>actually have an object to declare.
This donesn't make sense to me. If you have an abstract class, or a
dynamically-created class, you can still export its code--you don't need
to have an instance of a class to generate code for the class.
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
Erik Funkenbusch -- chucks@isd.net
Thursday, October 31, 1996
> -----From: "David J. Lloyd"
>
> Erik,
>
> Microsoft is trying to get rid of DEF files in win32.
I know ;)
> It has been a source of headaches for a many people
> (including me). Check Jeffery Richter's book for more
> details. There are only 2 situations where you require
> a DEF to produce a Win32 EXe or DLL
>
> 1.) When you want to use function fowarders
> 2.) When you want to import a function with a
> differe name (not the exported name).
>
> Most of the time, DEF files are no longer needed and should
> not be an issue any more.
Or when the code you are trying to export is encapsulated in macros in MFC
(ie. CRuntimeClass stuff)
> David J. Lloyd
> -----From: Mike Blaszczak
>
> Using DEF files certainly works. MFC, its own self, uses huge DEF files
> to guarantee that all symbols are correctly exported. Putting
__declspec()
> into the code would make it troublesome for us to build both static and
> dynamic versions of the library.
>
> >BTW, the reason i wanted to use the .def file was so i could export
> >dynamically created classes such as CView derived classes that don't
> >actually have an object to declare.
>
> This donesn't make sense to me. If you have an abstract class, or a
> dynamically-created class, you can still export its code--you don't need
> to have an instance of a class to generate code for the class.
Right, but as i point out above, some of the functions that need exporting
are not available to be mangled with __declspec() tags (ie.
IMPLEMENT_DYNAMIC, IMPLEMENT_SERIAL, etc..)
If you want to export these references, a .def file seems to be the only
way to do it. Now, like i said, using the .def file approach seems to
create a valid import lib, and everything links up without complaint, but
when trying to reference any of the imported symbols defined in the .def
(exported from the dll) i get Access Violations, but any of the
__declspec()ed symbols work just fine.
This makes no sense to me, since this process worked just fine in Win16.
> .B ekiM
Erik Funkenbusch -- chucks@isd.net*
Friday, November 01, 1996
[Mini-digest: 3 responses]
I seem to have solved my own problem, I discovered a strange syntax for
__declspec() that allows you to export the entire class. I had originally
tried this, however I used the syntax "__declspec(dllexport) class blah"
rather than the correct syntax of "class __declspec(dllexport) blah".
While this still does not explain the reason the .def file export method is
causing Access Violations, it at least allows me to get on with my work.
*NOTICE: The return address field of this message has been
altered to prevent spam mailings. When responding, please
remove the * from the end of the address or your mail will bounce.
-----From: Vincent Mascart <100425.1337@CompuServe.COM>
The .def file is not the only to do it. You can export an entire class with
__declspec(), therefore exporting all its members (including those defined in
macros). Sure it's not the best solution, but it works.
Vincent Mascart
100425.1337@compuserve.com
-----From: Mike Blaszczak
-----From: "David J. Lloyd"
> Microsoft is trying to get rid of DEF files in win32.
This simply isn't true.
> Check Jeffery Richter's book for more
> details.
Which Jeffery Richter book? He's written three or four different
titles. Where, specifically (that is, in which book and on which
page?), does he say that "Microsoft is trying to get rid of .DEF files"?
>There are only 2 situations where you require
> a DEF to produce a Win32 EXe or DLL
> 1.) When you want to use function fowarders
> 2.) When you want to import a function with a
> differe name (not the exported name).
There are many others:
3) When you want to export a name from a module based on an alias
4) When you want to export by ordinal only
5) When you want to export a private function
6) When you want repeatable control over which ordinal your function uses
> Most of the time, DEF files are no longer needed and should
> not be an issue any more.
I very strongly disagree: for most cases, a .DEF file is actually
far easier to use than the variaous __declspec() tricks.
-----"Erik Funkenbusch" wrote:
>Right, but as i point out above, some of the functions that need exporting
>are not available to be mangled with __declspec() tags (ie.
>IMPLEMENT_DYNAMIC, IMPLEMENT_SERIAL, etc..)
Yes, they are. Look, try this:
1) Open the IDE
2) Use the "CLose Workspace" command in the "File" menu
3) Use the "New" command in the "File" menu
4) In the resulting "New" dialog, pick "Project Workspace" and press "OK"
5) In the resulting "New Project Workspace" dialog, select a project
"Type" of "MFC AppWizard (dll)".
6) Choose a nice name. I typed "XPORTS". Press "Create"
7) Press the "Finish" button.
8) Press "OK" in the resulting confirmation dialog.
9) The project will have a main CPP file. For me, it was named
XPORTS.CPP. Open it.
10) Into that file, paste this code:
// --- START OF CODE YOU SHOULD PASTE ---
class __declspec(dllexport) CMyClass : public CObject
{
public:
CMyClass();
~CMyClass();
DECLARE_SERIAL(CMyClass)
};
IMPLEMENT_SERIAL(CMyClass, CObject, 0x001)
CMyClass::CMyClass()
{
}
CMyClass::~CMyClass()
{
}
// --- END OF CODE YOU SHOULD PASTE ---
11) Build your project using the "Build" command in the "Project" menu.
12) Get to a command prompt. Get to your project's built DLL. Mine
was in MSDEV\PROJECTS\XPORTS\DEBUG.
13) Type:
dumpbin -exports xports.dll
where, of course "xports.dll" is actually the name of your DLL.
You'll find that the internal-Get functions provided by MFC's
DECLARE_SERIAL() macro are properly exported for you.
>If you want to export these references, a .def file seems to be the only
>way to do it.
I think using a .DEF file is the preferred way to do this, but that's just
me.
>(exported from the dll) i get Access Violations, but any of the
>__declspec()ed symbols work just fine.
I'd say that you're doing some other thing wrong. Maybe you're incorrectly
importing the symbols, maybe something's wrong with the library your linking.
>This makes no sense to me, since this process worked just fine in Win16.
It works just fine in Win32, too. Look at MFC its own bad self: it exports
all this hidden information for all the appropriate classes. That is,
MFC somehow gets what you're saying "doesn't work" to work a couple of hundred
times every time somebody links to MFC42.DLL--which is pretty damned often.
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
| Вернуться в корень Архива
|