What Decompiled MQ4 Source Code Actually Looks Like: Setting Realistic Expectations

What Decompiled MQ4 Source Code Actually Looks Like: Setting Realistic Expectations

Table of Contents

• What Decompilation Recovers
• What Cannot Be Recovered
• Variable Names: The Biggest Expectation Gap
• Code Structure and Readability
• Compilation Readiness
• Free Tool Output vs Professional Output
• First Steps After Receiving Decompiled Output

The most common source of disappointment after decompiling an EX4 file is not a failure of the decompilation process — it is a mismatch between what the person expected and what decompilation can actually deliver. Setting accurate expectations before you receive the output makes a significant difference in how useful you find it. This guide explains exactly what professionally decompiled MQ4 source code looks like and how to work with it effectively.

What Decompilation Recovers

Decompilation reconstructs the MQ4 source code from the compiled EX4 binary. The binary retains the complete logic of the program — every condition, calculation, and function call — encoded in bytecode. A successful decompilation translates this bytecode back into human-readable MQL4. What you receive is a file that:

• Compiles in MetaEditor without errors (for professional-grade output)
• Contains all the trading logic: entry conditions, exit conditions, stop loss and take profit calculations, lot sizing, and order management
• Includes all indicator calculations used by the EA, whether built-in MQL4 functions or custom indicator logic embedded in the file
• Reconstructs all control structures: if/else conditions, loops, switch statements, and function call chains
• Includes the complete parameter list, including inputs visible to traders as inputs in MT4 and hidden internal parameters
• Contains function definitions matching the originals, with correct argument types and return types

In short, everything that makes the EA work as a trading program is present in the decompiled output. The recoverable content is the functional substance of the program — the logic that determines when and how it trades. An experienced MQL4 developer receiving professionally decompiled output can read it, understand the strategy, modify it, debug it, or port it to another platform without needing the original source file as a reference.

The covers in detail how professional services use binary pattern analysis, control flow reconstruction, and AI-assisted naming to extract this content at the highest possible quality level.

What Cannot Be Recovered

Understanding what decompilation cannot recover is as important as understanding what it can. Several categories of information are permanently discarded during compilation and are not present in the EX4 file for any tool to recover:

Comments

Source code comments — every // line comment and /* block comment */ in the original MQ4 file — are stripped completely by the MQL4 compiler. They are not included in the EX4 binary in any form. No decompilation technique, regardless of sophistication, can recover comments because there is nothing in the binary that represents them. The decompiled output will have no comments unless the decompilation service has added auto-generated comments as part of their reconstruction process.

Original variable and function names (in most build versions)

In MT4 builds below 600, many variable and function names were stored as strings in the compiled binary, making name recovery possible for much of the code. In build 600+ files, which represent the overwhelming majority of current EX4 files, variable and function names were removed from the binary. The decompiled output uses reconstructed names — either generated names like var1, dbl_0, func_23, or names inferred by AI analysis from the context of how the variable is used. Neither of these is the original name.

The input parameter names that traders see in the MT4 Inputs tab when attaching an EA are a partial exception. These names are often stored as strings in the binary for display purposes and can frequently be recovered accurately. But internal variable names within the code's logic are not recoverable in most modern-build files.

Code formatting and style preferences

The original developer's spacing preferences, indentation style, line break conventions, and organizational choices within functions are not encoded in the binary. The decompiled output will be formatted according to the decompilation tool's standard output format, which may differ significantly from how the original developer arranged the code.

Variable Names: The Biggest Expectation Gap

The single most common source of disappointment with decompiled MQ4 output is variable names. People who expect to open the decompiled file and read code that looks exactly like the original — with meaningful variable names like entryRSILevel, stopLossPips, and lotSizingMode — are usually working with a modern-build file where those names are not present in the binary.

What they find instead is code with names like iVar_47, dbl_12, bool_3, or AI-inferred names like stopLossDistance and periodLength. The AI-inferred names are better than purely generated names — they reflect the variable's apparent purpose based on how it is used in the code — but they are educated guesses, not the originals.

This is not a failure of the decompilation. The original names are not in the file. The decompiled output is as close to the original as the binary permits. An experienced MQL4 developer working with the output will rename variables as they understand the code's logic, which is typically a straightforward process once the overall strategy is understood.

Professional services provide better name recovery than free tools for two reasons: their AI naming systems are more sophisticated and context-aware, and their human review step corrects cases where AI inference produces misleading names. But neither produces perfect original-name recovery for modern-build files, and this is inherent to the format — not a quality difference between services.

Code Structure and Readability

Beyond variable names, professional decompilation produces output with a structure that closely parallels what a developer would write. The major structural elements of properly decompiled output:

Function organization

The decompiled file will contain the same functions as the original, organized in the same general arrangement. The three main MQL4 EA lifecycle functions — OnInit(), OnDeinit(), and OnTick() (or the older init(), deinit(), and start()) — will be present and contain the logic that was originally in those functions. Custom helper functions will appear as separate named functions with the appropriate argument signatures.

Control flow accuracy

The if/else chains, loops, and conditional logic in the decompiled output should mirror the original's logical behavior exactly. Control flow is the aspect of the program that is most accurately reconstructed because it is directly encoded in the bytecode instruction sequence. A well-decompiled file will show the same branching logic as the original, even if the variable names inside the conditions are generic.

API call accuracy

Built-in MQL4 function calls — OrderSend(), iRSI(), AccountBalance(), and similar — are generally recoverable with high accuracy. These functions have specific opcodes in the bytecode, and a maintained decompiler maps them correctly. The arguments to these calls are reconstructed from the bytecode, including their types and order. This means the complete list of indicators used by the EA, and how they are parameterized, is typically recoverable even from modern-build files.

Compilation Readiness

One of the most meaningful quality indicators for decompiled MQ4 output is whether it compiles in MetaEditor without errors. Professional services verify compilation before delivery — this is a standard step in their quality process. Free tool output frequently does not compile without manual intervention, and the errors can range from minor syntax issues to fundamental structural problems.

A file that compiles cleanly in MetaEditor is immediately usable. You can load it onto a chart and run a backtest to verify behavioral equivalence with the original EX4. A file that does not compile requires manual debugging before you can do anything with it, which is time-consuming and requires MQL4 knowledge to do correctly.

The compilation readiness difference between professional output and free tool output is one of the most practically significant quality gaps. For anyone without deep MQL4 debugging experience, a file that compiles on arrival is not just more convenient — it may be the difference between the recovered code being usable at all.

When evaluating decompilation services, asking specifically whether they test compilation before delivery is a useful filter. Services that verify compilation before sending the file have a process that catches errors before they become the customer's problem. Services that do not are, in effect, outsourcing the quality verification step to the customer.

Free Tool Output vs Professional Output: A Practical Comparison

For a post-600 file, the comparison between free tool output and professional output is stark enough that it goes beyond quality differences into a different category of result entirely:

Free tool output on a modern-build file typically contains: incorrectly parsed opcodes producing meaningless variable assignments, wrong argument types on function calls, structural errors that make the file impossible to compile, garbled control flow that produces loops and conditions referencing undefined identifiers, and random-looking numeric literals where meaningful calculations should be. This output cannot be made useful through editing — the fundamental parsing errors require starting over with a capable tool.

Professional output on the same file contains: correct logic, properly typed variables, accurate API calls, working control flow, AI-inferred variable names that are imperfect but meaningful, and a file that compiles without errors in MetaEditor. A developer can open it, read the strategy, and make modifications. The starting point is correct and complete — the variable names just require renaming as the developer works through the code.

The difference is not about polish or formatting preferences. It is a binary distinction between output that represents the original program correctly and output that does not. For ex4decompiler.com rk on modern-build files, only professional services with maintained tooling produce output in the first category.

First Steps After Receiving Decompiled Output

When you receive professionally decompiled MQ4 from a service like ForexMQ5, the practical workflow for getting the most value from the output:

Step 1: Compile and run a baseline backtest

The first thing to do is load the decompiled MQ4 into MetaEditor, compile it, and run a backtest on the same currency pair and date range you use for the original EX4. Compare the results. Trade counts, entry and exit prices, and P&L should be essentially identical. Any significant discrepancy indicates a reconstruction error that should be raised with the service.

Step 2: Map the parameter list

The input parameters are typically among the best-recovered elements of a decompiled file because they are often stored as visible strings. Go through the input section and verify that the parameters you know from the MT4 Inputs tab are present with recognizable names. This gives you an anchor point for reading the rest of the code — the parameters tell you what the EA exposes for configuration, and tracing how those parameters are used reveals the core logic.

Step 3: Identify the indicator dependencies

Locate all indicator function calls (iRSI, iMACD, iMA, iBands, custom indicator calls via iCustom, etc.) and make a list of what the EA uses. This gives you the strategy's technical foundation and is usually readable immediately from the decompiled code regardless of how the variables are named.

Step 4: Read the entry and exit logic

The OnTick() function (or start() in older EAs) contains the core decision logic. Read through it to understand the conditions that trigger orders and the conditions that close them. With generic variable names, this requires some interpretation, but the logic flow is usually clear from the structure. Renaming variables as you understand their purpose is the most effective way to progressively make the code more readable.

Step 5: Rename variables systematically

As you understand what each variable represents, rename it to something meaningful. Modern code editors with find-and-replace can do this efficiently. Working through the code systematically — starting with the most-used variables in the entry/exit logic — produces a progressively more readable file without requiring complete understanding before you can make progress.

The companion article alks through this process in more depth, including how to handle the specific patterns that decompiled code commonly produces and how to verify that your understanding of the code matches what it actually does.

Frequently Asked Questions About Decompiled MQ4 Output

How long does it take to understand decompiled code well enough to modify it?

For an experienced MQL4 developer, reading a professionally decompiled file and understanding the strategy typically takes an hour or two for a typical EA of average complexity. Making targeted modifications — changing a parameter, fixing a bug, adding a feature — can be done in the same session once the logic is mapped. For someone newer to MQL4, the learning curve is steeper, but the decompiled output from a professional service is still the correct starting point because it is structurally sound and compilable.

Can I tell who originally wrote the EA from the decompiled output?

Usually not reliably. The decompiled output does not retain authorship information. Coding style patterns can sometimes suggest familiarity with specific development approaches, and comments would have been useful for this purpose — but comments are not recoverable. If the EA used a recognized coding framework or contained embedded strings identifying the developer, those strings may survive in the output, but this is not a reliable identification method.

What if the decompiled output looks completely different from what I expected?

The most common reason for a significant mismatch between expectations and output is that the original EA was more complex or had different architecture than assumed. If the output is compilable and passes a backtesting equivalence check, it is correct even if it looks different from what you imagined. A professional service will investigate equivalence check failures as potential reconstruction errors that need to be addressed before delivery.

Is it possible to decompile an obfuscated or protected EX4 file?

Yes, with caveats. Some EX4 files have additional protection layers beyond standard compilation — control flow obfuscation, string encryption, or junk instruction insertion. Professional services have techniques for handling these cases. The output may require more cleanup than a standard file, and some heavily protected files may yield only partial recovery. The service should communicate clearly what protection level your specific file has and what that means for expected output quality.

• Share :