The .exe is big because of the errors being inserted to it which those errors are not necessary to the end user, only to the programmer.
Those errors weight lots of MB.
There should be another setting for the compiler to compile a release version which will not include those errors, and will probably reduce the .exe size a lot.

You can make a smaller exe by using Dark GDK and C++/C#/VB

Is .exe size even an issue? I mean if you were really concerned about code size, code effeciency, binary size you wouldnt be using Darkbasic Pro.

Besides, I find it hard to believe that even a 100 mb exe file would be much challenge for modern computers. According to Steams hardware survey, 72% of all thier users have machines with 500-2gb RAM, Disk space is so abundant that its almost not worth even considering.

http://www.steampowered.com/status/survey.html

On the other hand if your making software for a PDA or phone or something then you probably wouldnt want to use DBPro.

Thats just my 2 cents, dont worry about .exe size.

-T

The DLLs used are the debug versions. It's been discussed many times in the past, but it looks like they are here to stay.

If you're making a game, then exe size should probably be one of the last things you're worrying about.

And if you're making an application (with BlueGUI, etc.), then you can achieve tiny exe sizes simply by not using commands from certain sets. 'clr' is from the core command set (no added exe size), while 'clr COLOR' is from the 2D command set (added exe size), for example.

And, as a reason for keeping the Debug dlls, if you miss a potential bug while your writing a program, at least your users could report a "could not close loop on line 1673", while a "This program encountered an inconvenience and had to close" wouldn't let them report anything but a bug somewhere.

-Xol

I'm sure the dlls aren't the debug versions. Nobody bothered to change the filenames when they stopped using debug versions. At least I remember reading that sometime.

But then... where are the debug versions?

And if they aren't the debug versions, then Jack LOL's point is still decently valid.

-Xol

I'm with Jack LOL on this one.

The single most annoying thing about DBP on my machine is the size of the DBP executables. I'm getting near my hard disk limit and regularly have to delete unwanted files - and guess what 90% of them are. Even the most trivial 3D demo results in a .exe file several megs in size. It is a poor advert for the language when most of the file is so obviously unnecessary.

Tick the 'compress attached media' box when you compile - it causes the DLLs to be compressed as well as media. You can even set it in the .dbpro template file so that it's set every time you create a new project.

Unfortunatly with compress media ticked you game takes about 6x as long to start and the user ends up double clicking again

That's pretty neat IanM. Thanks for the tip.

-Xol

and the user ends up double clicking again

I posted the solution to that problem earlier on this week - use a unique mutex. If you can lock it, you are the first instance. If it is already locked, you are a second or more instance and can immediately exit.

[EDIT]
@GatorHex,
In fact, it was for a post you created! Did you read it?

Yeah thanx IanM, I read it, but evenualy discovered my games looooong load time was due to compression of attached media

it seems incredible, but we move the following dll`s to another folder , we can get a smaller exe.

Conv3Ds.dll
convMD2.dll
convMD3.dll
conmvMDL.dll


it means that if we are going to use only .x files then we don`t need this dll....we can move more of them...I don´t remember now, but some other can be move apart without error...


just try it !! it works !!

Yeah... Twilight IDE used to do that. Now you can open the setup.ini file with notepad in the Compiler forlder and move the dlls to the exclusions heading, modifying their prefixes as such (I expect):


If you just want to use .dbo, you can also leave out ConvX.dll. These Conv*.dll dlls might only be included automatically if your project

But most of the dlls with Debug in their name are probably necessary.

-Xol

Can't TGC make like dbprobasic2drelease.dll or something like that?
And then exclude all the unnecessary errors?

I don't care if the error is vague - "ERROR AT LINE 1378" is good enough for me. As long as the line number is accurate for once.

Can't TGC make like dbprobasic2drelease.dll or something like that?
And then exclude all the unnecessary errors?

The errors have to be handled anyway to prevent some serious system instabilities. The overhead of providing a nice message box is likely to be very minimal.