Pascal Bourguignon wrote.
	It's as easy  to get a C-source from a  machine language "binary" than
	it is to get a Smalltalk source from a Smalltalk image. And as easy to
	translate   back  to   Smalltalk  from   a  C-source   generated  from
	Smalltalk.

I don't agree - while decompile Smalltalk is in most cases not difficult
- even it is used to save memory - putting temp names in a method's trail -
there exist ** no ** commercial or public available
decompilation system for C which ( despite of some experimental ones ... ).

	They are some  techniques that can be implemented  to make the program
	terminate when it  detects it has been modified. It  can be made quite
	difficult  to  circumvent these  mechanisms,  but  this difficulty  is
	bounded:  it's the  difficulty  of decompiling  and understanding  the
	whole program.

Agreed - none of these technics are available in form of tools for
Smalltalk-
but I personally believe there are much other features which Smalltalkers
needs first.


	Now I agree that all this can't be understood by a PHB, and you should
	probably follow Tim's advice  Tim, encapsulate your Smalltalk programs
	into a kind of "binary" file  that can't immediately be read back into
	a  Smalltalk  environment, and  show  him  how  you've been  ingenious
	inventing this  nice Smalltalk to binary-executable  generator. It can
	be  costeffective  to this  purpose  to  obfuscate  the names  of  the
	objects, which should not be a problem for a closed system.

Such things exist ( e.g. putting a SLL into a DLL for Smalltalk/V)

My point is that deployment ( extracting an application ) from Smalltalks
development
environment can be improved ... ( Dolphin has Lagoon Deployment Wizard ).