Mosel does not see a DSO module provided by a C++ application - could Windows security be the problem?

Please make sure that the path to the module is correct (i.e. by setting the environment variable MOSEL_DSO) and also that the file effectively exists in this location: some security systems might quarantine "suspicious" files by moving them to some predefined location. Also, does this module depend on any other external libraries, if yes, are these accessible?

Dear Susanne,

I do not think your answer applies to our case, as we do not have a physical .dso file. As I tried to describe in my question, we have a Mosel model that we use from a C++ application using `XPRMrunmod()`.

The model uses a module called 'gassopt' that is provided in-memory by the C++ application (so no .dso file exists), which allows the C++ application to receive callbacks from Mosel...

In this case, I think, it is unlikely that the issue is caused by the security system (I assume that the program would not start at all if it was blocked).

Since the program works on other platforms, have you checked the environment: version of the system+patches, version of the C/C++-library? Are all systems running the same version of Xpress?

Do you check whether the registration of the static dso is successful (i.e. the return value of XPRMregstatdso, and does your implementation make sure that the initialisation function of the module is called and does not return an error status)? In particular the value returned by 'XPRMregstatdso' (if non-zero) can be helpful to analyse what is happening.

Dear Susanne,

thank you for your suggestions.

I believe that the customer may be running a version of the code that did not check return value of `XPRMregstatdso`, so I sent them an updated version and asked them to test it. (By the way, you write that the return value can be helpful for analysis, but the documentation states that XPRMregstatdso() returns 1 on fail - is the documentation wrong?)

I am also worried about Xpress versions, since they often run an older version of Xpress (I do not know why), but I have check the code on my machine and it works even with Xpress 8.6.

Moreover, they have an old version of the same application and that works - I do no understand why: the new version is a major revision, but it changed mainly database handling...

By the way, this is the sequence of calls in the code:

XPRMinit() // stops if not 0
XPRMregstatdso("gassopt", gassopt_init) // stops if not 0
XPRMsetdefstream(NULL, XPRM_F_WRITE+XPRM_F_LINBUF, outfile) // warns if > 0
XPRMsetdefstream(NULL, XPRM_F_ERROR+XPRM_F_LINBUF, outfile) // warns if > 0
XPRMcompmod("g", mosname, bimname, "GassOptTKL compiled") // stops if not 0
model = XPRMloadmod(bimname, NULL);

where `gassopt_init() is defined as`

int CVisBeregning::gassopt_init(XPRMnifct nifct, int *interver, int *libver, XPRMdsointer **interf)
{
	mm = nifct;
	*interver = XPRM_NIVERS;         /* The interface version we are using */
	*libver = XPRM_MKVER(0, 1, 0);   /* The version of the module: 0.1.0 */
	*interf = &dsointer;             /* Our interface */
	return 0;
}

Do you see anything suspicious or missing there?

There does not seem to be anything unusual in your code extracts.

Do you define XPRM_NICOMPAT before includuding xprm_ni.h? This defines the version of the API your module is using (and this could prevent loading of the module with an older release).

To be compatible with Mosel 5.0 (Xpress 8.6) this looks as follows:

#define XPRM_NICOMPAT 5000000 
#include "xprm_ni.h"

You are right, the documentation of 'XPRMregstatdso' is indeed incomplete - this will be fixed in next release. Possible values are:

0 Registration is successful

1 The module was already registered as a static module

2 Module initialisation function failed

3 Module not compatible with the running version of Mosel

4 Loaded library is not a Mosel module

> I am also worried about Xpress versions, since they often run an older version of Xpress

Ascending compatibility is always guaranteed (i.e. something built for 8.6 will work on 8.14) - this is not the case in the other direction. It would be safer for your customers to upgrade to something newer (or for you to build with 8.6).

Once more thanks for the answers.

I have updated the return-value checking of XPRMregstatdso() accordingly.

I have also found that we are actually setting `MM_NICOMPAT` to 4007000 for 32-bit builds.

This corresponds to version 8.3 or 8.4, but the user has reported the problem also with 32-bit Xpress 8.6, which would seem to exclude the compatibility issue as the source of the problem. (Though I cannot be sure that they are running the versions they say they use - I have therefore added reporting of XPRMgetversion() and XPRMgetversions(2) to the latest build...)

By the way, should I be using XPRM_NICOMPAT instead of MM_NICOMPAT? As far as I can see, XPRM_NICOMPAT is used only in one place and that is to defined MM_NICOMPAT if it is not defined (in xprm_ni.h)

The marco XPRM_NICOMPAT is renamed internally to MM_NICOMPAT (see xprm_ni.h), so you can work with either one, but not both together.