Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DLL Talk / [STICKY] Compiling with ExternaliseDLLS=Yes

Author
Message
IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th May 2008 00:18
With a little (Ok, a lot) of help from Lee, I've now got an understanding of how to get this option working, and I'm passing it on to you.

Here's the note from the release:
Quote: "A new field in SETUP.INI called ExternaliseDLLS will exclude ALL DLLs from your executable if set to yes. This allows you to have extremely small executables and place the required DLLs alongside the main executable."

Basically, it allows you to keep the DBPro DLLs separate from the executable.

Here's how you get it to work...

First, get your program running normally, with the setting set to No.

Once it is running to your satisfaction, locate the file TEMP\_Temp.dbm in the DBPro installation folder (usually in C:\Program Files\Dark Basic Software\Dark Basic Professional) and open it with notepad or a similar text editor.

Search for the line containing 'DLLS:', and make a note of the DLLs listed immediately after this line. Use this as a list of the DLLs to copy to your executable folder. Note, that the DLLs you need may be in any one of the 3 plug-ins folders within the Compiler folder.

The next step is to add a command from each of these DLLs to your source file - you can skip including commands for the Core and Setup DLLs, but all others MUST have a command included in the source file.

Now you are ready to recompile with external DLLs enabled. Change the line in the Compiler\setup.ini file from 'ExternaliseDLLS=No' to 'ExternaliseDLLS=Yes' and recompile.

Now check again the list of DLLs in the TEMP\_Temp.dbm file and ensure that the same DLLs are still listed. If they aren't, you missed using a command from the missing DLL.

If they are, you are now ready to run your program.

Don't forget to change the Compiler\setup.ini back when you are done!

IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th May 2008 00:21
Here's a simple example that I'll walk you through:
+ Code Snippet

When compiled, this code produces the following DBM file (edited to reduce its size a little):
+ Code Snippet

As you can see, the DLLs required are:
- DBProCore.dll
- DBProSetupDebug.dll
- DBProBasic2DDebug.dll
- DBProTextDebug.dll

I picked the TEXT command (for the Text plug-in) and the LINE command (for the Basic2D plug-in), ignoring the Core and Setup DLLs, and put the commands into a function (not necessary, but neater):
+ Code Snippet

Then I changed the ExternaliseDLLS value in setup.ini to Yes and recompiled. The same 4 DLLs were listed in the DBM file, so at this point, the executable is runnable.

trogdor
13
Years of Service
User Offline
Joined: 15th Apr 2003
Location: Portsmouth, VA, USA
Posted: 6th May 2008 17:48
Thanks for the instructions.
Lots of work just to get the small exe.

Re: your example, Why would dlls be listed if you are not using it? (Text plug-in, Basic2D plug-in)


I got a list of 30 dlls and I dont even know what a ConvMDL.dll, or ConvMDL2.dll, or ConvMDL2.dll commands are.

+ Code Snippet

Is there a list of the common DLLs and the commands they contain?

It would be great if the compiler spits out the NeverToBeRun() function

Let them hate as long as they fear -Caligula
IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th May 2008 20:41
Quote: "Lots of work just to get the small exe."

Yup... If you can get it to work. I've been trying to use this to load a simple X object, and am getting nowhere.

I'll be honest and tell you that I think this process is over-complex and difficult to get to work. There are far easier ways to skin this cat - using The Winch's DarkExplorer utility on the final exe is one such way.

the_winch
14
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 6th May 2008 22:20 Edited at: 6th May 2008 22:28
I wonder if there is any difference between an ExternaliseDLLS=Yes exe and an ExternaliseDLLS=No exe.

If the only difference is if the compiler attaches the dlls or not I guess you could do this.

-> Compile exe with ExternaliseDLLS=No
-> Load in dark_explorer.
-> Extract all dlls to exe directory.
-> Remove all dlls from exe.
-> Save exe.

Not exactly straightforward but a lot better than the ExternaliseDLLS=Yes method.

I'd also suspect that the latests version exes don't do anything different to previous versions when loading dlls. I expect the exe just uses LoadLibrary() to load the dlls and the LoadLibrary() search path includes the exe directory. So you should be able to use the above method with previous dbpro versions.

I'm not really sure what the purpose of ExternaliseDLLS=Yes is. Surely it is only of use when you have multiple exes in the same directory so they can share dlls but how often does that happen?

By way of demonstration, he emitted a batlike squeak that was indeed bothersome.
IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th May 2008 22:52 Edited at: 7th May 2008 00:16
When you compile with ExternaliseDLLS=Yes, the compiler seems to short-cut some processes, including listing within the _virtual.dat which DLLs are to be loaded at runtime due to internal dependencies - that's the reason for having to include actual commands to force them to be included.

I think that exploding the DLLs out of the exe's (or pck's) would work just as well as ExternaliseDLLS=Yes, but without all of the bother. I have a DBPro program that already does most of that - it only needs to be modified to produce a new .pck from the _virtual.dat and optionally re-attach it to the exe, and I suspect you could do just as quickly.

[EDIT]I decided to test it, and it does work but only for 6.8. If you do it for earlier versions the exe can't locate/load the DBProCore.dll.

Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 7th May 2008 01:20
I think this is a "feature" that I shall ignore.

[But the_winch's utility sounds the way to go if I should ever think of a need for this. ]

Am I correct in thinking that the main advantage is that if you have lots of DBP executables then you, in effect, need only one copy of the relevant DLLs on your system instead of lots of copies buried inside various exe files?
IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th May 2008 01:23
Yes, as long as your programs are compiled with the same version of DBPro. If they aren't then you may get unpredictable problems.

Green Gandalf
12
Years of Service
User Offline
Joined: 3rd Jan 2005
Location: Cornwall UK
Posted: 7th May 2008 01:51
Hmm. Looks even more like a feature to ignore.

But why are the executables so big anyway, either as a standalone exe or as an exe plus DLLs? Would, for example, C++ exes plus necessary DLLs be as large? My limited experience suggests they might be MUCH smaller - but then I haven't checked the DLLs they might need.
IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th May 2008 15:26
Much of the size is due to how the DLLs are compiled. All DBPro executable are compiled as static - what this means is that for each and every DLL a copy of the C and the C++ runtime is included (or at least relevant functions used by that DLL). The upside of this is that you don't need a separate set of rumtime DLLs either.

It's my thought though that this is over-rated. If TGC recompiled the DLLs as multi-threaded DLL (like I do mine), and they forced the C & C++ runtime DLLs to be added to the executable (like they do for Core & Setup), I would expect to see a smaller final exe, and as a plus, they would have a far easier to manage memory model to work with.

Whether this is within MS's licensing agreements for those redistributable files though is a separate matter, but then again, what is a DBPro exe except for just another archive format?

Freddix
DBPro Developer
14
Years of Service
User Offline
Joined: 19th Sep 2002
Location: France
Posted: 7th May 2008 16:00
Hum ... There is a problme with this new option...

Are we allowed to distribute the DarkBASIC Professional's DLL ?
Because, the interest is to get smaller .EXE but sometimes ... fixes are not in our .EXE but in the DBPro DLL ... So ... we may then need to release upgrade that are just DLL upgrade ...

Is it allowed ?

Gandalf said: "All we have to decide is what to do with the time that is given to us"
Odyssey-Creators - X-Quad Editor - 3DMapEditor
tiresius
14
Years of Service
User Offline
Joined: 13th Nov 2002
Location: MA USA
Posted: 7th May 2008 18:02
Quote: "up... If you can get it to work. I've been trying to use this to load a simple X object, and am getting nowhere."

I thought you got this working, IanM?

Quote: "Are we allowed to distribute the DarkBASIC Professional's DLL?"

I assume we are allowed. If we're sending out the DLLs as part of our first program group, what's the difference in sending out an updated DLL? The user already has it...

I'm not a real programmer but I play one with DBPro!
IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th May 2008 19:28
I got it working as long as the code was kept simple - once it got even a little more involved, I was tripping up all over the place.

In my opinion, it's far too much work to be bothered with and there are far simpler and less error-prone ways to get the same result as I proved last night. I can even post the code I used if it's of any interest to anyone. I might even play around with it a little and see if I can get something equivalent working for earlier DBPro releases.

Quote: "Are we allowed to distribute the DarkBASIC Professional's DLL?"

Yep, the user already has it - it's just wrapped up in an archive (ie the .exe or .pck)
You're not shipping the compiler, so it's not as if you are giving DBPro away. Besides, if anyone wants the DBPro functionality without having to pay for it, there's always the GDK.

the_winch
14
Years of Service
User Offline
Joined: 1st Feb 2003
Location: Oxford, UK
Posted: 12th May 2008 00:48
I added an externalise dlls command to the tools option of dark_explorer.
It saves the exe without dlls and writes all the dlls to the exe directory.

I also updated exe shrink which is a runtime style system for dbpro exes. Now when an exe runs it first searches for dlls in the exe directory before looking in the dbpro compiler directory. This uses a custom compress.dll to sourch the dlls from an external location so it should work with all dbpro versions.

By way of demonstration, he emitted a batlike squeak that was indeed bothersome.
IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 12th May 2008 01:33
Works just fine with 6.7, but it'd be better if there was an option to dump the DLLs out from the exe into the same folder as the new exe is built into.

Master Xilo
10
Years of Service
User Offline
Joined: 8th Sep 2006
Location: Bern, Switzerland
Posted: 5th Aug 2008 16:59
Why not just make a "Dark BASIC Pro Redistrubutable" that installs the .dlls in system32?
That would result in smaller executables + we would not have thousands of copies of the same dlls in our exe's using thousands of megabytes of our hardisks for the same thing. I also don't poy my pictures to every directory I want to be able to watch them from.

MSVC++ also has a redist and if you make a real game you'll give an installer with it anyway. and if you use Dark PHYSICS people will already have to install something additional (drivers) in order to run your programs.

Will this happen?


Something different:
We can't sell the dgdk programs without license, right?
What if I make my program in dgdk and give it away for free, but in order to start it needs to be started from a DBPro .exe which I do and can sell?
Would that be allowed (I don't think so, but does the EULA directly prohibit this? ) ?

We can sell things created in VC++ express right? And we can also give away the DBPro dlls + we can sell them with something we created.

What if i could call them from C++ (I don't think that would be easy) and write my program in C++?

Could I sell this as I don't use dgdk?

Just as some thoughts...

IanM
Moderator
14
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Aug 2008 15:36
Quote: "Why not just make a "Dark BASIC Pro Redistrubutable" that installs the .dlls in system32?"

Great, except that the DLLs change in each release of DBPro, and sometimes in slightly incompatible ways. Keeping the set of DLLs in the same folder as the executable is safer.

Quote: "What if I make my program in dgdk and give it away for free, but in order to start it needs to be started from a DBPro .exe which I do and can sell?
Would that be allowed"

No - it's still a part of the product you are selling.

Quote: "What if i could call them from C++ (I don't think that would be easy) and write my program in C++?"

No - the DLLs must be executed from a DBPro exe. However, there's nothing to stop you writing a one-command plug-in that contains your whole game.

Login to post a reply

Server time is: 2017-03-29 22:02:47
Your offset time is: 2017-03-29 22:02:47