|
I know that I should use #pragma comment(linker, "/export:DoSomething=DllImpl.ActuallyDoSomething")
But I have not any explication for it
Thanks
|
|
|
|
|
U should go for dll code injection for stuff like that
Jeffery Richter's Advanced Windows Programming has some nice information on it.
Tanzim Husain
|
|
|
|
|
on 5 Mar '03 bfadi wrote:
I know that I should use #pragma comment(linker, "/export:DoSomething=DllImpl.ActuallyDoSomething")
But I have not any explication for it
This is a little late perhaps,
but
try here for #pragma comment[^]
see here for linker options[^]
Incase the links don't work. I cut the relevant bits from MSDN:
#pragma comment( comment-type [, commentstring] )
Places a linker option in the object file. You can use this comment-type to specify a linker option instead of placing the option on the Link tab of the Project Settings dialog box. For example, you can specify the /include option to force the inclusion of a symbol:
#pragma comment(linker, "/include:__mySymbol")
Syntax
/EXPORT:entryname[=internalname]
With this option, you can export a function from your program so that other programs can call the function. You can also export data. Exports are usually defined in a DLL.
The entryname is the name of the function or data item as it is to be used by the calling program. You can optionally specify the internalname as the function known in the defining program; by default, internalname is the same as entryname.
So you can see that by redefining the internalname to be a call to a function exported by another dll, you can have your wrapper dll export the interface of the other dll(or part of it).
|
|
|
|
|
Thanks very much for the answer , its NOT too late. Its just on time
I have more questions if you have time to help me please.
How can I know the argument of a function exported from a DLL ???????
Like the functions exported from NTDLL.DLL like NTDeleteFile
This function not fount in the DDK ?
Thanks very very much
|
|
|
|
|
I'm afraid that's a bit beyond me to answer.
I can tell you there is no easy was to find out if a function signature
is not documented, what the return type and args are. I think it is usually done by stepping through an assembly at the point of the call and making an educated guess, then testing it.
With regard to NTDLL.DLL if you were just interested in the undocumented
API for this dll in particular you are in luck as it has mostly been revealed at
ntinternals.net[^]
For native API you could start at sysinternals.com[^]
For more dynamic API interception the
Detours[^]
library looks very useful, but one has to know the function signatures.
sorry I can't help any more than this.
|
|
|
|
|
Thanks very much
Fadi
|
|
|
|
|
Are you sure you are really linking dynamically against
the DLL, rather than statically against the LIB?
I downloaded your sample project and looked at your code.
In your DllTestApp.dsp there's a line like this for each
build configuration:
# ADD LINK32 ..\DllTest\Debug\DllTest.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept /libpath:"..\DllTest\Debug"
Naively it looks to me like it's statically linking
against DllTest.lib. I can see that using _declspec
(dllexport) in a class declaration does export everything
from the DLL. But what are you doing to import from the
DLL, besides including the DLL's header file in your
application?
I'm still looking for a way I can export C++ classes from
a DLL and import them into any C++ application.
Otherwise, for the projects I need to develop, it's
almost pointless to use MFC or C++ at all.
|
|
|
|
|
Yes as I can see it´s static. If you look in Project->settings->Link for the program you find this Link under "Object/LibraryModules" ..\DllTest\Debug\DllTest.lib
I am also looking for a nice way to export classes from a DLL (None MFC:s).
It can be done with a wrapper class, but still there must be a better way of doing this... To be cont.....
Jontemannen
|
|
|
|
|
As far I know it is possible to load a class dynamically, but this would mean, you must allocate your own class object at runtime and find a way to handle it. For importing those methods you may use the C++ encoded method name which looks like "??2@YAPAXI@Z" (in this case it's an exported new-operator in global namespace).
But it seems quite complex, so maybe you'd prefer to create a general wrapper class or an interface-like structure (like DirectX does, for example), or create you own reflection API.
If you find a good way.. tell us -.^
--------------------------
xplo.re Project Management
http://xplo-re.com/
http://koushiro.de/
|
|
|
|
|
when compiling the application, use the same header for the class, but instead of using __declspec(dllexport), use __declspec(dllimport)
|
|
|
|
|
Very useful project - thanks.
Could you explain how multiple classes can be included in your project? Also, for a new comer to DLL's could you explain how I tell my program which DLL's to load? Sorry if these questions are too basic
Graham W Griffiths
|
|
|
|
|
You can include as many classes as you want!
All you do is, use the __declspec(dllexport) before the class name, like..
class <pre>__declspec(dllexport)</pre> MyClass {
};
To load a dll, you have to link your application with the dll. The easiest way to do that is to link to the dll's lib file. Just check the sample application.
In the Project Settings->Link->Input, specify the name of the lib file, like in the demo project of the article, that's it!
Regards.
Tanzim Husain
|
|
|
|
|
Can this be done to VB6? Pardon my bliss, but I really don't know how one would start passing an object from a C++ DLL (MFC or otherwise) to a VB object. Might anyone know if this is possible one way or another?
|
|
|
|
|
No. You must use COM in order to do this. The other alternative is to export C functions. C++ uses mangled names and this is C++ compiler-specific and is not recognized by VB.
gs
|
|
|
|
|
Yeah, I got a little further into this problem and ended up making an ATL dll, which worked. So, as you already know, you're right about this. COM i/f here or nuthin.
|
|
|
|
|
I thought it was impossible to export a regular C++ class!!!
Thank you for this info!!
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C# and C++!
|
|
|
|
|
I forgot to give you a !
Rickard Andersson@Suza Computing
C# and C++ programmer from SWEDEN!
UIN: 50302279
E-Mail: nikado@pc.nu
Speciality: I love C# and C++!
|
|
|
|
|
Hi !
Maybe someone could be interested with this post.
If you attempt to export template classes using Visual C++, you may experience, like me, some compilation/linkage problems. A few months ago, I found a solution that works in all cases.
Suppose that you have this template class :
template <class T>
class MyTemplate
{
public:
MyTemplate() { }
~MyTemplate() { }
T m_data;
};
You cannot (I believe ?) export template class that are not "implemented".
All you have to do if you want to export/import an implementation of this template class, for example with type 'int', is to write :
#ifdef EXPORTING // If you are compiling the DLL
template class __declspec(dllexport) MyTemplate <int>;
typedef MyTemplate <int> MyTemplateInt;
#else // If you are using the DLL
extern template class __declspec(dllimport) MyTemplate <int>;
typedef MyTemplate <int> MyTemplateInt;
#endif
That's all !
Now you can use MyTemplateInt class in the program that links with your library.
(P.S. : sorry for my English, I'am French !)
Vincent Richard
http://www.vincent-richard.net/
http://www.kisli.com/
|
|
|
|
|
U know, AFX_EXT_CLASS is a #define for __declspec(dllexport) (and it's the same as AFX_CLASS_EXPORT by the way)
Ohh.. didn't mean to spoil the huge research you've put into this article u know lol
Sorry didn't mean to say that
Marc Richarme
|
|
|
|
|
Actually it can be __declspec(dllimport). It depends weather _AFXEXT, AFXDLL are defined. To be more precise here is a quote from MSDN:
This macro is defined by MFC as __declspec(dllexport) when the preprocessor symbols _AFXDLL and _AFXEXT are defined. But the macro is defined as __declspec(dllimport) when _AFXDLL is defined and _AFXEXT is not defined. When defined, the preprocessor symbol _AFXDLL indicates that the shared version of MFC is being used by the target executable (either a DLL or an application). When both _AFXDLL and _AFXEXT are defined, this indicates that the target executable is an extension DLL.
Best regards,
Alexandru Savescu
|
|
|
|
|
Tanks for enlightening me...
I never use these macros anyway as I mostly make my own #define s (It's much clearer, easier to control, and at least you know it's your fault when something goes wrong), but I guess someone could check against the _DLL predefined macro to make something similar to AFX_EXT_CLASS without MFC.
Cheers, Marc Click to see my *real* signature
|
|
|
|