cincom visual works non commercial 
Author Message
 cincom visual works non commercial

can i make stand alone executables with visual works non-commercial Smalltalk
from cincom?

if so can anyone give me a few hints..or where to look for help!

Sun, 25 Jan 2004 23:57:00 GMT  
 cincom visual works non commercial


> can i make stand alone executables with visual works non-commercial smalltalk
> from cincom?

> if so can anyone give me a few hints..or where to look for help!

Use Runtime Packager - it's documented in the vwadg.pdf

James A. Robertson
Product Manager (Smalltalk), Cincom

<Talk Small and Carry a Big Class Library>

Mon, 26 Jan 2004 00:58:15 GMT  
 cincom visual works non commercial


> can i make stand alone executables with visual works non-commercial smalltalk
> from cincom?

Yes.  5i.3 provides support for Windows.  5i.4 adds support for Mac
(thanks to Roland Wagener!).


> if so can anyone give me a few hints..or where to look for help!

Look in the betas/packaging/
                        WindowsPackaging.txt file

I've attached them..

Eliot Miranda              Smalltalk - Scene not herd

[ MacPackaging.txt 8K ]
VisualWorks(R) 5i.4 PowerMac Packaging ReadMe (beta)
Copyright Cincom Systems, Inc. 2000-2001. All rights reserved.

Packaging the VM and Image as a single file

Traditionally, a VisualWorks application is distributed as a virtual machine and
a virtual image files, possibly with additional support files.  It is now possible
to combine the VM, image, and other resource files as a single executable.  This
option is provided as BETA functionality only.

Building a Custom VM

This option requires the use of the C-Development environment MPW, which is a free
product and you can download it from:

Read the following description before actually using it.

First of all, combining an image file and a VM creates a new application in terms of
the Macintosh operating system.  Some constraints to remember:
 - The image file should be a runtime image created with RuntimePackager. The idea is
   that this combination is a stable state, that means the image is not to be saved
   again after deployment.
 - There is a size limit to the image file of 15MBytes right now.
 - The image is stored into 'DATA' resource 128 of the virtual machine.
 - After you combined a VM and an image, you are able to save the image as a
   separate file, if you wish, but it cannot be saved back into the resource.

Creating such a combination of a VM and an image is done using a variant of the user
primitive makefile. See file 'bin:powermac:userprim:README.VMWithImage' for basic
advice on the combine task. Because of this reuse, it is perfectly possible to combine
an image with a user-primitive VM, it can be done with the same makefile.

The result is a single file, a double-clickable application with some important things
to remember:
 - the creator of this new application is still 'HPS6',
   the creator code for VisualWorks 5i.4,
 - it has the same bundle resource as VisualWorks, so all file types described
   in section '8.0 TypeCreator settings' of the bin:powermac:readme file are still
   associated with this application,
 - you therefore can still drop VisualWorks image files onto this application,
   which then will ignore the image in its resource fork.
 - both shared libraries 'StdCLib' and 'NetManage WinSock Lib' need to be available
   for the resulting application. (StdCLib can be ommitted on MacOS 9.1)

In order to make your new application a stand-alone application, you need to edit
certain aspects with ResEdit, or another resource editor on the Macintosh.  Because
ResEdit is free, I will describe the tasks using this tool.  First, your application
needs to get a unique creator code, which is a four character word, and second, its
bundle resource needs editing. And some issues have to be handled on the Smalltalk side.

Unique creator code

You should register a four character code, all uppercase, with Apple in order
to be shure to have picked a unique code. Go to:

where every person can register creator codes. The service is of course free.
To only check whether your chosen code is available, go to this page:

If you have received the confirmation email from Apple, you can open your application
with ResEdit. Do it this way:
 - open ResEdit,
 - choose your application file for editing,
   a window with many labeled icons will open (called the ResourceWindow),
 - choose 'File->Get Info for this File', a big window opens,
 - enter your creator code into the entry field 'Creator:',
 - uncheck the checkbox 'Inited'.

You may close this window, and save your file in this state. However, if you haven't
changed the bundle resource yet, there are no new icons to be displayed for the Finder,
so you might have to repeate the last step and the file saving again.

You can now save your file, or continue editing the bundle resource.

New bundle resource

A bundle resource defines which icons should appear for certain file types, and for
the application itself. Furthermore, it tells the OS, which type of files this
application is going to 'like', that is, which kind of file this application accepts
when you drop one onto its icon. This has to be planned upfront, you should have a
good understanding of what file types your application is going to handle.

File types are made up of four characters, you are free to choose any combination,
these types are not registered centrally, but you should be aware of some which have
been around for quite some time:

  TEXT - for text files using MacRoman character encoding,
  JPEG - for JPEG-compressed graphics files,
  TIFF - for TIFF-encoded graphics files,
  W8BN - for a MS-Word document,
  XLS5 - for an Excel Spreadsheet.

If you look at the VisualWorks bundle resource, you'll see several entries:

  APPL - is the type of the application itself, so these icons are the application
         icons in various color depths,
  HPS6 - is the creator type, all image files are marked with this type, and get
         their icon from this bundle resource definition,  

and other resources for more types.

You should have some icon pictures available before doing the next step, or you can
paint icons directly in ResEdit.

 1. Open your application file with ResEdit or get the ResourceWindow to the front,
 2. Double-click on the icon labeled 'BNDL', which will open the bundel resource.
    There is only one resource with ID128 available, and you need to replace this one.
 3. Select bundle resource 128 and choose 'Edit->Cut' to remove the old resource,
 4. Select 'Resource->Create New Resource' to create a new, empty one.
    The window that opens now is the list of file types accepted by your application.
    It is currently empty.
 5. In this file, first enter your creator code into the entry field 'Signature:'.
    This has to be the same code you entered in the 'Creator:' field in the
    'Get Info for this File' window; otherwise all icons are ignored.
 6. Then choose 'Resource->Create new File Type' to add a new type. The list now
    contains a line with file type '????' and some icon slots,
 7. Select '????' and replace the question marks by 'APPL',
 8. Double click on the icon slots, and an icon dialog will open.
    The icons presented are currently available to ResEdit.

 9. If you don't like them, choose 'New' to open an icon editor.

    By and large, the editor works like every pixel based image editor; you have
    to paint an icon for different screen resolutions: one for black-and-white,
    one for 16 colors and one for 256 colors, and a mask. There are two icon sizes
    for each screen depth, so you have to paint eight icon pictures for one file
    type.  However, you can copy-paste stuff from other graphics programms.

Repeat the last four steps for each file type your application should handle.
Then save your file.

There is the possibility that the icon you just painted doesn't show up immediately
after saving your file. This might be due to the fact that the MacOS Finder didn't
realize that new icons are available. In this case open the 'Get Info for this File'
window again and uncheck 'Inited' again, and save the file again.

Smalltalk issues

Two Smalltalk issues have to be dealt with when using files of a certain type
and an application combined of a VM and an image:

 - how does your application access files on startup, and
 - how does your application save files.

Your application could be started up by drag-dropping a file of a type you
added a bundle resource entry for onto its icon. If a file of such a type exists,
which has its creator type set to the one your application has, then you can
even double-click this file and your application will startup.

Your Smalltalk application can only access these file(s), if parcel MacExtra is
loaded. MacOSFilename>>getStartupFiles gives you the list of files, and your
application code can take care of these.

If your application creates a file, it has to set the file's type and creator after
actually saving the contents. Your code should do something like this:
    newFile := 'test' asFilename.
    stream := newFile writeStream.
    [ <write to the stream> ]
            [stream close.
            newFile setFileCreator: myAppCreatorCode andType: myDocumentType].

Assuming that 'myAppCreatorCode' is your registered creator code for your application
while 'myDocumentType' is one of the types you entered as a supported file type in the
bundle resource. That way your saved file shows up with the icon you entered in the
bundle resource when viewed with the Macintosh Finder.

7/13/01  Roland Wagener
7/17/01  bb

[ WindowsPackaging.txt 6K ]
Beta Packaging Facilities on Windows

Packaging an Application as a Single .exe

With this release, we are Beta testing new functionality that allows one to
package an application as a single .exe file on Windows which contains both
the  ObjectEngine and the image.  The image can optionally be in a compressed
format, so that  the resulting .exe file is roughly half the size.

We do this by allowing the image to be stored as a resource in the executable
file.  You take one of our ObjectEngine executables and your image file,
and create a new executable file with our ObjectEngine as the code and the
image file as a resource  One can also optionally include resources in the
executable file for
        --program icon; the default icon that Windows will use
        --application name; which appears in the title bars of ObjectEngine error
                                                messages (which you've never seen, of course)
        --splash screen bitmap, which appears at startup
        --startup sound file

When that executable starts up, the ObjectEngine checks to see if any of
these resources are included.  If there are image, bitmap or sound resources
the ObjectEngine will use these resources rather than the image, bitmap or
sound file that it would otherwise use.  In addition, if there is an image
resource, then the ObjectEngine will ignore any command-line parameters.
This allows the packaged application unfettered access to the command line.

Adding Resources

In order to take our ObjectEngine exeutable file and add resources to it you
will need a resource editing tool which we do not supply.  It appears that
Microsoft's tools cannot add resources to .exe files, and only support adding
resources at  link time.  Fortunately there is a freeware tool written and
generously provided by Angus Johnson called ResHacker, see
You will need version 3.1 or better of ResHacker. Version 3.2.2 is in in this directory.

The resources must have these resource names and identifiers, which are used
by the ObjectEngine to look-up the resources:
        image: 332, 332
        icon: icon, 323
        startup bitmap: bitmap, 324
        application name:  325, 325
        startup sound: 326, 326

The icon should be in .ico format, the bitmap in .bmp format, the
application name in .txt format and the sound file in .wav format.

Note that with the non-commercial version it is not possible to change the
application name or the startup bitmap.

To create an exe containing an image using ResHacker, you can use the
following.  Make sure you specify a different name for the output executable,
here  called myapp.exe!  If you use tha same name (e.g. visual.exe) then you
will modify the standard ObjectEngine.

        ResHacker -addoverwrite \vw5i.3\bin\win\visual.exe, myapp.exe,, 332,332,

You can then add your icon, bitmap, application name and sound similarly

        ResHacker -addoverwrite myapp.exe, myapp.exe, iconfile.ico, icon,323,1
        ResHacker -addoverwrite myapp.exe, myapp.exe, bitmapfile.bmp, bitmap,324,
        ResHacker -addoverwrite myapp.exe, myapp.exe, appname.txt, 325,325,
        ResHacker -addoverwrite myapp.exe, myapp.exe, soundfile.wav, 326,326,

After each step check ResHacker.log as if there are any errors they will be
reported there-in.

Compressing an Image

For compactness one can also compress the image file using the file
imageCompress.exe in the same directory as this file. This usually
compresses the image by just over 50% and does not appear to slow down
start up appreciably on machines of ther performance of a 400 MHz
Pentium II.  Your results may vary, depending on processor and disk speed.

imageCompress uses the gzip library, available from <<include reference and
URL>>> to produce a file that is the the image file compressed.  Do the
following to produce a file named "":


This will create a compressed copy of the image in in a new
image file  Note that in this release compressed
images can only be loaded as resources.  SWe expect to support loading
compressed image files in the next release.

Image Startup Considerations

If you've read the memory management documentation in detail, you will know
that an image file is essentially a dump of the Smalltalk object space.  The
addresses of objects in an image file are therefore those of the objects in
the system that snapshotted the image file.  Different platforms may place
the object space at different addresses.

If an image is started on the same platform as it was saved, and if it
loads the base of the object space at the same memory location, then the
image's pointers are known to be correct and do not need to be updated.
But if the base of the object space changes, for example because an image
is loaded on a different platform or because the snapshot was a "perm save",
then all of the image's pointers will need to be updated, or "swizzled".
This should increase image start-up time slightly.

Although the base of the object space is affected by a number of factors,
in general it will be the same if a snapshot is loaded on the same platform
on which the snapshot was made, so this swizzling is usually  avoided.  But
adding signficantly large resources to an executable will push the base of
the object space to a higher address, so executables created as describe above,
from an image created by a non-resourced ObjectEngine, will need to be swizzled
and will have slower than necessary start-up time.

To get an image that will probably load at the same base, you merely need
to snapshot it from an already-packaged exeutable (containing that image or
something close).  It appears that Windows rounds the program heap to a
64Kbyte boundary, so  the original image can differ slightly without causing
a change in the actual heap base.  There's currently no way to confirm whether
swizzling is/was necessary.  But we expect to provide a way to check in the
next release.

As an example of such application image production using RuntimePackager,
and compressing the image, you would need to go through the following steps
        1.      Create the first Runtime Packager image
        1.5 Optionally compress the image with imageCompress
        2.      Create a single .exe containing the image and any other resources
        3.      Launch this .exe which will snapshot to produce the second image
        3.5 Compress  the second image if you're compressing
        4.      Replace the image in your single .exe with the new image
        5.      Launch this .exe which will snapshot to provide the final image
        5.5 Optionally compress the final image
        6.      Replace the image in your single .exe with the final image

Mon, 26 Jan 2004 04:48:21 GMT  
 [ 3 post ] 

 Relevant Pages 

1. Cincom Smalltalk Non-Commercial

2. Cincom Visual Works grid

3. is wiki works non commercial?

4. Need Visual Age, Visual Works, and Visual Wave Smalltalk mentors and developers and C++ designers/developers

5. Is Visual Works 7 Non Commercial Available for download?

6. Cincom Announces Cincom Smalltalk's latest Release

7. Cincom announces Cincom Smalltalk January 2000

8. It's Cincom, not CinCom :)

9. cincom download don't work

10. Smalltalk Developer Visual Works-Visual Age Perm job in MN

11. Visual Age vs Visual Works with Gemstone


Powered by phpBB® Forum Software