MS Visual Studio C 32 bits mxArray DLLs for the interface to MATLAB 64 bits

Hi All,

Please explaine me why MS Visual Studio C 32 bits mxArray DLLs for the interface from C to MATLAB can't be found in 64 bit MATLAB installation. What is relation of the 32 bit C application and 64 bit MATLAB when these environments are connected by virtual pipe for example or MAT file?

Thanks,

AlexS

[James Tursa]

It is a bit unclear what the question is. 64-bit MATLAB cannot run 32-bit mex routines. Is that what you are asking? 64-bit MATLAB can read MAT files written by 32-bit MATLAB, and vice-versa.

[Alex Sidorov]

Obviously, the quick answer isn't a good answer. 64-bit matlab can use conmmon interface-pipe to other apps which can be 64-bit app or 32-bit app as well. This is interface realization only issue or may be as pointed below OS restriction.

https://nl.mathworks.com/help/matlab/matlab_external/introducing-matlab-engine.html

[Walter Roberson]

The MS Windows search process for libraries checks the "magic numbers" looking for the libraries with the same compiled interface as the calling code. As far as Windows is concerned, if you are running a 64 bit application then the 32 bit libraries are simply misformated irrelevant files that might as well be music or saved Call of Duty games, things that cannot possibly be linked against.

For virtual pipes you have to ask what is being sent through the pipes.

The C and C++ languages can only return a single scalar value (that might be a pointer). In order to return multiple items, the only mechanism is for the calling routine to pass in pointers to the area that is to receive the results. But what size are those pointers and how much memory can they point to? A 32 bit library cannot address more than 4 gigabytes total including its own code and data and any operating system libraries it calls upon. In practice the limit for arrays cannot exceed 3 gigabytes for arrays being passed in 32 bit MS Windows.

Now suppose a 64 bit MATLAB session has its code (about a gigabyte), and a 5 gigabyte array and a 1 gigabytes array after that. Can the pointer to the 1 gigabyte array be passed to the virtual pipeline? No: the 1 gigabyte array lives at least 6 gigabytes into the 64 bit address space, needing at least 33 bits of address, and the 32 bit dll cannot refer to it. (At least not without operating system support for remapping hardware addresses.) And if you do manage to shim it to make the 1 gigabyte space addressable in the 32 bit dll then you know that isn't going to work for the 5 gigabyte chunk.

So... can you write the proposed virtual pipeline in terms of it allocating buffers of restricted size, passing the buffers in to the 32 bit dll, and copying out the results into the 64 bit space? Maybe for some functions that work with pure data (such as an analog to digital board being used to grab new data.) You might be able to do something useful with that, depending on what the dll does. But can it always work?

Consider a dll that takes an array of information and builds a 2/3 tree. Intermediate nodes contain a value, and a left pointer (for input values less than the value in the node), and a right pointer for values greater than the comparison value, and a center pointer for values exactly equal to the comparison value. Terminal nodes contain data that is not the size of the intermediate nodes... maybe variable length like a character vector. The dll creates these nodes of various sizes at need. Now it is time for the virtual pipeline to return the data to the 64 bit function. Can it do so? Well, potentially it can traverse the 32 bit tree and build a 64 bit equivalent in the appropriate part of 64 bit memory. But in order to do so, the virtual pipeline would have to know ahead of time the exact tree representation.

Thus, you might potentially be able to build an interface layer that translated between 32 bit and 64 bit space, for a dll that had well defined functionality, but it is not something that can be done in general.

[Alex Sidorov]

Thanks, I understand restriction that Matlab has... but the one 32-bit pointer of the C can point to structure with double size. I think that the implementation of thr interface should be impruved. According to

https://nl.mathworks.com/help/matlab/matlab_external/introducing-matlab-engine.html

engine should support different platforms. Example: The C code is launched on the 32-bit embedded platform in network and accellerated by remote network server with 64-bit Matlab.

Once again, a lot of thanks for your explanation.

[Walter Roberson]

MS Visual Studio C 32 bits mxArray DLLs for the interface from C to MATLAB can't be found in 64 bit MATLAB installation

Example: The C code is launched on the 32-bit embedded platform in network

32 bit Embedded platforms are not MS Windows .

https://www.mathworks.com/help/matlab/matlab_external/introducing-matlab-engine.html does not offer the possibility of executing on remote machines is you are using COM objects (but does not rule it out.)

The remote access that Mathworks discusses on that page are for Unix systems using pipes. In order to use the facility, the system, the system making the call must have access to the Unix pipe() system call, the unix forkv() system call, and an rsh executable. Embedded platforms do not typically have those facilities (a QNX system just might be able to work something equivalent out.)

[Alex Sidorov]

Thanks :)

Answer 1

[Walter Roberson]

This is an operating system limitation.

The only operating system that I can recall ever having the ability to call to a lower-bit facility, was an early Unix-like operating system that had no hardware memory protection, and wrote data arguments into the first page of memory and then did a processor reset to switch into 16 bit mode.