Deployment questions

All,

I'd like to be able to deploy "plug-ins" for an application I'm developing.
I've looked through the Education Center and all the information seems to be
there.  But I'm lazy.  Has anyone published a working example of such?
Basically I want to import binary packages at run-time and send messages to
classes in said package.  Before I do this, I'd like to know how to query
the binary package to make sure it "conforms" to my plug-in "spec" (whatever
that is--probably just some reflection to make sure it's a plug-in for
_this_ app, and maybe some meta data to display to the user) and be able to
un-load it at run-time (unload the package once it's unused).

Finally, I have a question about deployed executables.  I've poked around
the PE structure with some tools, and I _think_ that the .DLPHSGT segment
contains the binary guts of the stripped image, but would like to know a
little more about this process.  Mainly, I'm concerned about reverse
engineering of the code (mainly just Strings embedded in the image
containing selector names and any String literals (like registration codes,
etc.)).

So...  Has anyone done anything like this, and are you willing to share?  If
this is as yet undone, can someone point me in the right direction and give
me pointers/tips/thoughts on how to go about this?

Adobe Acrobat has plug-ins, so why can't/don't we?  As long as security
concerns are addressed (signed packages should work), I think this would be
a total plus for us, and allow us to rub others' noses in it.

Cheers,

--G. Krupa

> little more about this process.  Mainly, I'm concerned about reverse
> engineering of the code (mainly just Strings embedded in the image
> containing selector names and any String literals (like registration
codes,
> etc.)).
>
> So...  Has anyone done anything like this, and are you willing to share?
If
> this is as yet undone, can someone point me in the right direction and
give
> me pointers/tips/thoughts on how to go about this?

Reverse engineering is a risk.  My first thought is that, in general, one
should use Smalltalk to build something so slick that it becomes
sufficiently effective that the competition would be motivated to reverse
engineer your work.  That will probably take a while.

Registration code/passwords are obviously at more immediate risk.  You might
address it by storing the hash in your code and hashing user input; that way
the clear text code/password never appears in your exe.  You can also bounce
things through some encryption to make it harder on an attacker, but hashes
are probably more effective.


> Adobe Acrobat has plug-ins, so why can't/don't we?  As long as security
> concerns are addressed (signed packages should work), I think this would
be
> a total plus for us, and allow us to rub others' noses in it.

IMHO, you can rub their noses in it all you want, but it won't matter
because everything is in "that funny language".  Not to knock binary
packages, but the extension developer will have to work in Dolphin too -
"that funny language" again.  You can use COM or DLLs to allow people to
write extensions to a Dolphin app, and they would be able to use their
favorite C* language; that _might_ attract some developers, but only if
you've gotten them hook on your basic app.

Unless you expect large scale customization efforts, I think you're better
off keeping things simple and deploying apps often.  Dolphin's stripping has
improved greatly over time, and bandwidth is becoming plentiful.  Of course,
I'm _still_ using dialup at home, mostly because I download at work and take
things home on Zip/CD/Flash.

One problem with deploying monolithic apps is that you can get caught part
way through a new development, with the concern of breaking old features
along with the fix.  Keeping a good association between executables and a
backup of the image that built it/them would help - not that I've actually
done that =:0

In short, I see modularity as something that people do to in large part
because they've been told they should, and also to compensate for huge
compile/link/debug cycles that Smalltalk avoids in a better and more
reliable way.  Unless modules are designed very well, they turn out to cause
far more trouble than they fix.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]