DLL Design Issues

Correct.

Include only the interface files.

Kuphryn

Ok, i tried including only the interface files (.h) and it works, i mean, i can compile the dll if i dont use the code.
This compiles successfuly:
function doSomeMath(int n1, int n2)
{
math *m;
};

It won''t work if i actually try to use the class'' code, ie, if i do this, it gives me a lnk2019 error:
function doSomeMath(int n1, int n2)
{
math *m;
n1 = m->add(n1, n2);
};

...unresolved external symbol, because it cant find the code for the "add" method...

So, what other solutions do i have?

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven''t contacted us!

i believe it is very bad practise to have your dlls use your program... pherhaps make those classes dll''s aswell...

why bad practice?

This is how q3/q2 do it, but I don''t think they return classes. Perhaps try with just structs/global funcs? Or just study q2 source..

You''d need to export the classes from the exe, and make the header files tell the dll they are exported so it knows to import them. There might be some more things required, but it is all about importing/exporting and you should be able to find a lot of information about it. It should be exactly the same as putting your classes in the dll and making the exe use them.

Export the classes from the EXE?
That would be an extremely helpful feature...

Where can i find examples of this?

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven''t contacted us!

quote:

---

Original post by pentium3id
Export the classes from the EXE?
That would be an extremely helpful feature...

Where can i find examples of this?

---

In your .exe class declarations, declare them with __declspec(dllexport). In your .dll, declare them with __declspec(dllimport) and link with the .exe''s import library.

MSN

angryzenmaster @ livejournal

will that require me to build a .lib, or will the dlls be able to dinamicly link to the .exe?

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven''t contacted us!

I ''cheated'', like Q2 does.

I filled a struct full of function pointers and passed that to the game dll to use as it''s API.

ok, i added this test class to my exe:

class __declspec(dllexport) CExport
{
public:
	void alpha(void) 
	{ 
		x = 30; 
	};

	int x;
};

When I compile my exe, it also generates a lib file (myapp.lib). In my dll i added:
#pragma comment( lib, "MyApp.lib" )

So, what more should i add to the DLL to make the class work?
I guess that the code sits in the .lib file, while we add a header file to our DLL project, right?

Thanx for any input on this, im really lost here...

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven't contacted us!

[edited by - pentium3id on January 16, 2004 12:39:38 AM]

ok, i got the dll to use the exported class from the exe, via a lib that gets generated at compile time.

Now, can someone reverse engeneer that lib and get the code?

Thanx for any input on this stuff. To reedem myself I''ll write a tutorial on this stuff as soon as I get it to work myself

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven''t contacted us!

The way to stay sane is to declare the interfaces that you use between DLL and application as pure virtual classes. These need no code.

// declare this in a header included in both DLL and application
class IDllHostApplication
{
public:
  virtual void sayCheese() = 0;
};

// declare this in a header included in both DLL and application
class IDllFunctionality
{
public:
  virtual void takePicture( IDllHostApplication * host ) = 0;
};

// define this in the application
class CDllHostApplication : public IDllHostApplication
{
public:
  void sayCheese() {
    puts( "cheese" );
  }
};
CDllHostApplication host;

void appFunc( IDllFunctionality * func )
{
  func->takePicture( &host );
}

// define this in the DLL
class CDllFunctionality : IDllFunctionality
{
public:
  void takePicture( IDllHostApplication * host ) {
    host->sayCheese();
    DoSomePictureTaking();
  }
};

__declspec( dllexport ) IDllFunctionality MakeMeSomeFunctionality()
{
  return new CDllFunctionality;
}
 

The application then does LoadLibrary() on the DLL, and finds the function MakeMeSomeFunctionality by name, and calls it to get an interface into the DLL. It can then call the DLL through the known abstract interface, and pass an abstract interface to functionality implemented in the application, for callbacks. Typically, the IDllHostApplication will actually be passed into MakeMeSomeFunctionality().

This is a nice, light-weight way of supporting plug-ins that run in a well-defined host environment, without having to physically link one against the other. This works, because there is no code or data needed to be shared for a pure virtual class, which is all that''s shared between the app and the DLL.

If you want a heavier-weight version of this mechanism, Microsoft provides one with Windows: it''s called "COM".

What are the Cons of using Virtual functions? The same as using function pointers because there is a vtable?

Thanx for the tips, ill look into virtual functions and see how it handles

---

[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][Yann L.][Enginuity]
The most irrefutable evidence that there is intelligent life in the Universe is that they haven''t contacted us!