Pre build 600 compiler

 

I am working on updating a bunch of MQL4 code for someone that was last compiled by its original author with a pre build 600 compiler.

The code involves working with long-term cyclic patterns which means it does lots of manipulations of 32-bit timestamps which it frequently treats as integers when performing date arithmetic or sorting.  As a result it is starting to run into Y2038 issues when working with cycles longer than 17 years (2021.06 + 17 > Y2038 limit).

I have been able to modify much of the code to work with the contemporary MQL4 compiler in #STRICT mode and superficially it all seems to work but I'm concerned that I may have missed some subtleties in the calculations the code performs.  I'd like to be certain that I have not introduced any changes to the way the code works other than fixing the Y2038 issues.

Ideally I'd like to be able to freshly compile the original version after adding some extra debugging code so I can crosscheck the internal state with my new version which uses 64-bit timestamps throughout and is compiled with #STRICT.

Does anyone have an idea of where I might be able to get my hands on a pre build 600 compiler so I can comparison check the two versions?  I may have to run in an XP VM but I assume the compiler would still run.  Certainly the old compiled ex4 files still seem to work fine in compatibility mode in the contemporary MT4 terminal.

Many thanks for any pointers you can provide.

 
After 1 March 2019, MetaTrader 4 desktop terminal builds below 1118 … will no longer be supported.
          Support for older MetaTrader 4 Desktop and Android versions to end on March 1, 2019 - Android Trading Platform - MQL4 programming forum 2019.02.06
 
William Roeder:
After 1 March 2019, MetaTrader 4 desktop terminal builds below 1118 … will no longer be supported.
          Support for older MetaTrader 4 Desktop and Android versions to end on March 1, 2019 - Android Trading Platform - MQL4 programming forum 2019.02.06

Thanks William - yes, I've seen you and others make that point in the past.

I guess I was wondering if anyone had put an old compiler executable aside and might be in a position to share it.

 
LawrenceIpsum: I guess I was wondering if anyone had put an old compiler executable aside and might be in a position to share it.

Unfortunately, I've only got build backups as far back as build 910.

 
LawrenceIpsum: Ideally I'd like to be able to freshly compile the original version after adding some extra debugging code so I can crosscheck the internal state with my new version which uses 64-bit timestamps throughout and is compiled with #STRICT.

Even if you find one, you will not be able to run it.

 
William Roeder:

Even if you find one, you will not be able to run it.

Could you explain that in a little more detail William?  Not disputing, but I'm not understanding what the roadblock would be.  I would have expected to be able to use a 5xx metaeditor.exe to compile a xxx.mq4 to xxx.ex4 on a Windows 10 command line (or an XP command line at a pinch).

I have used the current compiler (metaeditor.exe) on the command line before without issues and had assumed the older version could be used the same way.  I used this as part of a release management system coded in Python that modifies a template mq4 file to include individualized license management code for a bunch of licensees.  So I'd thought I could just generate an ex4 script or indicator using the pre-600 compiler and then run it on a current release of the terminal (in compatibility mode) just as the old .ex4 files do.  I'd just planned to add some diagnostic Print statements so I could confirm that the new code generates the same internal values so don't need the legacy terminal, debug environment or live broker connection.

Anyway, seems like this isn't going to happen easily so I will just have to redouble my desk checks - there's about 10k lines of code so its potentially a pretty major job.

Thanks for your perspective.

 
Fernando Carreiro:

Unfortunately, I've only got build backups as far back as build 910.

Thanks Fernando.

 
LawrenceIpsum: Could you explain that in a little more detail William? 

To run it, you need to connect to a broker. There aren't any. What part of “below 1118 … will no longer be supported” is unclear?

 
William Roeder:

To run it, you need to connect to a broker. There aren't any. What part of “below 1118 … will no longer be supported” is unclear?

No doubt you're a smart guy William (I have benefitted greatly from careful reading of the code you so generously post), but habitually expressing yourself so bluntly just makes you look a little silly.

As I pointed out, the current compiler (metaeditor.exe) works perfectly well on the command line without making a connection to a broker.  I assume (I am willing to be corrected) that a pre-600 compiler works in the same way.  So which "it" needs to connect to a broker to work?  I was not involved in MQL4 coding in the pre-600 days so I don't know if things worked differently back then.

I also pointed out that an ex4 produced by a pre-600 compile works just fine in a current terminal.exe on both online and offline charts - so, again, no need for a broker.

Legacy compiles (almost a decade old) of the code that I am attempting to move up to current MT4 programming conventions work just fine with the current terminal.exe so if an old metaeditor.exe can be found and run  on the command line what step exactly is it that won't work?

The code that I seek to compile with a pre-600 compiler is not intended for release to users - merely as a verification aid whilst I confirm the correctness of my code modernization work to use current MT4 standards for timestamps, global data structures, entry points etc.

Anyway, thanks for your help and my apologies if I have misconstrued your answers but I really don't see what an inability for a pre-1118 terminal.exe to connect to a contemporary broker server has to do with it.

 

So let me just recount my experience briefly for anyone who comes this way in the future.

I will be a little circumspect with the details as it seems from my reading that MetaQuotes may be a little sensitive about this information being shared too explicitly in these forums and I don't want to step on any toes.

Firstly there are a number of places on the internet where old copies of the MT4 compiler may be found - including build 509 which I believe is the last build before things changed significantly in build 600 and beyond.  Seek and you will probably find.

It appears that compiler may be run on legacy .mt4 code either from the command line or by double clicking the metaeditor.exe executable.  The editor will create a folder structure for include files etc that is a little different from the modern standards but you'll work it out.  I put my .mq4 file in the same folder as metaeditor.exe and placed all required includes in the created experts/include folder.  Double clicking the editor/compiler allowed the code to be compiled - I didn't try the command line but I expect it would work.

My code compiled with zero errors (it gets many when compiled with contemporary compilers with #STRICT) and I was able to place it in a contemporary MT4 installation where it appeared to run identically to the existing legacy .ex4 files.  I added some diagnostic Print statements, recompiled, copied and was able to see the diagnostic prints in the Experts log.

I did read in another thread that it was possible to determine the release of the compiler that created an .ex4 by examining bytes 6 and 7 (zero-based) of the ex4 file to determine the compiler version.  In all the legacy .ex4 files I looked at these bytes were 0x00 and 0x00 so this is something that was implemented after build 509.  The same was true of the .ex4 file I created with build 509 of metaeditor.exe.  In all case there was a 2004 copyright notice which was considerably before the date of the compiler itself (around 2013).

I will be able to use this to get a version of the legacy code to output the state of its internal variables which should allow me to ensure that my modernized rewrite will generate identical results for dates (and financial cycles) up to Y2038 and then I can separately ensure that it works correctly for dates beyond that.

Interestingly the .ex4 binary file I created was significantly different from the legacy .ex4 file I was working with so I'm unsure of exactly what build of compiler was used for that but the error free compilation and clean test run make me reasonably sure that my comparison process will be a reasonable way to validate that my modernized code does not have significant regressions.

So it CAN be done with a little persistence.

 
LawrenceIpsum: So let me just recount my experience briefly for anyone who comes this way in the future ... So it CAN be done with a little persistence.
Thank you for posting your findings and your experience with this situation.
Reason: