We are pleased to announce a new Synergy/DE feature release, version 12.0.1.3275, which contains a complete implementation of all new features, changes, and improvements that will soon be released as Synergy/DE 12.1 LTS. This will be the final feature release in the 12.0 series, and we strongly encourage you to take advantage of the opportunity to test your applications with the new version prior to the upcoming LTS release.

Feature releases are similar to previous Synergex releases, i.e., they contain features and fixes, they go through our extensive and rigorous testing procedures, and they’re suitable for use in all situations. LTS releases are a new type of release to which we will only add quality and security improvements and no new features. For more general information about these types of releases, see our Release Strategy page.

Synergy .NET Support for .NET 6

As announced almost two years ago, the primary focus of Synergy 12 is to add support for .NET 6 (formerly known as .NET Core) as an alternative to .NET Framework in all the places where Synergy and .NET meet, including:

• Building and deploying Synergy .NET applications with .NET 6
• Using the .NET Assembly API to embed and execute .NET 6 code from traditional Synergy
• The introduction of a new xfNetLink .NET client built with .NET Standard 2.0, and including a new object pooling mechanism (COM+ is not available in .NET 6)
• Making all of the ancillary libraries (XML API, SQL Connection API, Repository API, etc.) available as NuGet packages

One thing that is not possible with Synergy .NET in .NET 6 is creating Windows desktop applications (Windows Forms and WPF). This is because Microsoft has decided to prevent third-party Visual Studio integrators from accessing the visual design surfaces for those environments.

As is always the case, we want all Synergy developers to test their applications with this release, but in particular, we are encouraging developers who use Synergy .NET with .NET Framework to try out their code in a .NET 6 environment as soon as possible; we are eager to receive your feedback on your experiences in that specific area.

Linux License Forwarding

Another feature in Synergy 12 is the ability to use TCP/IP licensing for Linux systems when subscription licenses are used. On new systems where licensing has not been configured, a new question during the installation provides the option to enter the name of a Windows license server, and when you do so, the Linux system will connect to that server for access to product keys.

When using a network license server, a local license server (synd) process is still present, but rather than maintaining a local license database file, it communicates with the license server to allocate licenses. Linux systems configured for network licensing access the same product keys that Windows clients use, so for this configuration, you will order Windows licenses for a new Linux system.

There are several advantages to using network-based licensing on Linux systems. It simplifies license management and enables shared concurrent-use licensing across multiple Windows and/or Linux systems and/or VMs. It is also an excellent solution for developers, who can now use the license server on their development systems to operate any number of Linux and/or Windows systems and/or VMs, without having to license each system individually.

And finally, this enhancement also removes a significant block that previously prevented Synergy applications from running in containers. For example, it is now possible to deploy Synergy applications in Docker containers and managed by a Kubernetes cluster. This opens up many new possibilities for Synergy applications, including the ability to deploy Synergy applications in the Public Cloud.

Encryption Enhancements

Another area of change in Synergy 12 is that on Windows, we no longer use OpenSSL but instead use the Microsoft Secure Channel APIs that are part of the Windows operating system. As a result, you no longer have to download and deploy OpenSSL and no longer need to create and provide “CA Files” to use the HTTP API securely.

Related to this, but affecting all platforms except for OpenVMS, we now validate certificates for authenticity, revocation, and expiration whenever they are used to establish secure connections. In most scenarios, this did not previously happen.

IMPORTANT: THIS CHANGE COULD BREAK YOUR ENVIRONMENT!

When enabling encryption for xfServer or xfServerPlus, or when enabling encryption on private Web servers accessed with the HTTP API, developers frequently use “self-signed” certificates. Unfortunately, these certificates were not validated in most cases, so some systems may likely be operating with invalid (untrusted, revoked, or expired) certificates. If a Synergy 12 upgrade is applied to such a system, the services with invalid certificates will fail to start.

If you use any cryptographic certificates in your Synergy environment, we recommend reviewing them before you update to Synergy 12 to ensure that they are from a trusted source, have not been revoked, and have not expired.

To minimize the potential impact of this change, we added a new -invcertOK command-line option to the rsynd utility and a corresponding “Allow startup with invalid PEM file certificate” check box to both of the xfServer and xfServerPlus configuration dialogs in the Synergy Configuration Program.

On Windows, it is no longer necessary to maintain your certificates in PEM files, making it easier to manage those certificates. With xfServer and xfServerPlus, a new syntax is available, allowing you to identify the certificate to be used directly from the Windows Certificate Store. And when using the HTTP API, a new “cert_store” keyword can be used in place of a “CA file,” causing the Windows Trusted Root Certification Authorities store to be used for certificate validation. Please refer to the Synergy 12.0 documentation for additional information.

Also, on Windows, the SQL Connection API no longer uses OpenSSL for data packet encryption; it also now uses Microsoft Secure Channel instead.

Other Notable Changes

• On Windows, Unix, and Linux, we have added two new functions called %create_server_connection and %destroy_server_connection that can be used to create and terminate a connection to xfServer. The connection can then be used with subsequent OPEN statements via a new SERVERCONNECTION OPEN statement qualifier. This means that applications can now connect concurrently to multiple xfServer instances.
• We have added a new define SYN_BUILDNUMBER which provides access to the build number of the compiler at compile time
• We have added a limited GroupBy class for use with Select statements to provide a subset of a SQL “GROUP BY” clause functionality. We plan to add more SQL-like functionality in future releases.
• In .NET, we have added GRFA support for READ, READS, WRITE, and WRITES statements when using stream, sequential, relative, and block files.
• We now provide limited support for Global I/O hooks on OpenVMS and have added support for the %DATETIME_TO_I8 and %DATETIME_FROM_I8 routines already available elsewhere.
• We have improved the isutl utility, improving re-index performance, particularly when processing very large files.
• On Windows, the Device Licensing tools now support .NET and .NET Core, and .NET Framework.
• In Workbench, the DPI scaling now adheres to newer Windows gdiScaling, resulting in an improved experience on high resolution and high DPI monitors.
• And also in Workbench, we have added 17 as a selectable target version for JAR files in Java Component Projects.
• The Synergy .NET compiler now supports multi-dimensional arrays of boxed value types.

What About .NET Support on Linux?

In addition to supporting the .NET 6 environment on Windows, we will soon introduce support for running Synergy .NET code in .NET 6 on Linux systems. This capability will not be present in the first 12.1 LTS release but will be introduced in a subsequent update.

This change is particularly important for Linux developers using Harmony Core services, as they will then be able to host their Harmony Core services on the same Linux systems that host their applications code and data, no longer requiring an intermediate Windows server to host the Harmony Core services.

Quality Improvements

In addition to the many new features and enhancements mentioned above, this release also includes quality improvements across all products, and we encourage you to refer to the release notes for your products for complete and detailed information. The release notes can be accessed online from the Feature Release Downloads page.

Windows 11 and Windows Server 2022

Please note that Windows 11 and Windows Server 2022 included some changes to screen painting code at a low level in the operating system, and these changes impacted screen painting by Synergy Windows and UI Toolkit applications on those platforms. We quickly resolved the issue, making some changes in the Synergy runtime. This fix was initially released in Synergy 11.1.1i in November 2021 and is also included in this release. Therefore, if you run any Synergy applications on Windows that use Synergy Windows or UI Toolkit, you need to upgrade to at least 11.1.1i or any later release to run successfully on Windows 11 or Windows Server 2022.

Availability

This release is available for the following platforms and can be downloaded from the Synergex Resource Center:

• Windows (32-bit and 64-bit)
• Linux (32-bit and 64-bit)
• OpenVMS IA64