Igor64.exe not loading XOP? (XOP function name length?)
Igor 8 and XOP Toolkit 8 (& Microsoft Visual Studio 2019 on Windows 10)
XOPs only exports functions (started with XFUNC3), everything is 64 bit.
I have two XOPs and if I debug igor64.exe with Visual Studio 2019 I
can see it load/unload each and then load the one which works but not
the other.
What is it checking to decide it doesn't like the "bad" one?
My best guess is that it doesn't like XOP function names longer than
31 characters. I'm copying the names from a device API with a a short
unique XOP prefix added.
I started with just a few XOP functions with the XOP working and tripped
up on a 50 character function name.
Is this what is happening? Are the XOP function names limited to 31 or
is it something else and I've leaped off into the ozone?
Assuming the 31 character limit is the problem, I've a possible solution.
Since most of these XOP device interface functions are not time critical
I'm thinking of implementing:
. code the C XOP with the full length name
. use a shortened name in the XOP 1100 XOPF resource
(the "register" function would map the resource number to the
address of the full length name C function)
. code an Igor function with the long name which calls the XOP short name
This should be the easiest to document (my document can say "see the
device API document") rather than trying to invent "user" visible names
for the ones which are too long.
This API has something like 480 functions but I expect I will only have
to implement a subset (yet unknown how large a subset). There are at
least 28 "too long" names before adding the unique XOP prefix.
I currently have a python program which given simple function information
like:
# my version info
function string ms_adq_XopVersion()
will generate the following files:
xopgen-parms.h - XOP routine parameter structures
xopgen-reg.h - XOP RegisterFunction
xopgen-rsc.rh - resource defining XOP entry points
So I can modify this to automatically invent shorter names, use
them in generated XOP resource entry points and add generate
the Igor proceedure which maps the long names to the short names.
Any suggeestions or comments?
Yes. I see that I forgot to document this in the help topic "Long Object Names". I have made a note to add it.
I believe the limit is because the name fields in the Macintosh XOPF and XOPC resources are defined as "pstring[31]" (see XOPTypes.r) and changing it would have created backward compatibility issues.
I think that would work.
January 24, 2022 at 03:00 pm - Permalink
We have a tool to generate the boiler plate code for writing XOPs using functions, see https://github.com/byte-physics/XOP-function-stub-generator.
You only have to define the XOP function signatures and the resource files etc. are generated. Works for Windows and Mac.
January 25, 2022 at 04:32 am - Permalink
Thanks for confirming this behavior and the root cause! I ran into a similar issue today and realized I exceeded the long object name limit in my XFUNC. This information will short circuit the debugging considerably.
July 19, 2024 at 09:24 pm - Permalink