on GitHub

Molebox Virtualization

by Alexey Sudachén


MoleBox Virtualization Solution (MoleBox VS) creates application-specific and secure virtual environment for your software applications, isolating them from the underlaying operating system and other software installed and running on the host device. It is achieved by placing the application and all of its elements into managed packages which form the following virtual layers in runtime:

Create virtual environment for your software

MoleBox VS lets you convert your application into an all-sufficient stand-alone executable, containing everything needed: components, media assets, registry entries and runtime settings. Moleboxed environment is private and secure, which means that all packaged elements are available to your application only and are protected from any unauthorized access.

Create portable applications

Traditional software setup process frequently requires administrator privileges, includes installation and registration of many components, and may take significant time. Portable moleboxed applications run without installation on any computer, from any source - USB device, CD-ROM, or network drive. Moleboxed software can run without altering host device file system: it does not extract original files not creates temporary files, and can be easily and cleanly removed when necessary.

Use any components and runtimes without installation or registration MoleBox VS allows embedding DLLs, ActiveX and .NET components, as well as VB, Fox Pro, Java and other runtimes into your application. Embedded components are loaded on demand directly to the memory and are never extracted to disk. Due to virtual registry technology, you can use ActiveX components without registration, without any changes to the host PC registry.

Run from user level, without administrator privileges

Moleboxed applications require neither installation no modifications to the host device registry, and run in user mode, without administrator privileges. Your end-users won’t be discouraged with security warnings or any other problems running your software.

Avoid application conflicts, DLL hell and registry root

With MoleBox VS you can create zero-install applications which are isolated from the host device, protecting it against changes to environment, registry and file system. This allows using multiple versions of same applications, components and runtimes at the same time without conflicts.

Manage your software distribution, simplify delivery, reduce support and testing cost

Moleboxed applications can be delivered in a single executable that runs with zero setup. MoleBox VS allows easy creation and distribution of software updates, by creating additional packages and delivering them to end-users.

MoleBox virtualization technology eliminates the need to test software on different configurations. Software developers and IT managers may package software once and deploy to different operating systems without repackaging.

Despite its outstanding functionality, MoleBox is very easy to use: you don’t need to deal with complicated settings, create installation programs or make system snapshots. All you need is to pick out the files required by your application and pack them.


Virtual file system features

Virtual registry features

Virtual environment features

Deployment features

System Requirements

MoleBox VS processes native 32bit and .NET applications 2.x+ and supports Windows 2000/XP/Vista/7/8/10 operating systems. It is compatible with a wide range of software development tools.

How To Package Your Application

MoleBox processes software applications by placing them into one or more managed packages. Each package contains a virtual file system including some files of your application suite, and may also contain virtual registry entries. In the simplest case, you can put all application files into a single EXE file.

If a package contains the main EXE file of your application, it’s called executable package and it should be compiled into an EXE file. Other packages are compiled into files with extensions of your choice.

When an executable package starts, it can mount other packages and use files they contain. Packages are mounted by file name pattern (mask), in alphabetical order.

Projects are stored in MXB files. You need to create a separate project for each package.

You can create packages through MoleBox GUI or through command line interface. Please note that some advanced features are not available through GUI.

Creating Packages Through GUI

To create a moleboxed package, follow these steps:

Please note that some advanced options are not available for editing through GUI, but if any of them present in your project file, MoleBox will spare them.

Setting Package Options

In the Tools menu, select Options…, or click Package Options… button in the toolbar. Package Options window opens.

Adding Files

The main window displays contents of the current package in a tree view and allows you to modify it.

File name column displays short name used to access the file from the packed application(short virtual path), File path on the local disk shows the name of the source file relative to the project file location.

Use toolbar buttons or Edit menu items to fill and modify the package contents. You can either add entire folders or separate files. If you add a folder, its subfolders are recursively added as well. Additionally, you can create virtual folders – folders inside the package, which allows building directory structure different from the one on the hard drive. You may also assign a different name (alias) to a packed file by renaming it.

Important notice on virtual paths

Virtual path (file name alias; file name used by the packed application to access the file) always starts from VFSROOT (virtual file system root folder). In the simplest and case, virtual path can be the same as the real path.

For example, your application consists of the main executable \bin\main.exe and a sound file \music\track1.ogg. In the original application, the path to the music file would be ..\music\track1.ogg. When creating a data package, you may add track1.ogg to the main directory, VFSROOT, and then the virtual path would be track1.ogg. Or you can create a folder music under VFSROOT, so the virtual path would be music\track1.ogg.

Compiling the Package

At this point your configuration is ready for packaging.

To start packaging:

Creating Packages Through Command Line

You can also create packages using command line packaging tool, mxbpack.exe. This tool allows generating packages either using project files created earlier (learn more about project file syntax) or without project files, specifying a list of files to pack directly in the command line.

Command line tool has the following syntax:

using: mxbpack.exe [options] ~~ @<mxbconf.mxb>
using: mxbpack.exe [options] ~~ -o external.dat [[!/#/*][~0/1/2/*]file[;pack_as]]
using: mxbpack.exe [options] <pefile.exe> [-o out.exe] [[!/#/*][~0/1/2/*]file[;pack_as]]

Returned value:


Parameter Meaning
<pefile.exe> Main executable for executable packages; ‘~~’ for non-executable packages or when using an existing project file
<out.exe> Output file name.
@<mxbconf.mxb> Existing project file.
file files to add to the package.

The following options are available:

Option Meaning
-V print program version and exit
-? print option’s help and exit
-o <outputfile> new name for package or wrapped file
-B blindly auto-bundle all non-system dependencies
-l enable virtualization logging
-O build/use virtual registry
-H hide all files
-C <0/1/2> if file named like embedded exists on a disk: 0=>use embedded, 1=>use external, 2=>access error
-D <envar>=<val> define environment variable
-e/-a <dllname> ‘-e’ embed activator dll or ‘-a’ use external one
-c <cmdl-args> override commandline arguments
-F do not encrypt executable extradata
-z slice executable and store inaccessible via VFS
-s opposite to -z, store original EXE as-is in default package
-S <container> use defined container instead original executable
-q don’t touch import table (required for some theme hacks)
-Q don’t touch RSRC section
-p <password> current package password
-P <password> externally mounted packages password
-m <filemask> externally mounted packages mask
–usereg virtualize registry but not build it
–regfull virtualize registry totally
–inject inject virtual environment to child external process
–regmask *.reg file mask to import registery files on start
–company “name” company name to add into version resourcses
–autoreg <opt> none, onstart, onpack. The onpack selected by default
–tls <size> minimal size of tls area in (bytes)
–image <size> minimal size of executable image mapping (kilobytes)

Options set via command line override the same options from the configuration file.

(*) What does auto-bundle all non-system dependencies option do? MoleBox recursively adds to the packaging all non-system dependencies of the application; only those that are normally visible with Dependency Walker will be added. The list of added dependencies is displayed in the packaging log. System dependencies should be embedded explicitly.

Files list includes absolute or relative file names, and may also include file aliases.


Processing an existing configuration, either executable or non-executable package, without modifications:

mxbpack.exe ~~ @mxbconf.mxb

Integrating 2 DLLs into an EXE file:

mxbpack.exe program.exe -o packed.exe libs\lib1.dll;lib1.dll libs\lib2.dll;lib2.dll

Creating Patches and Updates

Moleboxed application can mount multiple packages in certain, alphabetical order. Files from packages loaded later replace files with same names loaded earlier. This ability can be used to create and distribute updates to your software. All you need is to create a new package and distribute it to your users.

To create a patch or update:

If you need to replace the main executable, you have to rebuild and re-distribute the executable package with the options used before.