Smalltalk deployment

Andrew C. Greenberg werdna at mucow.com
Mon Jul 23 15:06:47 UTC 2001


>> 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 ? ****

The Georgia Tech reverse engineering web site.  Borland's decompiler.  
The linux reverse engineering toolkit.  Between you and me, I'd never 
begin with decompilation, for the reasons stated before, without knowing 
that the particular development system used for the binary would be 
sufficient -- its too much and not enough.  I have torn apart other 
works, both from a legal analysis and during a clean room analysis 
myself.  As I noted, there is no substitute for a good macro 
disassembler.

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

Then let us set this point aside.

> I pointed out that in general for Smalltalk apps you give ** 
> potentially **
> your sources away .

Look, this is an open source environment.  I have been contributing for 
free because of the reciprocal benefit of my colleagues' contributions.  
I agree to do so, knowing that others may take certain parts of my work 
"private," so to speak, because it reserves for me the right to do so -- 
and I think freedom is a good thing.  But I don't have to approve of 
such conduct.  Frankly, I think this open source community should 
dedicate only slightly less than 0% of its resources to support such a 
feature, precisely because it is an anathema to an open source product 
(and also because solid obfuscation is a cake walk of a project that 
should be funded by the guy who decides -- however misguided -- that he 
needs its benefit).

And, for the reasons previously stated, it is not even close to a 
reasonable argument to seek translation to C.

>> 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 agree.  If you can give me both, great.  But you can't.

Let's be real, here, guys.  If write-once run-anywhere is important, 
then you need to preserve the abstraction of the virtual machine at all 
costs.  Indeed, even permitting plugins and FFI invites nasty 
machine-dependencies.  The first step down the road of losing machine 
independence is to give in to the passion for creeping featurism.  It 
always seems nice to ask for the privilege of making Windows for 
Windows, but it costs -- big.  Moreover, there didn't seem to be any 
need for it.  Earlier versions of Squeak had goodies and forks that 
permitted native and native-looking windows, and the projects were 
almost just as quickly abandoned and left to suffer bit-rot.

Perhaps, however, there may be some interest in permitting a few 
abstractions that could facilitate compromises.  One thought occurred to 
me -- it would be very nice to support plural Display objects, each 
owned by a particular window, perhaps corresponding to a non-overlapping 
rectangular slice of a global Display object if that would make things 
nicer.  It would be nice to abstract general OS-level window-related 
events, such as activating, deactivating, minimizing, and so forth, and 
to have a protocol for the handling of such events to be managed (above 
the OS level activities) in the Display object, or overridden by 
subclasses.

Programs might spawn off new OS-level window in much the way this is 
accomplished today, and could be reasonably abstracted to any existing 
modern VM.  For systems without "modern" GUI's, the windows could be 
plain ole' Smalltalk systemwindows.

But I wouldn't be willing to spend a dime of energy if that effort made 
Squeak lose its write-once run anywhere traits.

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

We are thrilled that folks are busy building on Squeak.   Its just that 
not all of us find these features beneficial.  The OS lock-in that 
inheres in the project makes it problematic, at least for me.

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

Sure thing.  I wasn't quibbling about that -- I was disputing the 
utility and usefulness of obfuscation technology for Squeak.  In fact, I 
think it is a terribly bad idea.




More information about the Squeak-dev mailing list