Standalone Executable?

Blitz3D Forums/Blitz3D Beginners Area/Standalone Executable?

WarpZone(Posted 2004) [#1]
Is it possible to create a truly standalone exe file using BlitzBasic? That is, is it possible to compile all your sounds, models, textures, etc. into the final EXE file? I'm not talking about creating the meshes in-code, of course. I'm just talking about (basically) hiding the art assets without having to create a new format for everything. Does Blitz have a way to do that automatically?


xlsior(Posted 2004) [#2]
No, not natively...

but there are some 3rd party tools that allow you to do that, for example "molebox"

You write your program as normal, and load images/sounds/etc. Molebox can then re-write the .exe and merge the data files into the same file, so you end up with a single executable that also contains your media.


Rook Zimbabwe(Posted 2004) [#3]
Packmaker too... and its free! I have not used it to include everything with the exe but it says it is possible. Packmaker creates a packed and encrypted DATA.PPK (or whatever extension you care to call it) and then you simply extract the files in the start of your program and delete them when done.


Rhyolite(Posted 2004) [#4]
..and I believe PakMaker also allows you to combine the DATA.PPK into the exe file...???

Rhy Out


podperson(Posted 2004) [#5]
The advantages with Molebox are severalfold:

1) you can write your program normally, then create a single exe which includes everything and all your load calls will be changed automatically to reference packed files.

With PakMaker you need to replace every call to an external file that will be packed.

You could write wrapper code around the standard Pak calls to transparently handle cases where the packed data has not yet been packed, which would make this less of a burden during development, but it's both annoying and non-transparent.

Note that MoleBox even transparently copes with files that aren't packed (if you need to store and retrieve saved game or config files, for instance).

2) MoleBox transparently replaces file input code with code that is able to directly load moleboxed data with no intermediate file. This is both FASTER and MORE SECURE than the approaches taken by tools like PakMaker.

When you access a Pakmaker file it is decompressed and stored in an external directory. The external files may be removed manually and may get automatically deleted on the way out (I'm not sure) but -- if you alt-tab out of the running app OR kill the process, you can go find your unprotected files and steal them.

I might add that using a tool like PakMaker (which leaves unprotected files lying around on hard disks) actually contravenes the license agreements for some media (e.g. if you use licensed textures and models from Turbosquid you may discover that the media MAY NEVER be revealed in such a manner to an end-user).

3) MoleBox provides for packaging app and data separately and together and for patching. This latter is very important if your application ever actually SHIPS since you'll need to handle updates eventually, and you and your customers will pay for bandwidth and download times.

4) MoleBox allows you to encrypt your application binary (very handy if you're implementing a licensing scheme, since the code that crackers see in their debuggers will not be trivially mapped back to the actual executable).

5) MoleBox Pro allows you to embed DLLs in the executable.

Please note -- I do not use Molebox, I've just read the documentation and forums. I don't know how well it WORKS, just what it's supposed to do and how it's supposed to do it. It uses exactly the same approach we used for handling data in Prince of Destruction (including compressing and encrypting all our code).

MoleBox is kind of pricey -- $49 for the standard version and $99 for the pro version. But, unlike the other options, you don't need to start using it until your project is done. If you've COMPLETED a project and it's ready to ship, I think MoleBox is worth it. If you haven't, what do you care? (And meanwhile you don't need to worry about changing all your file load calls...)


Bot Builder(Posted 2004) [#6]
Although I think I heard that MoleBox has problems with sounds in blitz.


podperson(Posted 2004) [#7]
(Corrected, see my follow-up post below. Originally I replied here that based on MoleBox's forums this may well still be a problem.)


podperson(Posted 2004) [#8]
I downloaded MoleBox (standard) and tried it on Mark's Insectoids demo (which is one of the few sample programs that has some sound -- I'm a graphics guy so sound tends to be an afterthought in my projects ... seems like that's the case with a LOT of us :) ).

1) MoleBox seems to work very well. The final executable (including all BMPs and WAVs) was a little over 600kB (vs. 1.6 MB for the original exe and data files).

2) Launch times are indistinguishable from normal (but this is a small program).

3) Audio worked perfectly. I modified the original program to play an MP3 in the background (single call to playmusic) and stuck the MP3 in the packed archive. No problem.

Note: the MP3 file blew out the size of the final executable. My 600kB figure does not include the MP3.

Edit: I went and made the sound support a little more sophisticated, including (1) preloading the music using loadsound and then looping it, (2) panning the channel to match the position of the player -- still no problems.


Rook Zimbabwe(Posted 2004) [#9]
Just for the record... you can encrypt the PAK file too. I think both programs are good... I used PAKmaker on my latest game. Blitz3D compiled 12k of code into 1.46M and the music and sound effects and models (4, small) were in a 3.2M .RES which had been encrypted. Then I used PUREINSTALL to set up the install program and that packed BOTH down to 1.89M so it went from 4.7M to 1.9M and will install itself... (PUREINSTALL is fre as well but I think there is an upgrade you can buy!) :]
-RZ


podperson(Posted 2004) [#10]
With PAKed files, the decompressed -- and unencrypted -- file is present on your hard disk at least momentarily while your program is running. So the fact that your files are "encrypted" is not that useful.


Rhyolite(Posted 2004) [#11]
Ohhh, thanks for the heads up on Molebox - not heard of that. I think its biggest advantage over PakMaker is that it never unpacks a temporary, unencrypted file. Biggest disadvantage is $49!! Yikes, thats pricey!

And as mentioned, if your going to use PakMaker, make sure you do from the outset and write yourself functions to replace all your blitz load commands (mine include a 'development' mode which uses standard blitz commands and a 'release' mode which uses PakMaker commands).

Rhy Out


jhocking(Posted 2004) [#12]
Have you looked at the other packer tools available for Blitz now? If you look in the Toolbox->File Utilities you'll see BBCruncher. I haven't actually tried that one but it's another option to try.


WolRon(Posted 2004) [#13]
Is it possible to create a truly standalone exe file using BlitzBasic?
There is always the DATA statement...

Some 3rd party IDE's (like VisualBlitz) can take any external file and include it into your code as DATA statements (with a section of loading code as well).

Here is an example of including an image file with Visual Blitz (it wrote everything you see):

Note however, that the file is not compressed or anything.


Seldon(Posted 2004) [#14]
DATA statements to store media isn't a good idea for two reasons: for each byte of your media file, you'll get TWO longs (one long is the byte converted as long because Blitz handles just longs.. and the 2nd long is always 0 and it's used by Blitz for internal use). OK, you can compress the MEDIA file, but then it comes the 2nd reason: you'll load your media files two times in memory. A solution is to use the resource section of EXE files and access it with WinAPI functions. Resources aren't loaded when you run the EXE (like DATA), but only when you call the function (LoadResource() , etc..) and then they can be freed when you'll have your image created. It works fine with Blitz.