|
Re: Win32 binary (and extensible) OO-perl applications
by simonm (Vicar) on Dec 03, 2003 at 03:57 UTC
|
Yes, it's a nice technique.
I first used it about six years ago, in a shrink-wrapped product called IntraNetics that my team at Evolution designed and developed under contract.
You can also use it to apply local patches without modifying the binary, if you have the new modules re-define the relevant subroutines or install a wrapper subroutine that does some extra work and then calls the original. | [reply] |
Re: Win32 binary (and extensible) OO-perl applications
by derby (Abbot) on Dec 03, 2003 at 12:42 UTC
|
... and some are free, as in speech.
nagios.
-derby
| [reply] |
Re: Win32 binary (and extensible) OO-perl applications
by hardburn (Abbot) on Dec 02, 2003 at 21:59 UTC
|
The evil part is, is that (for our system) the user-supplied query must be subclassed from a built-in base class, which is not delivered as PERL code to the end-user.
So? You're not supposed to know anything the base class is doing. As long as its interface is strict and well-documented, you won't have a problem. Unit testing should handle your problem.
Does anyone else think that it's pretty slick that a perlapp EXE can load on-disk perl modules
No, but I'm probably not the one to ask. I've gone through enough Perl golf that anything much less than a Schwartzian Transform doesn't impress me anymore.
----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer
: () { :|:& };:
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
|
|
So? You're not supposed to know anything the base class is doing. As long as its interface is strict and well-documented, you won't have a problem. Unit testing should handle your problem.
That's true, and I agree with that. However, I think that the nifty thing in this example is that they *can't* know anything about it.
It seems to me that Perl hasn't forayed into the commercial *product* market like other products. By that, I mean that you can develop a system in Perl (say, a web site), and you can sell that. Unlike other products, though, your end-user is free to muck about with it. In open source, this is A Good Thing, and I support it.
If you're trying to develop a product to sell, though, it can prevent you from handing out "demo" versions, pursuing upgrade revenue, or getting follow-on work.
Perlapp, in my mind, has been a nifty way to package up a piece of functionality, but before now it always meant that the end-user couldn't customize it or add to it (which is a beautiful thing in Perl). Now, with this approach, and a little planning, they can.
It's kinda like writing it in C, and letting your users plug in functionality with DLLs, except that you're still promoting Perl.
:)
-Dave
Update: Changed PERL => Perl
| [reply] |
|
|
Unlike other products, though, your end-user is free to muck about with it.
About the biggest difference between Perl and "other products" in this regard, is Perl does less to maintain the illusion of protection. The bottom line is, anything you give someone to run on their computer can be mucked about with. Granted, most folks won't have the tuits to break out a decompiler, or debugger, or whatever... but the opportunity is there for the taking.
I would go so far as to say about the only fool-proof way to keep your program secret is to not let people run it on their computer. Web applications are an excellent way to accomplish this. As things go, without knowing much about it specifically, I would presume PerlApp (along with other "Perl compilers") is probably one of the least effective ways to keep your program secret, short of giving out plain-text source.
I think most experienced Perl programmers realize this, and stop trying to fight it. If you make a great product, and provide good service to go along with it, that effort stands on its own.
PS: I second duff's recommendation. There is no such thing as PERL; only Perl and perl. People sometimes call it the "Practical Extracting and Reporting Language," but as far as we know this is a retronym, and was coined after the name was already chosen.
| [reply] |
|
|
I think that the nifty thing in this example is that they *can't* know anything about it.
On the contrary, if you're loading their Perl code into your process, they can find out just about anything.
For example, they could supply you with a module with a BEGIN block that walked through all of the package namespaces, dumping out subroutine names and variable values. They could also wrap relevant subs in a logging wrapper to observe the flow of function/method calls and the arguments they receive, dumping the results to a text file for later review.
In an extreme case, they might even be able to deparse your program back to source code using something like the B:: modules.
However, I agree that in the vast majority of cases, most people won't do any of the above, and your commercial application will be sufficiently safe. (To the best of my knowledge, nobody else ever used the plugin mechanism in IntraNetics other than in the specific ways we documented.)
| [reply] |
|
|
Yes it's cool, but no more so than using 3rd party libraries in C++, C, or any other typically compiled language.
And please, please, PLEASE, stop saying "PERL" It grates on my eyes. It's Perl if you're talking about the language and perl if you're talking about the program.
| [reply] |