 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Using Interfaces with Dlls |
|
 |
ironfroggy Member since: 6/6/2000 From: USA |
|||
 Posted - 1/22/2004 6:22:35 PM |
||||
| I don't get it, what advantages are there here over using COM? If a project used this kind of custom-interface and then at one point had need of some COM interface (like, anything in DirectX maybe?) two interfacing models would have to be used. Or, if anything developed in the project, like some AI system perhaps, was extracted for use in other projects, those other projects would have to learn to use this custom interfacing code. This is what standards are for, people. The article is pointless. |
||||
|
||||
|
uchyenik Member since: 2/4/2005 From: USA |
|||
|
Posted - 2/4/2005 1:42:45 AM |
||||
| I haven't tried it, but perhaps this concept is portable to other OS's? |
||||
|
||||
|
stimarco Member since: 4/11/2000 |
|||
|
Posted - 2/4/2005 9:45:36 AM |
||||
Quote: The DLL concept is platform-neutral. Linux, *BSD, MacOS X, Windows and, yes, even the Commodore Amiga's own OS support DLLs in some form or another. Platform-specific interfaces to this functionality need to be catered for, but it's usually fairly trivial to have cross-platform code using #define blocks. (Assuming you're using C or C++.) A Dynamically-Linked Library is exactly what it says on the tin. Its advantage is that you can create smaller software downloads if you're sure the end user will already have the requisite DLL files on his computer. (The alternative is statically-linked libraries.) The COM technique we see in so many Microsoft APIs is built on top of the DLL mechanism. In a nutshell, it is really just an additional vtable -- in assembly programming terms, a "jump table" -- in front of a DLL's own vtable. The idea is that you can create different versions of a library without worrying about breaking old code when you change the API. COM is a Windows-specific take on a the "DLL Versioning" concept. It has analogues on other operating systems, but it is much more common in Windows development. It's generally harder and more complex to work with if you're working with the older Win32 and MFC APIs. (The .NET architecture supports a modified version of COM, COM+, at a fundamental level, so it's a lot easier to work with on that platform.) For many games, which rarely need to worry about long-term maintenance issues, COM is overkill. Windows games tend to use COM more than DLLs simply because the various DirectX libraries can and do change over the lifetime of a game. However, COM isn't common on Linux and console programming. (Linux games tend to use a lot of static or DLLs. Even OpenGL is often available in both static and DLL form.) Given that modern consoles _do_ have an actual, bona-fide operating system on them, it's worth remembering that you will have to deal with library management on those as well. (The XBox, for instance, actually has a heavily modified version of Windows in it, although even that eschews COM for its DirectX-derived libraries. I believe they reverted to DLLs for the DirectX API in XBox as it's not going to be updated during the lifetime of the console.) Understanding how DLLs work is also a good route to understanding the additional layer of complexity introduced with COM. Learn the first and the second makes a lot more sense. -- Sean Timarco Baggaley |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 4/9/2005 2:27:47 PM |
||||
| That was very usefull for me. Thanks. But there was one little mistake in the code: In the clientcode there is almost at the end: if(pfnFree != 0) pfnFree(&hMyDll); But it should be: if (pfnFree != 0) pfnFree(&pInterface); You are freeing the interface there, not the library. The library is released one line later with FreeLibrary. ----- Odyne |
||||
|
||||
|
Malchivus Member since: 9/5/2003 From: Scotland! |
|||
 Posted - 7/22/2005 10:48:57 AM |
||||
heya ... I'm trying to do something simmilar, ie;
typedef struct interface {
virtual void foo(void)=0;
virtual const char* name( void ) = 0;
} interface;
class poo : public interface
{
const char* name(void) { return "foo is my name"; };
void foo(void) { printf( "foo you.\n" ) };
};
exportDLLfunc interface* makeClass(void)
{
return new poo;
}
but the return value of name is absolute garbage ... any idea why? **OOPS!** actualyy it was working, but i was trying to print the results with _snprintf and i meant to use _vsnprintf [Edited by - Malchivus on July 30, 2005 8:48:42 AM] |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 8/18/2005 8:46:58 AM |
||||
| I am looking into this method, as I am having problems in borland with a class in dll. It seems I throw an access violation error on the use of delete. I am not using this method as desribed in the article but if I can thrash it out I might see if it solves my problem. I am using "__declspec (dllexport)" to export the class. It works unless I use new or delete on the class, then bang. |
||||
|
||||
|
thanhnv Member since: 12/28/2004 |
|||
|
Posted - 9/6/2005 8:22:30 AM |
||||
hey, everyone ! I have some question about article: and I have some "*.h" and "*.cpp" below: ////////////////////////////////////////////////// ///////============ cs_crsunrise.h =====///////// ///////// file in your dll //////// /////////////////////////////////////////////// #ifndef CS_CRSUNRISE_H #define CS_CRSUNRISE_H #ifdef CSDLL_EXPORTS #define CSDLL_API __declspec(dllexport) #else #define CSDLL_API __declspec(dllimport) #endif class CSDLL_API CSCrSunrise { public: CSCrSunrise(); ~CSCrSunrise(); int GetLibrary(); int Run(); }; CSDLL_API extern CSCrSunrise Application; #endif =======> next file /////////////////////////////////////////////////////// //////////========= cs_crsunrise.cpp =======////////// ////////// file in your dll ////////// //////////////////////////////////////////////////// CSDLL_API CSCrSunrise Application; int CSCrSunrise::GetLibrary() /// call here ..... int CSCrSunrise::Run() /// call here ..... when I press F5, my program created "*.dll" and "*.lib" normally and using "dll" and "lib" test the program ran normally. but while I was creating "*.dll" and "*.lib". there are four warning below: + CSCrSunrise::CSCrSunrise : inconsistent dll linkage + CSCrSunrise::~CSCrSunrise : inconsistent dll linkage + CSCrSunrise::GetEngine() : inconsistent dll linkage + CSCrSunrise::~CSCrSunrise : inconsistent dll linkage You can get idea about warning or get any suggestions about above any idea and suggestions very good for me! |
||||
|
||||
|
true_organs Member since: 5/24/2008 From: Port Coquitlam, Canada |
|||
|
Posted - 5/24/2008 1:31:13 PM |
||||
| I get a bunch of error messages when I try to run the client that stem from GETINTERFACE pfnInterface=0; They basically say that GETINTERFACE is undeclared... How do I fix this issue? thx |
||||
|
||||
|
Mike2343 Member since: 7/14/2005 From: Portland, OR, United States |
|||
|
Posted - 5/24/2008 6:40:08 PM |
||||
| Please note this article is well over 7 years old at this point and was created using Microsoft Visual Studios 6.0 which is very, very old. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
