Principle
After several hundred man*years in the FX domain, there is another approach to orchestrate a smooth and elegant MT4 Terminal co-operation with other processes than to try to push water up the hill or than to pay USD500+ for a kit, that will stop working right upon the next shock once Build 524-> Build 562->Build 586->Build 600->Build 609->Build 624->... moves again
A non-existent toy
Yes, MT4 architecture does not expose it's own interface to allow self to be "disturbed" by an undeterministic obligation to handle external low-level calls via DLL et al.
How to fix it
Nevertheless, it is possible to reverse the architecture and make MT4 Terminal act as a lightweight thin-Client, operating a smart messaging library, trough which the MT4 functions are being exposed for a remote call ( RPC ).
Example
This way a Python
Node may collect MT4 data for numerical processing,
same way a PHP
Node may in parallel handle remote-syslog-s,
same way a C++
Node may integrate another task,
same way another Python
Node may act as a CLI terminal interface with a Custom-specific scripting-syntax language to command MetaTrader-side activities via command-line / stdio
simply -- whatever your application infrastructure needs can be done this way
( One may even improve a poor real-time features of the native MT4 threads to gain a much better soft-real-time predictability and a low-latency massively parallel architecture .. and still be on a safer-side, protected from being torpedoed by any next "new"-MQL4 )
nota bene: just to imagine the invisible threat, the headbang collision in "new"-MQL4.56789
is, besides others, that string
, while being syntax-proposed as string, is not in fact a string
but a struct
and all your previous DLL-related work simply has to be re-worked and wrapped-around to emulate a string-as-struct or a new DLL-interface has to be designed for cases, which return a value in a buffered ArrayOfBYTEs
, which MQL4.56789
side can receive and process, but which it cannot free on it's own and memory leaks.