[RESOLVED] DLL as resources.

[Slyke]

Say if i make a DLL in Delphi, C++ or even VB and i want my program to be stand alone still, would this be possible to include the DLL into the project so that i can still call from the DLL?

I was thinking along the lines of including the DLL as a resource inside the project (like you would a picture or a sound) and then calling subs and functions from it still as you normally would.

This would allow me to create DLLs in other languages, include them into visual basic projects, and still allow the program to be one file.


Is this possible?

[RhinoBull]

If it's a standard dll then you'd have to use declarations similar to those Windows APIs.
If it's an ActiveX dll then you can either reference it (through project references) directly in your project or use late bindings to create instance of an object.

For each approach we have plenty of samples.

[randem]

I am confused you are referring to stand-alone and VB...

That is not possible.

[gabba]

If you're in designtime and you're referencing to an external library then at runtime your prog will reference to that same library.

By its very nature Dynamic Link Library is going to be linked to [filesystem or memory]...

If you're going to talk self-extraction, DLL-in-PE and all that, then you'll need to ask that question by itself.

[Slyke]

Yes, i'm talking about creating a DLL that my program can use API calls from it.
I was wondering instead of placing the DLL in the same folder i could instead make it a resource. It's not an ActiveX DLL.

I don't see why this isn't possible, but i don't know too much about this area.

[gabba]

why not just put all your code into classmodules/usercontrols and skip the dll? this way, you can allow other applications to reference to your .exe (not .dll) and you have all of your references/links readily available to you in your program, without having to call an external file...

[randem]

Why not just package your app like the rest of the VB world... it would be far simplier.

[Slyke]

I also may use the same DLL with C or Delphi programs.

It just makes it easier, if i want to make a stand alone application and i won't want to have to worry about 2 files, only 1 file. It just makes it simplier.

I'm looking at that program that you told me about now, but i'm a bit weighed down with study at the moment to try it.

Sooo... is it possible?

[gabba]

Possible with self extraction + temporary directory.

But why don't you just write your DLL into your VB application, by means of class modules, modules, and usercontrols(thats all you're allowed in a dll). Why not?

[DigiRev]

I've put ActiveX controls in the EXE file through the resource editor.

Didn't use any self-extracting or anything, just kept it in the EXE. It seemed to run just fine on systems without those ActiveX's installed.

It was more of an experiment though. I would never feel good about distributing an app like that.

Use an installer.

[davidbishton]

Possible with self extraction + temporary directory.

But why don't you just write your DLL into your VB application, by means of class modules, modules, and usercontrols(thats all you're allowed in a dll). Why not?

Because he said he may want to use the DLL with other programs.

[gabba]

You can reference to EXE API calls if you make them publicly referencable through PE reference headers, you can do it in C so I see no reason why you cannot implement something similar in VB.

[randem]

You can't make a stand alone VB6 program...PERIOD!!!

[gabba]

slyke, why did you want to package your dlls into your exe? There isn't some kind of sinister activeX plot going on here?

[Slyke]

Well when i say 'stand alone' I ment no other custom files needed.

Yess, i'm secretly going to open up the activeX black market

So if i put API calls inside the DLL and put the DLL as a resource i can still call the APIs from the DLL which is inside the EXE?

Thanks.

[Slyke]

Another reason is i can give DLLs to people so that they can use APIs that i have made, and they don't have to worry about carting around 2 files since they can just add the DLL and call it's APIs from the resource.

[randem]

Still what about the VB runtime files???

[DigiRev]

Your program will require the msvbm60.dll file regardless, so it's never completely standalone.

You can compile all of the runtime files into the EXE but it's still not technically stand-alone. It will be a single EXE file but it will still be dependent on other files.

You might want to check out Alloy which can bundle everything into one EXE. This is still not much different than an installer, only that it extracts the necessary files quickly and invisibly.

Alternatively you could put everything into a resource file, but I'm not sure you can still make API calls to your DLLs this way unless you extract the DLL files somewhere first.

If you want everything statically linked in your EXE then you're using the wrong language. Use C++