-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Andrew
C. Greenberg
Sent: Monday, July 23, 2001 1:55 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Smalltalk deployment


On Monday, July 23, 2001, at 05:02 AM, Frank Lesser wrote:

> 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 ... ).


This certainly is not the case: reverse engineering tools are readily
available (try a google search "reverse engineering tools").  Although
few reverse engineers use these tools, preferring to use a great macro
disassembler instead.  For most purposes, a decompiler is often too much
and not enough tool, unless you have one particularly tuned to the
particular compilers used to build the software.  In this, Frank assumes
that the user knows a priori that the program was written in a
particular Smalltalk system.  A relatively simple obfuscation effort,
elimination of tools from an image, and rebuild of the compiler could
hide this.

**** I tried this google search - could you please give one example which of
these result point
to a Reverse-Engineering Tool for Reverse Engineer Binaries ? ****

But who among us really cares about this?  I know nobody who chooses
development tools based upon obfuscation capabilities.  Who genuinely
believes that the lack of this "feature" renders a system unusable?  In
making this argument, please account for Java and VB.

**** I agree on it - I am not focussing on obfusc. as a important feature
which
needs to be implemented for Squeak - Squeak lives from its openess .
I pointed out that in general for Smalltalk apps you give ** potentially **
your sources away .

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

Maybe, but currently one of Squeak's greatest features is that a Squeak
program runs pretty much without modification on just about every
meaningful platform out there.  One can write a multi-media application
on a PC that will run on a Mac and Unix platform pixel for pixel
identically and without change.
Try that with Lagoon Deployment Wizard

****
I agree, but there are a lot of nice OS-specifc-features, e.g that guy (
comp.lang.smalltalk - a few days ago ) who seeked a solution to create a
Stephen Hawkings demo for his daughter looked first at Squeak and was just
given a hint from Andy Bower to use Dolphin together with MS-Agent.

I also don't like to rely on the OS-vendor lock-in too much - But I think it
is always nice to have options.
In our firm we have choosen Squeak as a development base for our LSWVST -
Smalltalk - because its wide avabiltiy on platforms which is possible
because it's GUI which relies on BitBlt. But we are busy providing true
OS-Integration
which isn't just implementing bindings to Windows API's. After having the
Windows bindings finnished we will target X' es.

So during development Squeak's - everything down to GUI Bits is an object is
really nice - you don't have to
care much about the API barrier dealing with a lot of C-structures
containing pointers etc.

Smalltalk has big advantages over other environments - but from time to time
it maybe usefull to discuss new features
to enable Smalltalkers to benefit from "outside" Smalltalk developments.

Cheers, Frank