writing windows dlls using visual studio 2008 express

I was wondering if anyone knows how exactly to set up the project to compile a dll in visual studio 2008? I got it to export a dll file, but for some reason can't get that dll to load into a program i wrote in liberty basic 4.03 (eeeww!! it's just to test my dll, im loyal to c, i swear). but i have the function defined:

int _stdcall sum (int a, int b);

and i'm not using any functions requiring interrupts or anything, just

return a+b;

but i still cant get it to work right! I have the project defined as a dll in project options, so what am i doing wrong?

actually guys, i just figured it out. Crisis averted!!!

You might want to tell your solution so others can benefit from your wisdom? Good work, btw.
And _stdcall should really be __stdcall.

oh, sry, forgot about the solution, duh! Anyways, I forgot to go into the linker options and add the def file to the command line. Also, i had the def file written wrong i think. now everything is working fine. I didnt realize that Visual C++ wouldnt automatically link the def file.

Actually, if you add a .def file to the project, it will be "linked" by the linker (ie exporting the functions listed there).
But if you need to use that DLL is another project, then of course you will have to either use the lib file (properties -> general -> additional include libraries) or tick a dependency (add the dll project to the solution, go to solution properties -> project dependencies and select your project to use the dll in the drop-down list, and finally tick the checkbox next to your dll).
Either way will work.

Well, actually, i had planned on creating dlls to link at runtime. I was also wondering how classes within dlls would work. how can i declare a variable of type (Var_type) if that type is defined inside a dll linked at runtime? or can i not instance that class? It's all very confusing!

It's rather easy.
Firstly, you would need a macro, like DllExport. For the dll, it must define DllExport as __declspec(dllexport) and the project that uses the class must define it as __declspec(dllimport).
This ensures that the dll will export the class and the target project to use will import the class.
Secondly, use that macro in the header, after the class "keyword" on the class of choice. It needs to be used on the definition of the class.
The implementation can be left inside the dll source files.
Now, all the project that uses this class needs to do is include the proper header and use it. The actual dll code will be inside the dll.

???? Sry, i have no clue what to do w/ that answer dude. Can u maybe show a short example of what u mean? and i wanted to be able to load the classes dynamically, not during compile time. im not sure if that makes a difference for ur answer... i read a brief tutorial on loading dlls at runtime, but i couldnt get much from it. Could you recommend some?

Quote:

---

Originally Posted by xixpsychoxix

???? Sry, i have no clue what to do w/ that answer dude. Can u maybe show a short example of what u mean? and i wanted to be able to load the classes dynamically, not during compile time. im not sure if that makes a difference for ur answer... i read a brief tutorial on loading dlls at runtime, but i couldnt get much from it. Could you recommend some?

---

Loading a class from a DLL is a quite tricky subject. Why not try a google for "how to write DLL" first, then tackle the problem of how to make a class definition in a DLL. We use this concept quite a lot where I work, but it's not entirely trivial to make it work the first time you try it. Because of the way it works, the best way is to have a function in the DLL that returns a pointer to the object.

--
Mats

Ok, that i do understand. So i would use a pointer to store the data from the object, and then to read it? Nevermind, but i have one last question. how can i provide a function as an argument to a call? Here is the code i had to make a dll that runs a thread (just as an example):

Code:

---


//borrowed most of this from a tutorial site

/*  testLibLoad.cpp
*  Auth: earl at earlh dot com
*  This works under Win2K; dunno about anything else
*/

#include <windows.h>
#include <stdio.h>

void *threadtest (void)
{
        printf ("Hello, world\n");
        system ("pause");
        return NULL;
}

int main (int argc, char** argv)
{
HINSTANCE hDLL;
hDLL = LoadLibrary("TestDLL.dll"); //load the library
if (hDLL == NULL)
{
fprintf(stderr, "Unable to load library.\n");
exit(-1);
}

//search for our function:int libPrintHelloWorld(void)
int (*funcPtr)(void (*)); //the function pointer

funcPtr = (int (*)(void (*))) GetProcAddress(hDLL, "runthread");
if (funcPtr == NULL)
{
fprintf(stderr, "Unable to find Message\n");
exit(-2);
}

//everything is working, so call the function
int retVal = funcPtr (threadtest ());

//cleanup by freeing the library
BOOL result = FreeLibrary(hDLL);
if (result == FALSE)
{
fprintf(stderr, "Unable to free library\n");
exit(-3);
}

printf("Everything worked!\n");
system ("pause");
return 0;
}

---

And here is the code for my dll:

Code:

---


#include <windows.h>
#include <process.h>

int sum (int a, int b)
{
        return a + b;
}

int Message (char *mbText, char *mbTitle)
{
        MessageBox (NULL, mbText, mbTitle, MB_OK);
        return 0;
}

int runthread (void (*to_run)(void *), void *arg)
{
        _beginthread (to_run, 0, arg);
        return 0;
}

---

the thread starts correctly, but then it does something funny. i am using Visual c++ 2008 edition, and i get this runtime error:

debug assertion failed!

Program: DllRuntimeLoaderTest
File: thread.c
Line: 113

Expression: initialcode != NULL

Why is it doing that? And what is the correct way to pass a call the address of a function?

Code:

---

void *threadtest (void)
{
        printf ("Hello, world\n");
        system ("pause");
        return NULL;
}
..
int retVal = funcPtr (threadtest ());
...

---

What is the return value of threadtest()?

If you want to run "threadtest" as a function, remove the () after the name of the function.

--
Mats

I'm having trouble finding tutorials on how to load a class from a dll. is it possible to just extend a class that exists in the program and use that somehow? but how would the constructor be called for the derived class? this is a confusing topic. if anyone has a short example, or even a long-winded, extremely confusing example that is well commented, or a link of some sort... i think i may be in over my head w/ this :eek:

Code:

---

Dll.h:
#ifdef DLL
#define DllExport __declspec(dllexport)
#else
#define DllExport __declspec(dllimport)
#endif

class DllExport MyClass
{
    // ...
};

Dll.cpp:
#define Dll
#include "Dll.h"
// Class implementation goes here

Demo.cpp:
#include "Dll.h"
int main()
{
    MyClass foo;
    // Use foo as normal here
}

---

Now all you have to do is add a depedency as I mentioned.
This will not work, of course, if you dynamically load your dlls at runtime. It assumes that you will use static linking.

Using classes from a dynamically loaded DLL will be tricky at best, and unfortunately I have no method of doing so.

I just found a really good article on the subject with good source, but it fails to explain about derived classes. how can i add class members or class functions to the class from the dll, if at all possible? I want to be able to extend the functionality without having to know what functionality to add. What i have gathered will work for now, but im trying to learn as much as possible about this now so i dont have to learn it over again...:rolleyes:

Huh? So you add the extra functionality and re-compile the dll and the app and it's done, unless you are talking about something way different?

well im trying to avoid having to re-compile the app if possible. that's why i want to link to the dll. if it isnt possible, i guess i could just decide what i would want to add and then add it as i go. also, if i need to extend the functionality that much, i can always rewrite the application i suppose

As long as you don't change the exposed dll functionality, such as function names and what parameters they take, etc, an old app will run fine with a newly compiled dll.
However, your app will not be able to take advantage of the new functionality in the dll!

Ok, so the way our system works is that you have a "create" function in the DLL that returns a pointer to the base-class. For each variant of the DLL, it obviously returns the relevant derived class.

This works well as long as your derived function doesn't need further member functions than the original base-class provides - and of course, all base-class functions need to be virtual.

--
Mats