Hi Paolo,
If you ask for how to build an EXE I guess you work on Windows and have already
experience with building
EXE's using other programming languages.
Typically IDE's for C/C++, Pascal, VisualBasic, ... provide this concept, you
have a main(),
WinMain() or other entry point function into your program and provide some
additional
resources (like a custom icon, version info, ...). The development environment
typically creates
a file with an *.exe extension - internally this is a so called PE-File
(portable executable) that
when clicked is loaded by the OS loader and starts in your predefined entry
point.
Unfortunately is not a very flexible way to package anything into a single
compiled executable.
It is hard to ship an update - since you have to redeploy the executable
anytime your program
changes.
Portable for EXE also means "portable on Windows only", since the PE-Format is
Windows specific.
Real portable environments that are based on virtual machines (VM) tyically use
another path: they
just have a single executable for the virtual machine itself. This virtual
machine is implemented
as a native windows, mac, Linux, ... application and your program is included
in one or more
portable file(s) running on top of this VM.
Take Java as an example: you have a Java runtime environment with an EXE for
the virtual machine
(java.exe) and your program is portable since it is defined in a (Java)
portable format (*.class files
and *.jar archives). In Java you typically also do not deploy an EXE, you
deploy the JAR archives
and if not preinstalled maybe the Java runtime environment (JRE).
Downside is: in Java the environment will have to be correctly set up,
otherwise the virtual machine may not
find the classes of your program - then you have to fight with loader problems,
class path problems, ...
Additional note: yes there are products in the market that allow you to also
create an EXE from a Java
program - but they do often nothing more than packaging up the program into a
single EXE file for better
handling - in the end they often use the virtual machine to run it.
Microsoft does something similar nowedays - if you build an EXE in C# you end
up with a native Win32
application in PE-Format that loads and runs the .NET runtime. So it is not
more than an entrypoint
into the more portable .NET world. Take care: while the basic concepts of .NET
are portable
(see Mono to run on Linux) the APIs are often very bound to Windows.
Smalltalk (and Pharo) goes one step further: it also provides a native virtual
machine (EXE) like
in the other environments - but all the objects, packages, resources, ... even
the IDE are hosted
in a single data file (called the Image file with an *.image" extension).
So you can compare it more with technologies like VMWare, VirtualBox, ... with
portable images
or portable game engines like ScummVM where the program runs on top of a VM and
is shipped as a single file.
To make long story short:
=========================
1. You typically and easy deploy by giving the Pharo VM executable away
together with your custom image
file (predefined for customer experience) and with you application setup
(typically in fullscreen).
2. If you want to hide that it is done in Pharo and "customize" it a little
bit more, specific on Windows:
A. rename the virtual machine Pharo.exe into "MyKillerApp.exe"
B. Prepare image
- disable "Check changes file availability" in the Settings browser
(if you do not need the code changes "*.changes")
- disable "Check sources file availability" in the Settings browser
(if you do not need the source code file "*.sources")
- start you app to take up the full space of the Pharo window (sample
can be found in http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher)
- do other things to customize, like providing a custom world menu
(http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/032696.html)
- save the image with a different name "MyKillerApp.data" (so no
image extension if you like)
C. You renamed the VM into "MyKillerApp.exe" (see Step A) so instead of
Pharo.ini the VM system looks for a "MyKillerApp.ini"
in the same directory. Add the name of your new image file here:
[Global]
ImageFile=MyKillerApp.data
...
So when the user clicks on "MyKillerApp.exe" the virtual machine is
started, reads the "MyKillerApp.ini" and
loads the "MyKillerApp.data" Pharo image.
D. If you want to have a nice custom icon use the "Resource hacker"
freeware tool to exchange the icon
of the virtual machine.
If you need more customizations just have a look at VM building. Using MingW,
CMake and friends and the Pharo
VM tool chain it is easy to rebuild and adopte the Pharo VM (executable) to own
custom needs. Here you can also
provide an own custom icon or other execuable properties (like version info) by
customizing the *.rc file.
You can also implement custom VM plugins ... up to a whole new Pharo ;)
An image is very very flexible. Note that you can even provide an own update
server - to update customer images
similar to how Pharo images are updated. If required and allowed the customer
can also save the image in different
states like saving a game. I would not recommend it - but technically it is
possible.
So depending how far you want to go (and how deep you will go into Pharo
internals) anything is possible for shipping
a customized environment.
Bye
T.
