Ideas on why this DLL can be used exactly like a MATLAB function?

Hi,

Previously my experience with DLLs in MATALAB was that you must load the DLL library in question with "loadlibrary()", and then you can request use of its functions using "calllib()". Recently I received a new piece of hardware that came with a DLL written in C to pass commands to the device. They gave me a sample m-file for using the DLL, but I was confused since they never make a loadlibrary call, and also they directly call on the DLL just like an m-file function, with the DLL placed in the same directory as the script (i.e. no "calllib()" is made). Below is the first snippet of code, with the DLL in question "CgCall.dll".

 % Variables used for system_command in CgCall()
 INITIALIZE = 1;
 QUERY = 2;
 CONFIGURE = 3;
 DO = 4;

 %There was some more parameter declarations here that I've left out

 %Initialize the CompuGen system
 NumBoards = CgCall(INITIALIZE);

Now this script didn't work before I installed the hardware drivers, but after I did it worked just fine (no surprise). So installing the drivers must have done something that allows this dll "CgCall.dll" to work just like MATLAB function, with no "loadlibrary()" and subsequent "calllib()" requests. Moving the DLL out of the current directory also makes it stop working, so it isn't like the DLL became part of MATLAB's library.

Does anyone have any ideas as to how this is possible? I've contacted the company, but they are very slow at response.

Thanks,

-Greg

EDIT: Also, to be clear, it appears that this CgCall.dll only contains the one CgCall function

Answer 1

[James Tursa]

It is possible that CgCall is itself a mex routine (has a mexFunction interface etc). What version of MATLAB are you running?

[Greg McCracken]

I'm actually not very familiar with the MATLAB MEX files. Essentially (I know there are more details), one just writes a C script and then uses MATLAB's mex() function to make it a usable MATLAB function right?

How would I tell if it's an "mex file"? Would it have a .dll extension, or is there actually a .mex extension?

As I stated in the comments above, the only file "CgCall" can bee linked with is the "CgCall.dll" in my current directory.

My version of MATLAB is somewhat old, 7.7.0 (R2008b), which is 32 bit

[James Tursa]

I guess the short answer to the question "How would I tell if it's a mex file" is to call it just like a regular function and see if it works. Since it does work (and the which command shows that the dll is in fact being called), that means it is a mex file. MATLAB mex files are dll files that MATLAB attaches at run-time. They are compiled (C/C++ or Fortran typically) routines that have a specific interface so MATLAB can link to them dynamically. They used to have the extension ".dll", as your file does, but recent versions of MATLAB use a platform specific extension such as ".mexw32" for Windows 32-bit, etc. For some versions of MATLAB either the ".dll" or ."mexw32" etc platform specific extension can be used and either will work. At some point in the future (or it might have happened already) MATLAB will no longer work with files with a ".dll" extension.

[Greg McCracken]

Ok, I agree, that must be what's going on. It's too bad that it's in this format, my real purpose was to actually use the DLL in Python since my lab computer with the device doesn't have a MATLAB license. I had tried loading it with Python's ctypes module, but it wouldn't recognize it, so this must be why.

Thanks for the help!

[James Tursa]

Well, the dll itself is just a regular dll, so any s/w that can deal with dll's should be able to load it and run any exported functions that are in the dll. The fact that the special interface function mexFunction for MATLAB is exported shouldn't affect your ability to do this. The likely problem in using the dll this way is that other functions that you think are in the dll and want to use may not be exported because during the build it was intended to be just a mex routine, so you wouldn't be able to get at your desired functions directly.

[Greg McCracken]

I actually was able to resolve this issue as well, I was just being an idiot. Upon the driver install there was a "CgDrv.dll" placed into the sys32 directory, which I should have known about since there was a static library of the same name in the install package. The "CgCall.dll" mex routine is probably linked to this dll, which is why it doesn't run pre- driver installation. I should be able to use the functions directly from this dll with ctypes.

Oh well, at least I learned something!

Answer 2

[Image Analyst]

Why can't CgCall() just be an m-file that contains the loadlibrary() call inside of it?

[Greg McCracken]

The directory from which I'm running the script (also the current directory) only contains the "CgCall.dll" (apart from the script). Also, upon removal of the "CgCall.dll" the script no longer works, with the "CgCall" now being "undefined". This indicates to me that there is no outside m-file "CgCall.m" that was created during the driver install (i.e. such a file is not located in a separate directory, linked via search path).

[Greg McCracken]

Also, upon a search for the pathname for "CgCall" using MATLAB's which() function,

which CgCall
C:\Program Files\Gage\CompuGen\Sample\MATLAB\scripts\CgCall.dll

This is the same directory I was running the script from