in reply to Developing Perl against proprietary interfaces

It seems like the way most people deal with this is to ship a compiled binary that interfaces with the secret code and a larger open-source library that talks to the binary blob. In your case the binary blob would probably be compiled C code that you interface with via XS or Inline::C. The goal should be to keep the C code as light as you can without exposing the secrets of the memory format.

The alternative is to not sign the NDA and build the interface by reverse-engineering. You could load up the existing Windows implementations and watch what they do with a debugger. Then you can release your code under whatever license you want. (After you talk to a lawyer, of course.)

-sam

  • Comment on Re: Developing Perl against proprietary interfaces

Replies are listed 'Best First'.
Re^2: Developing Perl against proprietary interfaces
by wade (Pilgrim) on Apr 22, 2008 at 17:34 UTC
    Instead of linking your C with Perl using raw XS, you might consider http://www.swig.org/. It builds the XS for you and, if you so choose, you can convert directly to Java. I've used SWIG before and it's really easy.
    --
    Wade
[reply]
      You might, but I wouldn't. I've also used SWIG and I found it to be mostly a waste of time. It offers something I don't need (bindings for multiple languages) in exchange for greatly increased complexity. That complexity hides the actual details of the XS interface that you'll need to effectively debug your code. And you will need to debug your code!

      -sam

[reply]

        My approach (which, admittedly, won't work for everybody) was to debug the two sides, separately. I got the Perl working with the C calls stubbed-out and I got the C working with a test harness on that side. At that point, I plugged the bad boys together and it worked like a charm.

        Of course, YMMV.

        --
        Wade
[reply]

In Section Seekers of Perl Wisdom