Sorry your browser is not supported!

I have developed a technique to use third party DLLs within a DarkBASIC Profesional program and yet distribute only a single "standalone" .exe file. For example, my networked COMMBAT program used Lagmaster's IP retrieval DLL, and the testers only needed to download and unzip a single executable module.

Part of this technique involves attachment of the DLL to the project. For me, the DBP IDE does not seem to recognize a DLL file as a type of media, so it does not allow me to directly attach a .dll file to the executable build. So I decieve the IDE by changing or removing the file extension, and then adding the file as media.

The other part of the technique is performed during the program initialization. Have the program copy the attached file to a folder, renaming it back to the proper .dll. The DLL is then available to be loaded and called by the program. Good housekeeping dictates the deletion of the renamed .dll from the disk as soon as it is loaded into the program.

I think that using this technique makes for nicer distributions, cleaner installations, and you will have the assurance of KNOWING the proper DLL is used by your program.

Are there any drawbacks to using this technique?

I presume you mean DLL's as in DLL's and not as plug-ins, in which case the problem doesn't exist (and one reason to use plug-ins).

One possible (but unlikely problem) is that the temporary directory is called something else (and not TMP or TEMP). Next, you've got to make sure that the DLL isn't already present (and marked as read-only).

The temp. directory on XP machines should have permission for file copying & renaming, so that shouldn't be a problem.

Aside from that, I cant see any real problems there.

As long as you give the dll a known media name, the file will be attached, and you will be able to call the dll using that name.

Here's some code I've got working :



I attached a copy of user32.dll to my exe, renamed as user32bodge.sgt, and the above program works great.

It gets around using a temporary directory and potentially leaving files hanging around.

MrTAToad what do you mean
"I presume you mean DLL's as in DLL's and not as plug-ins, in which case the problem doesn't exist (and one reason to use plug-ins)."? I don't understand.

IanM, cool tip. That's the way I will do it from now on.

Ie DLL's you use calling CALL DLL, as opposed to plug-in DLL's which are always compiled into the program, removing any need for external DLL's.