The not implemented does come from what h2xs generates however you might need to do some massaging of the code before you can actually do something. I have run h2xs on vendor supplied headers and got just my defines and none of the functions. It could be that you are suffering from the same problem!

As well, much of the XS work that I have had to do was not with simply exposing the functions in the API. It was finding a logical way to take the various datastructures that the API uses and making them make sense in the world of Perl.

Looking at your code, my first guess is that the underlying dx_open() is returning -1 and leaving errno set to ENOSYS.

I'll also throw in my lack of respect for T_PTROBJ. In the rare case where you really do want an object to handle your data structure, I feel strongly that you are better off dealing with objects in Perl code rather than putting object manipulation code in XS (where it is hard to get working, hard to debug, hard to maintain, hard to enhance, etc.).

After a very quick scan of your code, it doesn't look like the underlying API is malloc()ing buffers so you won't have to deal with the worst possible problem of XS [getting Perl to deal with data that it didn't malloc()]. So I'd start with the assumption that each struct is going to be filled and used only by the API and so you can treat each as a "black box".

So just pass them around as Perl strings (and pre-extend them to be big enough when appropriate -- either in Perl or in XS). Then when you find a struct that you need to put data into or take data out of (without just using the API to do that), then add functionality for that. Sometimes a simple use of pack() and unpack() is a good idea. But this depends on the struct and what you do with it. Feel free to ask specific questions since I'm being pretty vague. (:

I have found then, that my XS is perfect. Wrapping this function deeper in XS doesn't help - the ENOSYS persists. Funny thing is that compiling a C program with -ldxxx -lsrl -lLiS works, while having these same libraries in the Makefile.PL does not enable these funcs properly, it seems. I wonder, how I can trace this process better to see where the error is coming from, perhaps "what" function exactly is not implemented? It could be other than the actual target routine. Is including those libraries in Makefile.PL enough? Any other tips on finding out what's going on here? I feel rediculous, but it's stumped me and all the XSing around I can think of is not helping me find the cause. I even tried swig, but quickly opted out for the simplicity and nice-ness of XS. Thanks, cb921

Hi :) You have tied many things together and have increased my understanding. I elimenated all the junk in my files, and created a simple one-function XS module, which returned the same results, so none of that stuff seems to be getting in the way at least. If I write a small C program using this function, and including the libraries etc, the return is the device handle as it should be. I don't, then, know how further to debug this problem - I will here admit that one might expect better C from an overripe tomato than from myself, springing from which my need for Perl. How could I check errno from the XS? I understand how to insert code there, just not 'what' code. Regarding passing the struct parameters into functions... I'm less in the dark, but I will concentrate on making the simplest functions usable, and then I will, as you say, add support as necassary. Thank you again, you have been unexpectedly helpful and kind. ceeb