Is there a CPAN module that can automate the famous ollydbg debugger?
If yes, could someone provide such module and some tutorials/documentaitons/example about it?
Googling brings up this:
http://www.openrce.org/downloads/details/220/OllyPerl
Note that it's from 2005 and provides this description:
Perl scripting for the OllyDbg API, Alpha-quality code, use at your own risk. Requires ActivePerl.
Also included in package is wavediff.pl, a PoC implementation of binary difference analysis via phase cancellation.
YMMV but the author still blogs & twitters.
Related
I need to package a Perl Dancer application for installation using RPM. Pretty much all of the Perl module/distribution tools deal with installing files into Perl specific locations, such as /usr/lib/perl. I need to be able to create an installation in a self contained location, such as /opt/foo.
I know about App::Build, which looks like it might be useful, and provides facilities missing from Module::Build. I expect there might be a Dist::Zilla plugin to do this sort of thing but I've been unable to locate one.
What tools would you suggest using for building, testing and packaging a Perl 'application'?
The layout of the application would follow normal Dancer style, with /public, /views, /lib, etc
You are mistaken in saying that Module::Build is missing the functionality to install additional (non-lib) directories. See the Cookbook.
I don't know if this helps at all. It describes what we do at work:
http://www.slideshare.net/p3castro/packaging-perl
Caveat: we use a common Perl install across all applications.
so I'm having a lot of fun with Perl at home for some time now.
How much more difficult do things get when you develop Perl modules (In my case it's mostly catalyst) in a team? How do we make sure we all got the same development environment (Perl/Module versions)? Simply by keeping up to date with CPAN? Do some teams setup their 'private' CPANs?
Using the following things should make your life easier.
check out local::lib you could easily then create a server that each member could sync these modules too.
You probably don't really want to mirror all of cpan. just the most recent modules which is why you'd use minicpan.
If you're using recommended modules in Task::Kensho then using the latest releases shouldn't be a problem as they should be surprisingly changing API on you. Basically by doing this you make sure you don't end up with your team reinventing the wheel or hopefully using 3 different modules that do the same thing.
And you want to make sure that your team uses good Perl coding practices and not the bad ones. There are a lot of bad ones. Read Perl Best Practices, remember it's just a guideline you should tune it too your team and your style.
local::lib
minicpan
Task::Kensho
Perl Best Practices
It is not exactly clear what is meant by "in a team".
If the team is at some company, the best solution is of course a shared directory where only the CPAN modules you need are installed.
If the team is a bunch of guys working collaboratively from their home computers, there are a couple of solutions.
One that comes to mind is as follows:
Have a shared "latest version of module to install" list in a file, accessible publicly from the web (on someone's home page, your favorite source control system, Google docs, whatever).
Write a little Perl script which retrieves that file from the web or checks it out of repository, loops over each CPAN module listed in the file, and verifies that locally installed version is the correct one. If upgrade is needed, have the script install update from CPAN.
Have that script run as a scheduled job (cron on Unix, or at/scheduler on Windows) as admin/root account, or at least account which has enough perms to install CPAN modules.
I won't provide details of script implementation, because I don't even know if this is for Windows or Unix, and doing all those tasks are fairly routine Perl coding - if you get stuck, you are always welcome to ask follow up questions on SO! :)
This is probably a multi-part question. Background: we have a native (c++) library that is part of our application and we have managed to use SWIG to generate a perl wrapper for this library. We'd now like to distribute this perl module as part of our application.
My first question - how should I distribute this module? Is there a standard way to package pre-built perl modules? I know there is ppm for the ActiveState distro, but I also need to distribute this for linux systems. I'm not even sure what files are required to distribute, but I'm guessing it's the pm and so files, at a minimum.
My next question - it looks like I might need to build my module project for each version of perl that I want to support. How do I know which perl versions I should build for? Are there any standard guidelines... or better yet, a way to build a package that will work with multiple versions of perl?
Sorry if my questions make no sense - I'm fairly new to the compiled module aspects of perl.
CLARIFICATION: the underlying compiled source is proprietary (closed source), so I can't just ship source code and the appropriate make artifacts for the package. Wish I could, but it's not going to happen in this case. Thus, I need a sane scheme for packaging prebuilt binary files for my module.
I look after DBD::Informix, one of the Perl Database Driver modules that works with the DBI (Perl Database Interface). The underlying libraries used to connect to IBM Informix Dynamic Server (IDS) are proprietary, but the DBD::Informix code itself is not. I distribute that code on CPAN, just the same as any other Perl module. People can download that source, and (provided that they have the Informix ClientSDK installed on their machine - and Perl and DBI and so on), they can build DBD::Informix to work with their installed Perl.
I would strongly counsel that you arrange that your Perl interface code be made available in source form, even though the library that it interfaces to is proprietary. This allows people to install the code with any version of Perl they have - without requiring you to deal with inconsistencies.
If you still want to provide binary support, you are going to have to work out which platforms you want to support, and build the module with the standard version of Perl on each such platform. This gets messy. You need access to an instance of each machine. Granted, virtual machines make this easier, but it is still fiddly and the number of platforms and versions only grows. But you still need to support people who don't use the standard version of Perl on their machine - that's why the Perl wrapper interface needs to be provided in source form.
DISCLAIMER: I have next to no experience creating binary packages that can easily be installed. Therefore, I am making this post CW to make it easier for others to add their advice.
You should make the distribution available in source form so it can be compiled on each system tailored according to the specifics of that system. I really like Module::Build for that purpose.
For ActiveState users on Windows, you probably want to have four or six PPMs based on whether you want to support 5.6. Package both 32-bit and 64-bit versions for each of 5.6, 5.8 and 5.10. Use the version of mingw you can install using ppm to compile the modules to preserve binary compatibility.
Another option is to use PAR::Packer and distribute your application in a PAR archive. In that context, PAR::WebStart might be useful although I have not tried it. I have had success with PAR archives in the past, though.
PLDelphi is a Perl project hosted on CPAN. I am currently working on a Delphi application and I am investigating the possibility of adding Perl scripting support and read about PLDelphi.
Ideally, I'd like my application to not require Perl to be installed. PLDelphi claims to support this:
To use PLDelphi from your Delphi
application without need to install
Perl you will need this files in the
main diretory of your application:
PLDelphi.dll - The PLDelphi
library that loads the Perl
interpreter. PLDelphi.pm - Perl
side of PLDelphi. Perl56.dll -
The Perl library in case that you have
Perl built dynamic. PLDelphi_dll.pas -
PLDelphi classes and DLL wrapper.
lib/* - A Perl lib directory with basic .pm files (strict, warnings, etc...)
I am aware of RemObjects PascalScript and embedding Python in Delphi, but in this instance, I am interested primarily in Perl support.
Has anyone used PLDelphi with success? Or have you found other ways to execute Perl scripts from Delphi without the full Perl installation available locally?
EDIT:
To be more clear, I found 1 potential solution and that is using PLDelphi. However, I'd like to know if anyone has used it (last updated in 2004) before, and how well it worked.
I'm also interested in hearing about any other options for embedding a Perl interpreter with Delphi.
You could use Windows Script Host (which comes with VBScript and JScript by default) and install PerlScript from ActiveState.
Sadly PLDelphi isn't updated for XE3 or 64 bits there for won't work with Perl 5.16
I was really looking for a solution that didn't require installing anything on the client. It appears that PLDelphi is not working with ActivePerl 5.10...so I don't believe there is a ready solution to embedding Perl within a Delphi application.
Whenever I work on a system of any flavor that has a particular way of handling package management, I try to stick with that standard for managing my Perl modules. "When in Rome, etc."
For example, on a Win32 system using ActivePerl, I use PPM for everything and use the great PPM::Make. On a RedHat system I prefer to use RPMs.
Now I am working on a Debian system, and find myself in need of a way to turn an arbitrary CPAN or CPAN style distribution into a deb.
Google shows options like dh-make-perl, CPANPLUS::Dist::Deb and CPAN::Packager::Builder::Deb.
Does anyone with experience with these different tools have any recommendations as to what to use or avoid?
What's the best way to handle building deb files from standard CPAN modules?
Update:
I found an article by Hans Dieter Piercy on this subject - he suggests, for his own needs, CPANPLUS tools. Under some circumstances he recommends dh-make-perl. Jeremiah Foster (who wrote the article brian d foy points to) responds to HDP and makes a case for dh-make-perl.
There's also a post on idimmu.net that describes using dh-make-perl.
ATM, I'm leaning toward dh-make-perl, since that has been thrice recommended (brian d foy as proxy for Jeremy Foster, the idimmu.net author and hillu) vs once for CPANPLUS
dh-make-perl does a good job in taking care of the repetitive and heavy lifting and guessing information from the sources. It has worked correctly for almost all of the CPAN modules that I have packaged up as Debian packages (official or for in-house use only).
That said, the resulting package should only be considered as a starting point for a proper Debian packages. dh-make-perl puts warning notes into the automatically generated such as debian/control (i.e. description of the package and dependencies) and debian/copyright (licensing information).
In response to Manni, I believe that it is a great idea to work with the tools that the OS or distribution provides for package management, not against them. In the case of Debian, this means putting stuff into .deb packages and installing those. Perl's build tools and CPAN do a great job of providing a cross-platform build environment and for distribution of the source code, but compared to package management tools in modern Linux distributions, they perform suboptimally, simply because extra manual intervention is often required that is less easily automated across multiple machines than rolling up a package.
(For one-off and test installations, installing into /usr/local/ and using stow(8) as a poor man's package manager may be okay.)
Even if you are just building the packages for your own use, consider contacting the Debian Perl Group and have someone sponsor an upload to Debian if you feel that the module in question is of use for other people.
I suggest you ask the Debian Perl Maintainers group, rather than here on SO. Just mail the address shown as maintainer on any odd package:
Debian Perl Group <pkg-perl-maintainers#lists.alioth.debian.org>
Back in the day, I added a few modules to Debian, and just 'did it by hand'. I still maintain some. That isn't hard either. but the group now maintains way more package, and has tools.
Jeremiah Foster published an article about turning Perl distros into Debian packages in the Spring 2009 issue of The Perl Review.
There is a very good step by step here as well. (also with links to other good resources and some decent comments. [it is dated 2005, but still mostly relavent and many comments much more recent])
http://www.debian-administration.org/articles/78
here is the debian perl policy (also linked to in article)
http://www.debian.org/doc/packaging-manuals/perl-policy/
You won't like this, but I really think that you should not do this at all. The various Perl Debian packages aren't for developers that need certain Perl modules on their machines. They were built because other applications need them and users want or might want those applications.
Please take a look at the answers to this question before doing something that you probably should not be doing.