Repository navigation
Home
When we have complex projects in which we must share information, we have several tools and/or interconnection technologies (Interprocess Comunication - IPC), this work offers an alternative to use Shared Memories to have access to a space with reading and writing features available to processes, threads and programs.
What you have is a shared memory manager that manages the desired memory spaces and the type of data desired, then in the same library functions are offered to access these memory spaces to be able to store or read the data.
This project was born from the idea of having an exchange of information as quickly as possible and with the greatest simplicity. To achieve an exchange of data at the highest possible speed, this proposal does not offer a queue or storage of data to be consumed, but the most current value is stored and the previous one is eliminated, thus making it available to other customers only the most current data. Simplicity is achieved by having a library with the necessary functions to access the memories and work with them, ensuring that the data exchange is achieved with few lines of code.
Dynamic link libraries can be compiled for both 32bits and 64bits, they also have different Calling Conventions.
When compiling libraries for 32bit windows operating system we have several options, the tests were carried out with the following calling convention, more information here.
- stdcall
- fastcall
- cdecl
In 64-bit windows operating systems the problem has already been addressed and has already been standardized so we have greater compatibility and we do not have the compatibility problem depending on the calling conventions, more information here.
- Application Binary Interface (ABI)
The library was compiled in the above-mentioned calling conventions and tested in the following programming languages, giving the following table of results.
| Architecture | Calling Convention | Programming Languages | |||||
|---|---|---|---|---|---|---|---|
| C | C++ | C# | Java | Python | Visual Basic | ||
| 32Bits |
stdcall |
+ | + | + | - | + | + |
| fastcall | + | + | - | - | - | - | |
| cdecl |
+ | + | + | - | + | + | |
| 64Bits | ABI | + | + | + | - | + | + |
| + Supported - Not Supported |
|||||||
| Java has a separate DLL to be used | |||||||
Also this initiative to be part of a research project that works with mathematical models and augmented reality, has been tested in the following applications giving the following compatibility chart.
| Architecture | Calling Convention | Applications | ||
|---|---|---|---|---|
| Matlab | Unity3D | Excel | ||
| 32Bits | stdcall | Not Tested | Not Tested | + |
| fastcall | Not Tested | Not Tested |
- | |
| cdecl | Not Tested | Not Tested | - | |
| 64Btis | ABI | + | + | + |
| + Supported - Not Supported | ||||
-
As a result we see that in 32-bit windows operating systems the calling convention with greater compatibility is __stdcall (Since excel in its 32bits version only supports this calling convention). The calling convention with lower compatibility is __fastcall
-
In the same way in 64bit systems we can observe a complete compatibility.
-
Libraries to be used in projects in programming language JAVA has its own method of library generation that works completely for both 32 bits and 64Bits.
Although __stdcall is the one with the greatest compatibility (by a little), in the library generation decorators are added in the call to the functions creating modified names towards the functions, so (Unless strictly necessary) the use of calling convention __cdecl is recommended, which retains the name of the functions.
All examples such as client library and the Administration Panel have code documentation in case you want to check the code or adapt it to your needs.