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?

 

Quote:
My best guess is that it doesn't like XOP function names longer than 31 characters

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.

Quote:
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.

I think that would work.