CodeGen 5.1.4 Released
July 29, 2016Testing, Testing, 1,2,3
August 29, 2016Targeting an earlier version of the runtime in traditional Synergy
Are your customers on different versions of Synergy? Do you have to use separate development machines to target different Synergy versions? Since version 10.3, the “Target Synergy runtime” option in Visual Studio has been available for Synergy .NET, but now in 10.3.3 there’s a compiler switch, -qrntcompat, for the traditional Synergy compiler that gives you the same functionality, with more versions.
Here’s how it works: Each -qrntcompat value corresponds to a specific version of the Synergy compiler, as shown in the table below.
Targeted version | -qrntcompat switch value |
9.3.1 | 90301 |
9.5.1 | 90501 |
9.5.3 | 90503 |
10.1.1 | 100101 |
10.1.1a | 10010101 |
10.1.1b | 10010102 |
10.1.1c | 10010103 |
10.1.1d | 10010104 |
10.3.1 | 10030100 |
10.3.1a | 10030101 |
10.3.1b | 10030102 |
10.3.1c | 10030103 |
10.3.3 | 10030300 |
10.3.3a | 10030301 |
If you compile with -qrntcompat=10030102, for example, the compiler creates a .dbo file as though the 10.3.1b compiler were used. This allows one development environment to build and target different runtime versions.
Not only does the compiler ensure that the .dbo file has the correct format and contents for the targeted version, it also verifies that features that were not yet available in the targeted version haven’t been used. As a result, if you’re targeting multiple Synergy versions, it’s possible that some of your code may need to be written differently for different Synergy versions. So we added four .DEFINEs (DBLV953, DBLV10, DBLV103, and DBLV1033) that you can use to perform conditional processing on your code (using .IFDEF) based on the targeted version, as shown in the table below. For example, if 10.1.1 is targeted, DBLV953 and DBLV10 are defined, but not DBLV103 or DBLV1033. Thus, you can easily specify which code is to be compiled based on the version you’re targeting.
Targeted version | DBLV953 | DBLV10 | DBLV103 | DBLV1033 |
9.5.1 | – | – | – | – |
9.5.3 | 1 | – | – | – |
10.1.1 through 10.1.1d | 1 | 1 | – | – |
10.3.1 through 10.3.1c | 1 | 1 | 1 | – |
10.3.3 | 1 | 1 | 1 | 1 |
In addition, we added the same -qrntcompat switch to dblink. Since the compiler now adds the version to the object module, this new linker switch makes the linker check each object module to ensure that none of the routines were compiled for a later version. The only caveat is that routines compiled with an earlier version of the compiler aren’t able to let the linker know what version they were compiled for, so a complete recompile of all modules is recommended. Using this switch with the linker ensures that version errors can be caught at link time, rather than at runtime. (Tip: An easy way to incorporate the switch is by using the SYNCMPOPT environment variable, which is also read by the linker. The linker only looks for the -qrntcompat switch; it ignores the rest of the SYNCMPOPT definition.)
Finally, we also added the -platform=type switch to the compiler, where type is either x64 or x86, to enable you to generate a .dbo file for either a 64- or a 32-bit system. Because only the 64-bit compiler can generate .dbo files for 64-bit systems, the x64 type is only allowed on the 64-bit version of the Synergy compiler.
Ta da! Like magic, even if you have customers on different versions of Synergy, the new runtime targeting feature in 10.3.3 has made the need for separate development machines disappear.