How to Identify Your EX4 File’s MT4 Build Version and Why It Matters

How to Identify Your EX4 File’s MT4 Build Version and Why It Matters

If you are trying to recover MQ4 source code from an EX4 file, one of the most important technical details to understand is the MetaTrader 4 build version associated with the file.

The build number matters because MetaTrader 4 and the MQL4 development environment have changed substantially over the years. Build 600, released in February 2014, introduced a substantially revised MQL4 language, a new MetaEditor environment, and changes to how MQL4 applications were handled.

Later changes also affected the EX4 executable format. For example, MetaTrader 4 Build 970 introduced an EX4 format change, with EX4 programs compiled by Build 970 or later not running on older terminal builds.

For anyone researching an EX4 to MQ4 decompiler, understanding the build history can therefore help explain why one recovery approach may work on one EX4 but fail on another.

What Is an MT4 Build Version?

An MT4 build is a version number associated with the MetaTrader 4 trading platform and its development environment.

You may see build numbers such as:

• Build 509
• Build 600
• Build 625
• Build 670
• Build 745
• Build 840
• Build 970
• Build 1170
• Build 1380
• Build 1440 and newer

These numbers represent different stages in the development of MetaTrader 4.

The platform has continued receiving updates, including performance, functionality, and security improvements. MetaQuotes announced that from July 1, 2025, the minimum supported MetaTrader 4 desktop version was Build 1440.

However, the build of the MT4 terminal you are currently using is not automatically proof of the build that originally compiled a particular EX4 file.

That distinction is important.

EX4 and the MT4 Build Relationship

The normal MQL4 development process looks like this:

MQ4 Source Code → MetaEditor Compiler → EX4 Executable

MetaTrader’s documentation confirms that an Expert Advisor is written in MQ4 source code and compiled into an EX4 executable.

Therefore, the compiler environment used when the program was built can be relevant when analyzing the resulting EX4.

A simplified example:

MQ4 Source

     ↓

MetaEditor

     ↓

Compiler

     ↓

EX4

     ↓

MetaTrader 4

If the EX4 was produced using an older compiler generation, its characteristics can differ from an EX4 produced using a newer MQL4 compiler.

This is one reason professional EX4 source-code recovery begins with technical assessment rather than assuming every EX4 is identical.

Why Build 600 Is Important

Build 600 represents one of the biggest milestones in MQL4 history.

MetaQuotes released Build 600 on February 3, 2014, with a substantially revised MQL4 language and a new development environment. The update also changed the organization of MQL4 files and introduced the newer data-folder structure.

The update included features such as:

• Revised MQL4 language
• Updated MetaEditor
• Object-oriented programming features
• Classes and structures
• New file organization
• Updated compiler technology
• Changes to application protection

MetaQuotes also stated that older EX4 applications compiled with the old compiler continued to work in the new terminal after the Build 600 update.

For EX4 analysis, this creates an important historical dividing point:

Pre-Build 600 EX4

versus

Post-Build 600 EX4

They should not automatically be treated as technically identical.

Why Build 970 Also Matters

Another important milestone occurred with Build 970.

MetaQuotes documentation states that the EX4 executable format changed in Build 970 to support new MQL4 features. EX4 applications compiled with previous MetaEditor builds remained compatible with newer terminals, while applications compiled with Build 970 and above would not run on older terminal builds.

This is important when researching an old EX4 file because compatibility can depend on both:

• The terminal being used
• The compiler that produced the EX4

Therefore, simply knowing your current MT4 build does not always tell you everything about the EX4 you are analyzing.

How to Check Your Current MT4 Build

The easiest way to identify the build of your current MetaTrader 4 installation is through the platform itself.

Step 1

Open MetaTrader 4.

Step 2

Open the Help menu.

Step 3

Select About.

Step 4

Look for the displayed MetaTrader 4 build number.

You may see information similar to:

MetaTrader 4

Build 14xx

This tells you the build of your current MT4 installation.

Important Difference

Your current terminal build tells you about your current environment.

It does not necessarily prove that the EX4 file you received was compiled with that exact build.

For an EX4 obtained from another computer, developer, broker, or older project, additional analysis may be necessary.

How to Check the Build Used to Compile an EX4

This is more complicated.

If you still have access to the original development environment, the easiest solution may be to identify the MetaTrader 4 installation and MetaEditor version used when the project was compiled.

If you do not have the original development environment, determining the compiler history of an EX4 can require technical file analysis.

This is where professional EX4 decompilation and source-code recovery services can be useful.

A specialist may assess the EX4’s characteristics and compare them with known compiler and executable-format generations.

However, it is important not to assume that every EX4 exposes a simple, reliable text field saying:

“Compiled with Build XXXX.”

Build identification from an EX4 can depend on the file and the available technical evidence.

Does an EX4 File Contain Its Build Number?

EX4 files are compiled executables rather than ordinary text documents.

Some technical analysis methods may identify compiler-related characteristics or metadata, but you should not assume that the build number is always available as a simple readable value.

If someone claims they can identify every EX4’s exact compiler build instantly with absolute certainty, be cautious.

A professional assessment should distinguish between:

• Confirmed information
• Strong technical indicators
• Estimated information
• Unknown information

This is particularly important when the original compilation environment is unavailable.

Why Build Information Matters for EX4 Decompilation

The main reason build information matters is compatibility.

A decompiler or recovery system must understand the compiled program it is analyzing.

If the EX4 comes from a compiler generation that a particular tool does not properly support, the result may be:

• Empty output
• Corrupted source
• Incorrect functions
• Invalid syntax
• Missing logic
• Unusable MQ4
• Compilation errors

That does not necessarily mean the EX4 itself is damaged.

It may simply mean that the recovery method is not appropriate for that particular executable.

Build Version and Source-Code Recovery

Consider two hypothetical EX4 files.

EX4 A

• Older compiler generation
• Simple custom indicator
• No unusual dependencies
• No additional protection

EX4 B

• Newer compiler generation
• Complex Expert Advisor
• External dependencies
• Additional protection
• Large internal structure

The recovery prospects may be completely different.

This is why professional source-code recovery should evaluate the actual file rather than relying on the filename or extension alone.

What Happens When the Wrong Decompiler Is Used?

One common mistake is to download an old EX4 decompiler and assume it should work on every EX4.

A tool may have been designed around a particular generation of MQL4 executables.

When presented with a substantially different executable format, it may produce output that looks like:

Unknown function

Invalid instruction

Corrupted code

Empty result

Unreadable MQ4

In other situations, the tool may produce a source file that technically opens but does not accurately reproduce the original program.

This is why successful file conversion does not automatically mean successful source-code recovery.

EX4 Build Version vs MT4 Terminal Version

These terms are related but should not be confused.

Your current MT4 might be running a recent build while the EX4 you received was created years ago.

Therefore:

Current MT4 Build ≠ Automatically the EX4 Compilation Build

How Build Differences Affect Expert Advisors

Expert Advisors can be particularly sensitive to differences in their development environment.

An EA may use:

• Trading functions
• Classes
• Structures
• Libraries
• External components
• Custom indicators
• Resources
• Advanced MQL4 features

The Build 600 transition introduced major changes to the MQL4 language and development environment, including features that made MQL4 much closer to MQL5 in functionality.

Therefore, knowing the approximate compiler generation can help a specialist understand the architecture they are dealing with.

How Build Differences Affect Custom Indicators

Custom indicators can also be affected by compiler history.

An indicator may contain:

• Multiple buffers
• Custom calculations
• Alerts
• Chart objects
• External indicators
• Libraries
• Resource files

MetaQuotes noted that some older custom indicators could encounter issues when compiled under the newer MQL4 environment, demonstrating that compiler changes can affect how older programs behave.

For an EX4 indicator decompilation project, build analysis can therefore be one part of understanding the file before source-code recovery begins.

Other Factors That Matter Besides Build Version

Build identification is useful, but it is not the only factor.

A professional EX4 assessment should also consider:

File Integrity

Is the EX4 complete and readable?

Program Complexity

Is it a simple indicator or a sophisticated Expert Advisor?

Protection

Does the application use additional protection?

Dependencies

Does it require DLLs, libraries, or other EX4 files?

External Services

Does it interact with websites, APIs, or licensing systems?

Resources

Does it contain embedded resources?

Original Project Files

Are MQH, DLL, EX4 library, preset, or configuration files available?

All of these factors can affect the recovery process.

Can You Determine the Exact Build From the EX4 Filename?

Usually, no.

A filename such as:

MyEA.ex4

does not tell you whether it was compiled with Build 509, Build 600, Build 970, or a newer compiler.

Likewise:

GoldScalper.ex4

does not reveal its compiler history.

The filename identifies the file chosen by the developer, not necessarily the technical environment that produced it.

What About the EX4 File Date?

The file’s creation or modification date can provide context, but it should not be treated as definitive proof of the compiler build.

For example, an EX4 modified in 2020 may have originally been compiled years earlier and simply copied to another computer.

File timestamps can therefore be useful supporting evidence but should not be considered a guaranteed compiler identifier.

Can the Original Developer Confirm the Build?

Yes.

If you still have contact with the original developer, asking which MetaTrader 4/MetaEditor build was used to compile the application may provide valuable information.

You can also ask whether they still have:

• MQ4 source
• MQH includes
• Libraries
• DLLs
• Project files
• Presets
• Original MT4 installation

If the original source exists, recovering it directly is normally preferable to attempting source-code recovery from an EX4.

A Professional EX4 Build Assessment Workflow

For an authorized source-code recovery project, a professional workflow might look like this:

1. Receive the EX4

The service receives the file and relevant project information.

2. Check File Integrity

The EX4 is checked for obvious file problems.

3. Identify Program Type

The specialist determines whether it appears to be an:

• Expert Advisor
• Custom indicator
• Script
• Library

4. Analyze Compiler Characteristics

The file is assessed for characteristics associated with different MQL4 compiler generations.

5. Check Dependencies

The service determines whether supporting files may be required.

6. Assess Protection

Potential protection or licensing complications are considered.

7. Evaluate Recovery Feasibility

The provider determines what level of source recovery appears realistic.

8. Attempt Source Reconstruction

Where technically feasible and legally authorized, source-level information is reconstructed.

9. Compile and Test

Recovered MQ4 source is compiled and tested.

10. Compare Behavior

Where practical, the recovered application can be compared with the original EX4.

Why Professional Assessment Is Better Than Guessing

Suppose you have an EX4 file and assume:

“This is probably Build 600, so an old Build 600 decompiler should work.”

That assumption could waste time.

The actual file might:

• Come from a different compiler generation
• Use additional protection
• Depend on external libraries
• Contain unusual structures
• Be damaged
• Require a different recovery approach

A professional assessment replaces guesswork with evidence-based evaluation.

Can a Modern MT4 Open an Old EX4?

In many cases, newer MT4 terminals can run older EX4 programs.

MetaQuotes stated during the Build 600 transition that previously compiled EX4 applications remained operable in the newer terminal.

However, compatibility in the opposite direction can be different.

MetaQuotes specifically documented that EX4 programs compiled with Build 970 or later would not run on older terminal builds.

This is an important distinction:

Newer terminal → older EX4

can differ from:

Older terminal → newer EX4

Why This Matters When Recovering MQ4 Source Code

If your objective is to recover MQ4 source code, build analysis helps establish the technical context of the EX4.

It can help answer questions such as:

• Is this an older or newer MQL4 executable?
• Which recovery methods may be relevant?
• Are compatibility problems likely?
• Could the file require additional analysis?
• Are dependencies involved?
• Is the file likely to require extensive reconstruction?

It does not guarantee the recovery result, but it can make the assessment much more accurate.

How to Prepare an EX4 File for Professional Recovery

If you own or have authorization to analyze the file, provide as much relevant information as possible.

Useful information can include:

• EX4 file
• Current MT4 build
• Original MT4 build, if known
• Original developer information
• Related EX4 files
• MQH files
• DLL dependencies
• Preset files
• Screenshots
• Description of expected behavior
• Whether the EX4 is an EA or indicator

This gives the recovery specialist more context.

Questions to Ask an EX4 Decompiler Service

Before choosing a provider, ask:

Can you assess my EX4 before starting?

A technical assessment is preferable to an automatic promise.

Can you identify the likely compiler generation?

Ask how the provider determines build information.

Do you work with modern EX4 files?

This can help distinguish current technical capabilities from outdated tools.

Do you analyze dependencies?

Important for complex Expert Advisors and indicators.

Do you test recovered MQ4?

Compilation and functional testing can reveal problems that are not obvious from source inspection.

Do you guarantee 100% recovery?

Be cautious. A responsible provider should explain that recovery depends on the individual file.

What exactly will I receive?

Ask whether the delivery includes source code, cleaned code, supporting files, and documentation.

Frequently Asked Questions

How do I check my MT4 build number?

Open MetaTrader 4, select Help → About, and look for the displayed build number.

Does my current MT4 build tell me the EX4 build?

Not necessarily. Your current terminal build and the compiler used to create an EX4 are separate pieces of information.

Why is Build 600 important?

Build 600 introduced a substantially revised MQL4 language, a new MetaEditor environment, and changes to the organization of MQL4 application files.

Why is Build 970 important?

MetaQuotes documented an EX4 format change in Build 970. Programs compiled with Build 970 and later would not run on older terminal builds.

Can I identify the exact compiler build from an EX4?

Sometimes technical analysis may provide strong indications, but you should not assume that every EX4 exposes a simple and definitive build number.

Does an old EX4 decompiler work on modern EX4 files?

Not necessarily. Different compiler and executable-format generations can require different analysis approaches.

Does build version determine whether an EX4 can be recovered?

No. Build information is only one factor. Protection, complexity, dependencies, file integrity, and other characteristics can also affect recovery.

Can an EX4 Expert Advisor be converted back to MQ4?

Source-code recovery may be possible in some cases, but results vary by file. A professional assessment is preferable to assuming complete recovery.

Can custom indicators be recovered?

They can be assessed for source-code recovery, but the result depends on the specific EX4 and its technical characteristics.

Final Thoughts

Understanding the MT4 build version associated with an EX4 file is an important part of professional EX4 analysis.

MetaTrader 4 has undergone major changes throughout its history. Build 600 introduced a substantially revised MQL4 environment, while Build 970 brought further changes to the EX4 executable format.

For this reason, the build of your current MT4 terminal should not automatically be assumed to be the build that created your EX4.

If you are looking for an EX4 to MQ4 decompiler or professional EX4 source-code recovery service, build analysis can help establish the technical background of your file before recovery begins.

The most reliable approach is to assess the actual EX4, consider its compiler characteristics, complexity, protection, dependencies, and integrity, and then determine what source-level recovery is realistically possible.

Need help analyzing an EX4 file? Submit your authorized EX4 for professional assessment and determine the most appropriate source-code recovery approach.

• Share :