[fitzjj]

i need to write a dll, it is to be written in C, but never havin had to write a dll before i thought i'd just check that it has no serious limitations over that of an executable does it. i.e. it is able to call malloc and all of the c libraries as with a regular c app.

cheers - thought it best to check before i get too far into it!

[Iron_Cross]

As far as I know, the only limitation that a .dll has is that it can't be directly run (ie. by double clicking it), it has to be called by some other arbitrary code.

[fitzjj]

cool. that is kind of what i expected. thanks

[Something Sexy]

I believe with .dlls there are two different types, one is Implicit Linking and the other is Explicit linking, I believe with Explicit you can load each function you need into memory when you need it, with Implicit it loads all the code in the DLL right away whether you need it or not. but I believe Explicit is just a little bit more difficult to write.

[fitzjj]

Something Sexy you are a star!

so far i have coded everything using implicit linking, which after a quick bit of research seems to be the norm. My DLL needs to talk with another DLL, which by the looks of it may well have been coded explicitly. I think this is what has been causing me a couple of problems. I am assuming explicit is more efficient considering i have to code a lot of functions in the dll? although like you mention no doubt it is more difficult.

thanks!

[Something Sexy]

Heh heh it's no problem, let me know how it goes, wouldn't mind seeing some sample code of it.

[TheHeadFL]

If I recall from the last time that I wrote a DLL (forgive me, this was a few years back) that you can actually use C++ and any of the regular libraries in a DLL. Its just that all your 'interface' functions have to be written in C. In other words, you could actually work with objects internally in your DLL, but you would have to serialize the input and output through a regular C function.

[fitzjj]

Ok, :o it turned out to be a bug in my makefile and nothing to do with implicit/explicit linking, but cheers for the suggestion anyway.

Unfortunately i cant use C++ for it since i am already supplied with a header and a C source file which need to be used - well in all fairness they are extremely badly written and could do with recoding, but i havent got time for, am not being paid enough to do that.
Basically the guy who wrote the library i am using (but dont have the source code for) used some very strange types defined in the C code i have and used in his library so i am coding another DLL to wrap them up and make them accessible to the C# app that i need to write which should also make the functions more accessible, useful and understandable! hopefully this would save a lot of work if they ever need to access the library again.

Unfortunately beacuse it is for a company i cant get you any source code Something Sexy, but in all fairness it is nothing too exciting, mostly just a load of functions that call some functions in another DLL but mess around with datatypes and stuff along the way

[Something Sexy]

Yea that is understandable, but good luck, and let me know how the final project goes.

[fitzjj]

i need to store variables in a dll, which need to remain there so that they are accessible for other exported functions in the dll to use. It seems that using dllImport will not keep the dll in memory and so these variables are lost once a function call has completed.

What i need is something like loadLibrary() that was avaiable in C++ to use in C# - in relation to the above messages this would be explicit linking. - but basically i want the dll i am using to remain in memory throughout the execution of the program so that all function calls to the dlls functions are to the same instance of the dll.

hope that makes some sense. does anyone know how to do this in C#? thanks