This is all so cool! Should have its on forum! ;)
By putting it on CPAN I bet/hope people will find it and support it!
Password inside the start.c is nifty! Although one have to compile it, but that wasn't much of a problem really... Really nice trick to keep the source safe. Having the script scrambled isn't as safe, just harder to get. With the password protected .zip I think its a better protection (although I'm not sure what kind of algoritm .zip uses). Also, adding it into the .c is also abit safer. However, probably quite easy for any hacker, but anyway.
Btw, what are you gonna call this packer? Packer::Start? :D
/ Ace | [reply] |
Packer::Start because of start.exe and start.c?
Of course that was application name and not technology name.
I thought something like Yet Another Application Packer...
Do you have better ideas?
BTW its often not easy to convince people that module is "kewl", they will still think that PAR is much better
I am a little bit surprised that someone (you) recognized approach as "kewl" :)
Its a great work (to recognize, I mean) -- people must step out dogmata a bit, and then do some research, and then compare, and then make conclusion.
People usually fail before the first step :)
| [reply] |
That's a problem yea. People go after what they know. Since I've been testing PAR, perl2exe out, I have some experiences. :)
Sure, they are good and seems to be working. However, things I've noticed with PAR that I don't like:
1. First of it doesn't clean up itself afterwards. Which is nice in one way, however,
2. I'm not sure how or if it "caches". That is, when running the same file again, does it extract all again or check if already extracted? Can be a problem if script is modified and it runs the same extracted data... and not the new...
3. In memory is WAAY faster aswell, not cluttering up hd. Besides, you shouldn't really rely on that there must be hd space to be able of running some application. It's damn annoying to run out of space in general and if hd gets full while running some app, just because you are just running it is even more annoying.
perl2exe is quite nice too. But since that is commercial I don't like it that much. ;)
Also, eventhough I doubt it, but if you "protect" your script using perl2exe, you never know if the creators of perl2exe can get your data.
Since I love doing stuff in Perl, and love the idea of one file, no installation hustle, PAR been nice, but your solution is better. Probably faster aswell. I do apps in perl, pack it and send it (and the reciever doesn't have to care about installing Perl and all modules needed for the script). With PAR it doesn't really feel good knowing it extracts "junk" that it never deletes. Sure, the standalone executable may be abit bigger, and not sharing files between other applications may seem like some waste of space, but in general I don't see how that can be too bad. Besides, having it all in one pack, you have all dependencies there and know that it works. A big plus is also that all files are packed in .zip and only extracted as needed (hopefully this means that same file isn't extracted twice!). Having it all in a .zip means even less space on hd. I'm jelous of programming languages like C/C++ in that way. But with your solution this is pretty close to that. Who cares that the binary may be abit faster than parsing and running scripts when most apps don't rely on pressing every clockcycle out of the CPU. With Perl you can archive your goals faster (and it doesn't have to be wierd, unreadable code) and you can concentrate more on the app in question.
I'm sure I've missed some other points about PAR and perl2exe that I discovered before, but I don't remember them atm.
YAAP could work although I prefer having a name that describes the module more... Hmm...
/ Ace
| [reply] |