Principle
After several hundred man-years in the FX domain, there is another approach to organizing MT4 Terminal's smooth and elegant collaboration with other processes than trying to push water up the hill or pay USD500 + per set, which will stop working immediately after the next hit, as soon as Build 524-> Build 562-> Build 586-> Build 600-> Build 609-> Build 624 → ... moves again
Toy carrier
Yes, the MT4 architecture does not provide its own interface to allow itself to be “violated” by an undefined obligation to handle external low-level calls through DLLs and others.
How to fix it
However, you can undo the architecture and make MT4 Terminal a lighter thin client working with an intelligent message library through which MT4 functions will be displayed for a remote call (RPC).
Example
This way, Python Node can collect MT4 data for digital processing,
in the same way a PHP Node can handle remote-syslog-s in parallel,
just like C++ Node can integrate another task,
like another Python Node, it can act as a CLI terminal interface with a user-defined scripting syntax language to control MetaTrader actions via the / stdio command line
simple - regardless of the needs of your application infrastructure, you can do it
(You can even improve the poor real-time capabilities of MT4 native streams to get much better real-time predictability and small-sized parallel architecture with low latency .. and still be safer, protected from a torpedo from any next "new" -MQL4)
nota bene: just to present an invisible threat, a headgear collision in the “new” - MQL4.56789 , among others, string , being the syntax suggested as a string, is actually not a string , but a struct , and all your previous ones DLL-related jobs just need to be reprocessed and wrapped -around to emulate a string structure or a new DLL interface should be designed for cases that return a value to the buffered ArrayOfBYTEs that the MQL4.56789 side can receive and process, but which it can't free about n owns and memory leak.