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 have an EX4 file but do not know when or with which MetaTrader 4 compiler it was created, identifying its approximate compiler generation can be useful.

This is especially important when you are dealing with an old Expert Advisor, custom indicator, script, or other MQL4 application and need to investigate compatibility, maintenance, or EX4 to MQ4 source-code recovery.

MetaTrader 4 changed significantly around Build 600, when MetaQuotes introduced a revised MQL4 language, a new MetaEditor/compiler environment, and a new organization for MQL4 files. (MQL5)

However, there is an important distinction:

The MT4 build installed on your computer is not necessarily the build or compiler version that created your EX4 file.

An EX4 can be copied between terminals, so checking your current terminal alone does not establish the compiler generation of the EX4.

This guide explains what you can check, what the results mean, and why the information may matter when working with old or recovered MQL4 source code.

What Is an EX4 File?

An EX4 file is a compiled MetaTrader 4 application.

MQL4 source code is normally stored in files such as:

• .mq4 — source code
• .mqh — include/source files
• .ex4 — compiled MetaTrader 4 application

EX4 files can represent different types of MQL4 applications, including:

• Expert Advisors
• Custom indicators
• Scripts
• Libraries

The compiled EX4 is designed to run inside MetaTrader 4, while MQ4 source code is what developers normally edit and compile.

Why Does the MT4 Build Matter?

The biggest historical dividing point for EX4 files is the transition around Build 600.

MetaQuotes released MT4 Build 600 on February 3, 2014. The update introduced substantial changes to MQL4, including a new compiler and a revised file structure. (MQL5)

Before this transition, MT4 used an older MQL4 development environment.

After Build 600, MQL4 was significantly updated and brought closer to the architecture and features of MQL5.

This matters because an EX4 produced by an older compiler is not necessarily equivalent internally to one produced by a newer compiler.

A Simple Historical Breakdown

Build 600 should therefore be treated as an important historical dividing point when investigating an EX4 file.

Important: Your Current MT4 Build Is Not the EX4’s Build

One of the most common mistakes is opening MetaTrader 4 and checking:

Help → About

and assuming the displayed build number is the build that created the EX4.

It is not necessarily.

For example, suppose you have:

MyRobot.ex4

You install it on a current MT4 terminal showing:

Build 14xx

That only tells you the build of the terminal currently running the file.

It does not automatically prove that MyRobot.ex4 was compiled using that same build.

The EX4 may have been compiled years earlier and subsequently copied to the current terminal.

Method 1: Check the Original Project Information

The easiest method is often not technical at all.

If you still have access to the developer, original project folder, documentation, or an old computer, look for:

• Original MQ4 source
• MetaEditor version
• MT4 installation date
• Project documentation
• Compilation notes
• Old terminal backups
• Old EX4 and MQ4 pairs

If an MQ4 file is available, opening it in the relevant MetaEditor environment may provide more useful information than analyzing the EX4 alone.

Method 2: Check the EX4 File Signature

One commonly discussed method for distinguishing older and newer EX4 generations involves examining the beginning of the binary file.

MQL4 community discussions have noted a difference between older EX4 files and newer files associated with the post-Build-600 environment.

Older EX4 files have historically been associated with an EX4 signature, while newer formats have been observed with a different EX- signature. (MQL5)

This can be useful as a quick diagnostic clue.

However, do not treat a three-character signature as a complete compiler-version identification system.

It can help answer a broad question such as:

“Does this look like a legacy EX4 or a newer-generation EX4?”

It does not necessarily tell you:

“This EX4 was compiled specifically with MT4 Build 742.”

That distinction is important.

Method 3: Inspect EX4 Metadata or Binary Information

Some MQL4 community discussions describe examining specific bytes within an EX4 file to identify compiler-version information. One discussion refers to bytes around positions 7–8 as containing MetaEditor version information. (MQL5)

Other discussions describe examining bytes 6 and 7 in older files. (MQL5)

Because these are community-derived techniques rather than a current official MetaQuotes identification procedure, they should be treated carefully.

Different EX4 generations, tools, and file structures can produce different results.

What Should You Do With Binary Information?

If your goal is source-code recovery or technical assessment, preserve the original EX4 and provide the file to someone who can analyze it properly.

Avoid modifying the original binary while experimenting.

Create a backup first.

Method 4: Look at the File’s Age

The file’s creation or modification date can provide useful context.

For example:

TradingRobot.ex4

Modified: 2013

is obviously more likely to belong to the pre-Build-600 era than:

TradingRobot.ex4

Modified: 2025

But file timestamps are not proof.

Files can be:

• Copied
• Downloaded
• Extracted from backups
• Renamed
• Moved between computers
• Recompiled and redistributed

Therefore, timestamps should be treated as supporting evidence rather than definitive compiler information.

Method 5: Check Where the EX4 Came From

The source of the file can provide additional clues.

Ask:

• When did you purchase the EA?
• When did the developer send it?
• Was it downloaded from an old website?
• Was it included in an old MT4 installation?
• Was it compiled specifically for your broker?
• Did the developer mention the MT4 version?
• Do you have an older terminal backup?

For example, an EA purchased in 2012 is much more likely to be associated with the legacy MQL4 era than an EA first distributed in 2025.

Again, this is evidence—not definitive proof.

Legacy EX4 vs Modern EX4

A practical way to organize your investigation is to separate files into two broad categories.

Legacy EX4

A legacy EX4 generally refers to applications associated with the older MQL4 compiler generation before the major Build 600 transition.

These files can be especially interesting when investigating old MT4 projects because the compilation environment was substantially different.

Post-Build-600 EX4

Build 600 introduced major changes to MQL4 and its development environment. MetaQuotes also described changes to the protection of compiled MQL4 applications. (MQL5)

This means that simply finding an EX4 file does not tell you that the original MQ4 can be recreated exactly.

The compiler generation is one part of the technical assessment.

Why Build Identification Matters for EX4 to MQ4 Recovery

If you are investigating an EX4 to MQ4 decompiler or source-code recovery service, knowing the approximate EX4 generation can provide useful context.

1. It Helps Establish the File’s History

Knowing whether a file belongs to the legacy or newer compiler generation can help explain why its internal structure and behavior may differ from other EX4 files.

2. It Helps With Compatibility Research

Older MQL4 applications may have been developed around different directory structures, language features, and compiler behavior.

MetaQuotes documented that the Build 600 transition changed the MQL4 directory structure and compiler environment. (MQL5)

3. It Helps Set Realistic Expectations

A source-recovery project should begin with an assessment of the actual file.

Compiler generation is one of the pieces of information that can help determine what kind of technical work may be required.

4. It Helps With Testing

If recovered or reconstructed source code is produced, it should be compiled and tested in the intended MT4 environment.

This is particularly important when maintaining older trading applications.

Does Build 600 Automatically Mean an EX4 Cannot Be Recovered?

You should not reduce the situation to a simple yes or no.

Build 600 introduced major changes to the MQL4 compiler and protection model, but the existence of a particular build does not by itself determine the outcome of every individual EX4 analysis.

There are also conflicting claims in online discussions about what is technically possible with modern EX4 files. For example, some MQL5 forum moderators have stated that there has been no proof of successful decompilation of post-Build-600 EX4/EX5 files, while other forum participants have reported contrary experiences. These are community claims rather than definitive technical documentation. (MQL5)

For that reason, a file-specific assessment is more useful than assuming that every EX4 falls into one universal category.

How to Check Your MT4 Terminal Build

If you want to know your current MT4 terminal build, open MetaTrader 4 and select:

Help → About

You will normally see information about the installed terminal, including its build number.

Remember:

Current terminal build ≠ necessarily EX4 compiler build.

This distinction is one of the most important points in EX4 source-code recovery research.

What Information Should You Give a Recovery Specialist?

If you are requesting an EX4 technical assessment, provide as much legitimate project information as possible.

Recommended information

• EX4 filename
• File size
• Approximate file creation date
• Current MT4 terminal build
• Approximate date the EX4 was obtained
• Whether it is an EA, indicator, script, or library
• Any related EX4 files
• Any MQH files you legitimately possess
• DLL dependencies, if applicable
• Original developer information
• Expected behavior of the application

You should also explain what you actually need.

For example:

“I need maintainable source code for an old Expert Advisor.”

is more useful than simply saying:

“Convert EX4 to MQ4.”

The desired outcome affects how the project should be evaluated.

EX4 File Assessment Checklist

Before submitting an EX4 for analysis, use this checklist.

File identification

• ☐ Confirm the file extension is .ex4
• ☐ Record the file size
• ☐ Preserve the original file
• ☐ Record the file timestamp
• ☐ Identify whether it is an EA, indicator, script, or library

MT4 information

• ☐ Check your current MT4 build
• ☐ Determine approximately when the EX4 was created
• ☐ Look for old MetaEditor or MT4 backups
• ☐ Determine whether the file is likely legacy or post-Build-600

Project information

• ☐ Find any original MQ4 files
• ☐ Find MQH include files
• ☐ Find DLLs or external dependencies
• ☐ Find configuration or preset files
• ☐ Document expected behavior

Recovery preparation

• ☐ Keep an untouched backup
• ☐ Do not edit the original binary
• ☐ Confirm that you have authorization to analyze the file
• ☐ Define what you expect to receive
• ☐ Plan compilation and testing after recovery

Why You Should Preserve the Original EX4

If you are considering source-code recovery, the original file is valuable.

Do not repeatedly modify, rename, or overwrite it.

Keep at least one untouched copy.

A useful structure might be:

EX4 Project/

├── Original/

│   └── MyRobot.ex4

├── Related Files/

│   ├── Library.ex4

│   ├── Support.dll

│   └── Settings.set

└── Recovered/

    └── MyRobot.mq4

The exact structure is not important. The principle is.

Keep the original separate from experimental or recovered files.

What If You Cannot Identify the Build?

That is not necessarily a problem.

You do not need to know the exact compiler build before asking for an assessment.

Instead, provide:

1. The original EX4.
2. Its approximate age.
3. The MT4 terminal where it currently runs, if applicable.
4. Any related project files.
5. Information about where the EX4 came from.

A technical assessment can then investigate the file itself.

Frequently Asked Questions

How do I know what MT4 build created my EX4?

There is no simple official user-interface field in MT4 that tells you the compiler build of an arbitrary EX4. Community techniques examine file signatures or binary metadata, but these should be treated as diagnostic clues rather than guaranteed identification methods. (MQL5)

Can I check the EX4 build from MetaTrader 4?

You can check your current terminal build through the MT4 interface, but that does not necessarily identify the build that compiled the EX4.

What is the importance of Build 600?

Build 600 marked a major change in MQL4, including a revised language, compiler environment, and file structure. (MQL5)

Are Build 509 EX4 files different from Build 600+ files?

They belong to different compiler generations. Community discussions also identify differences in their file signatures. (MQL5)

Does an old EX4 guarantee easier source recovery?

No. File age and compiler generation are only factors. They do not guarantee a particular recovery result.

Can an EX4 be converted directly into the original MQ4?

Not in the ordinary sense of a file-format conversion. EX4 is compiled code, while MQ4 is source code. Any recovery or reconstruction process should be evaluated based on the individual file and the desired result.

Should I modify the EX4 before sending it for assessment?

No. Preserve an untouched original and work from a copy if technical analysis is required.

Final Thoughts

Identifying the approximate MT4/MetaEditor generation associated with an EX4 file can be useful when investigating compatibility, maintenance, or source-code recovery.

The most important historical milestone is Build 600, which introduced substantial changes to MQL4 and its compiler environment in 2014. (MQL5)

But determining the exact compiler version from an EX4 is more complicated than simply checking the build number shown by your current MT4 terminal.

Use multiple clues:

• File age
• File origin
• EX4 signature
• Available metadata
• Historical MT4 installation
• Related source files
• Current terminal compatibility

Most importantly, keep the original EX4 unchanged.

If your ultimate goal is EX4 to MQ4 source-code recovery, the build information should be treated as part of a broader technical assessment rather than as a guarantee of what can or cannot be recovered.

• Share :