Review of Fusion 1.0
I must admit that after talking with the PR guys at BitArts, I was impressed. Fusion seemed to have it all and infinitely more.
So I checked out their evaluation copy, available as a free 1.3MB download. Installation was a doddle, eating a mere megabyte of disk space. But be aware you'll need to install on a machine with Internet and e-mail access to complete the initial registration.
After skipping the nag screens, the first thing that strikes you is the aesthetically pleasing user interface. The options are exceptionally clear and you really don't need to delve into the help file to get started.
Creating a completely self-contained executable consists of three separate main steps—selecting the file, adding any dependencies, and then processing. And it's all surprisingly easy.
So I decided to try it out on my project—Sahara—an Internet content extractor I've been working on...
Selecting the File
The first step is to select your compiled file. This could be an EXE you created using Visual Basic, or perhaps a DLL, OCX or Screen Saver file.
I went and ahead and choose my VB-created 'Sahara.exe' executable.
I also specified the filename of the soon-to-be-made, self-sufficient EXE. In the evaluation version, it will be named 'bitarts_evaluation', no matter what you enter.
The BitArts website says the final program won't run if that 'bitarts_evaluation' name is changed, though I personally managed to chop it down to just 'bitarts', without any problems.
To the hobbyist, such a name may not be much of a problem—but it's a clever way to get hardcore programmers to register and rid of the limitation.
Add Any Dependencies
The first thing I noticed in the Dependencies tab was that Fusion had already detected this was a Visual Basic executable and added the Visual Basic 6.0 runtime library (MSVBVM60.DLL). Hmm, impressive!
But of course, most projects rely on much more than just the VB runtime. They use external OCX controls and weird-sounding DLLs, too. And to handle this, Fusion has a built-in function that can analyse the original Visual Basic project file and automatically add dependencies for you.
I tried it with my Sahara.vbp project—and it added both an OCX and DLL file that I'd referenced in my project.
But for whatever reason, Fusion skipped one very important file—a custom DLL that was definitely referenced in the project. Still, no harm done—I simply manually added it to the list of dependencies by clicking the little + button.
Processing the File
So we've selected the file and added the dependencies. Now for the crunch.
After clicking the Progress tab, I hit the 'Run Fusion' button.
Five minutes, two 3D progress bars, and a lot of whizzing and whirring later, the program had finished processing—and a smooth-look chart appeared on the screen.
The graph displayed a comparison—the total size of all the files compared with the size of my newly created, compact EXE.
Mine cranked in at 1.2MB, from an initial 2.6MB. Not bad, huh? Compression rates typically range at between 50 and 70%.
And all that chopping, changing and squeezing means the probability of a decompiler getting its hands on my valuable code is also dramatically reduced. A double whammy if ever I saw one.
However I can't say this last step was always problem free. If you try opening Visual Basic whilst Fusion is running, you'll receive an illegal operation error. And I occasionally received 'dependency is already open/locked' messages, causing me to reboot then try again. And again.
But these nitty issues are really the exception rather than the rule. Most of the time, I ended up with a small, all-inclusive executable complete with all its required OCX and DLL dependency files. And it could all fit on one disk!
Incidentally, I went ahead and tried the executable on two separate computers to ensure it worked. And it did—the DLLs were registered, the OCXs put in place, and the main project file fired up. In a word, it worked—and well.
Page 2 of 3