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] |
Free forum by Nabble | Edit this page |