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
|