> From: "Frank Lesser" <Frank-Lesser at Lesser-Software.com>
> Date: Sun, 22 Jul 2001 03:32:28 +0200
> 
> Hi Tim,
> 
> ok - please regard it simply as my opinion - a decompiler cannot be
> removed - it may be offered by a third party as in the Java world.
> 
> But how you will answer the question if you try to convince someone to use a
> specific Smalltalk environment -
> he will ask - it is your favourite tool - but is it maintained will it exist
> in a few years, and so on.
> 
> By translating Smalltalk to something - a few years back there were at least
> a demand on translating to Java -
> you can maybe convince someone to make a decision use a high productivity
> environment.
> 
> I didn't say translation is the king way - But it can be one feature which
> helps ...


The point is that any form of a program can be translated in any other
form, given the equivalence theorem of all Turing machines.

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.  

Actually the hardest  part is in effect to  retrieve meaningfull names
to the objects found  in the program.  But even this is  not much of a
problem  for a  competent  programmer  : just  read  the "source"  and
understand what it does from what it really does (finding all the bugs
by the  way...), and  name them. Well,  some variable will  stay named
_t08543,  which is as  meaningfull than  those i,  k, dummy,  and temp
variables.



Note also that not having the names of all the objects of a program is
often  not a problem,  because you  can patch  it the  same, replacing
parts you've identified or adding your own objects.

Let  me see,  the last  time  I've corrected  a bug  in an  OpenSource
program, it was:

  102 files,  35724 lines,  166973 words,  1151330 bytes in total

and I  actually opened  5 or 

    6 files,  3549  lines,    15870 words,  104996 bytes, 

but actually  read only a  small part of  them (like one  procedure in
each), and edited just two lines in one file.

I  would say  that's  typical. In  another  case, where  I changed  an
algorithm  that had  quite  wide-range repercusions  on  a program,  I
changed 9 files over 157.



Therefore I  would say  that to  abuse of your  programs, one  need to
understand only 5% or 6% of it, and this can be done whatever the form
it's in. Even when we'll have  the technology to encode such a program
into DNA, we'll have it to decode it and it'll still be that easy.


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.


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.


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT d? s++:++(+++)>++ a C+++  UB+++L++++$S+X++++>$ P- L+++ E++ W++
N++ o-- K- w------ O- M++$ V PS+E++ Y++ PGP++ t+ 5? X+ R !tv b++(+)
DI+++ D++ G++ e+++ h+(++) r? y---? UF++++
------END GEEK CODE BLOCK------