Need someone familiar with DLLs

Hello everyone. I'm not sure exactly where to post this as it is kind of a generic question yet is related to (game programming + win32 + c++) so I just posted here.

I've never written a DLL before and after searching the board and the web I'm thinking about using them for a program I'm writing. From someone who has used DLLs I just wanted some input as to whether what I'm doing is stupid/mis-usage of DLLs or not.

My program:
- A win32 app. that will have a bunch of different card games built into it.
- The user will select a specific game from a dialog box.
- At this point I'm thinking about loading a DLL containing that game's code (Ex: Solitaire.dll; or BlackJack.dll; etc..)
- This will allow me to keep my main program small & clean; permit easy upgrading/altering of my code later (adding more game functionality;etc.).

Uh, is this a good usage of DLLs? For every new game I would of course add another DLL. Is this overkill? or okay? Basically every game DLL would have similar functions just different implementations

Ex:

Code:

---

// Solitaire.dll
void handleMouseClicks(...){};
bool draw(...){};

---

Code:

---

// BlackJack.dll
void handleMouseClicks(...){};
bool draw(...){};

---

Code:

---

//Main pseudocode.

if(SOLITAIRE)
  Load(Solitaire.dll);
else if (BLACKJACK)
  Load(BlackJack.dll);

WM_LEFTMOUSEDOWN:
  handleMouseClicks(...); // Call specific function depending on which game DLL is loaded.  I'm assuming this would work???
break;

---

This a bad idea? Or should I just go statically with a class Hierarchy?
ex:

Code:

---

class Game
{
  virtual void handleMouseClicks(...){};
  virtual bool draw(...){};
}

class Solitaire:Game
{
}

class BlackJack:Game
{
}

int main()
{
  Game *currentGame;

  if(SOLITAIRE)
    currentGame = new Solitaire();
else if (BLACKJACK)
  currentGame = new BlackJack();

WM_LEFTMOUSEDOWN:
  currentGame->handleMouseClicks(...); // I'm assuming this would work??
break;
}

---

Moved to the appropriate forum.

Thanks for moving me... guess instead of creating a new thread I might as well post another question here:

I'm attempting to learn DLLs, but I can't get it to work:

Code:

---

// This is DllOne.dll
#include <windows.h>

BOOL WINAPI DllMain(HINSTANCE hinstDLL,
DWORD    fdwReason,
LPVOID    lpvReserved)
{
    return TRUE;
}

__declspec (dllexport) int Multiply(int x, int y )
{
  return x*y;
}

---

Code:

---

// This is my main trying to test the DLL
#include <iostream>
#include <windows.h>

using namespace std;

typedef int (*MYPROC)(int, int);

int main()
{
  HINSTANCE inst = LoadLibrary("DllOne.dll");
  MYPROC ProcAdd;
 
  ProcAdd = (MYPROC)GetProcAddress(inst, "Multiply");
 
  if(ProcAdd)
    cout << (ProcAdd)(1, 2);
 
  if(inst)
  {
    FreeLibrary(inst);
  }
 
  cout << "Hello";
 
  return 0;
}

---

Problem is the code above in RED never gets executed. I have my DLL in the same directory as my program, but I can't seem to access the function within my DLL. Also, is the only way to use a DLL is to use function pointers due to compile time checks?

What you have described is often described as a plugin architecture and is a common usage of DLLs. A couple of articles are listed below.

http://www.codeproject.com/dll/plugin.asp
http://www.codeguru.com/cpp/misc/mis...cle.php/c3879/
http://www.codeproject.com/library/piarchitecture.asp

Ah those were good links.. I have a good idea which direction I want to proceed now. Thanks.

As for my second question (3rd post in this thread) about the explicit linking... anyone know where my problem lies? I know for a fact the LoadLibrary() is working correctly and returning the correct HINSTANCE to my DLL, but the GetProcAddress() just doesn't seem to be working.. any ideas?

Oww.. my freaking head hurts.. cursed the man who invented programming.

Screw all my other questions as I have fixed 'em.. just one remaining:

The following doesn't work. GetProcAddress() fails even though this is how I seen it written in many tutorials.

Code:

---

__declspec(dllexport) int Multiply(int x, int y)
{
  return x*y;
}

---

While the following works!?!? My GetProcAddress() works perfect now..!?

Code:

---

extern "C" __declspec(dllexport) int Multiply(int x, int y)
{
  return x*y;
}

---

My question is what is the extern "C" do? Why do I need it? And why do places (i think even MSDN documentation examples) say i only needed __declspec(dllexport)?

Quote:

---

At this point I'm thinking about loading a DLL containing that game's code (Ex: Solitaire.dll; or BlackJack.dll; etc..)
- This will allow me to keep my main program small & clean; permit easy upgrading/altering of my code later (adding more game functionality;etc.).

Uh, is this a good usage of DLLs? For every new game I would of course add another DLL. Is this overkill? or okay? Basically every game DLL would have similar functions just different implementations...

---

I'm not an expert on DLLs, but as I understand it, it's usually the other way around. The DLL should contain all of the common code... maybe all of the card-deck related stuff... and the other programs should contain the game-specific code.

The general idea is to avoid duplicating code in each similar program. i.e. instead of duplicating a card class and a deck-shuffle function in each program you can write and debug it once, and stick into a DLL.

Quote:

---

Originally Posted by Kurisu33

Oww.. my freaking head hurts.. cursed the man who invented programming.

Screw all my other questions as I have fixed 'em.. just one remaining:

The following doesn't work. GetProcAddress() fails even though this is how I seen it written in many tutorials.

Code:

---

__declspec(dllexport) int Multiply(int x, int y)
{
  return x*y;
}

---

While the following works!?!? My GetProcAddress() works perfect now..!?

Code:

---

extern "C" __declspec(dllexport) int Multiply(int x, int y)
{
  return x*y;
}

---

My question is what is the extern "C" do? Why do I need it? And why do places (i think even MSDN documentation examples) say i only needed __declspec(dllexport)?

---

It's probably due to name mangling, check this article for an explanation that is pretty straightforward (basically, extern "C" causes the code to be compiled with C linkage specifications, i.e. no name mangling):
http://www.devx.com/tips/Tip/12527

Quote:

---

Originally Posted by Mad_guy

It's probably due to name mangling, check this article for an explanation that is pretty straightforward (basically, extern "C" causes the code to be compiled with C linkage specifications, i.e. no name mangling):
http://www.devx.com/tips/Tip/12527

---

Yeppers, that satisfied me. Didn't know the compiler was renaming my functions.. what a dirty thing to do :)

------------------------------------------------------------

I still have one major problem though. My card-deck code as someone referred to should be a .dll so that it isn't pointlessly duplicated, but I don't know how to do this.

My problem is that my game code makes reference to the object thus requiring compile-time junk.

Example:
My card-deck code is contained within 2 files. Pile.h & Card.h
Each game consists of PILES with each PILE containing a series of CARDS.
So my game class includes "Pile.h" and "Pile.h" includes "Card.h"
Err basically [Solitaire.h -> Pile.h -> Card.h]

Code:

---

// This will be Solitaire.dll
#include "Pile.h"    // Needed for Pile class.  If I remove this this code will no longer compile due to my private member variables.

class Solitaire
{
    public:
        Solitaire();

        void draw(/*inout*/ HDC &hdc);

        void newGame();
       
        void handleClick(/*in*/ int x, /*in*/ int y);
       
    private:               
        Pile m_deck;    // Cards currently in the deck
        Pile m_deckHolder; // Where the cards are placed when removed from the deck.
        list <Pile> m_endPiles; // Four end piles that hold each suit from Ace-King.
        list <Pile> m_playingPiles;    // Seven playing field piles.
};

---

So, anyone know how I can still keep the Pile variables in my game code without actually having to include the Pile.h & Pile.cpp & Card.h & Card.cpp at compile time. It is making my game DLLs bigger and if I wanted to change my Pile/Card code later I would have to recompile each and every game Dll. That seems kinda bad.

Oh my.. after hours of Googling + beating myself senseless with a spoon + some sleep deprivation I think I managed to answer my own question.

Solution:
Create a .dll with the card-deck code: Pile.h/cpp + Card.h/cpp = (Backend.dll)
Take Solitaire project and link with (Backend.lib) which results in (Solitaire.dll)
Place Backend.dll & Solitaire.dll in main game directory and run.

Final:
Card Games.exe (200kb) loads Solitaire.dll (92kb) which uses Backend.dll (32kb)


Oh the horrors. :rolleyes:

Finally I have ended this thread.