Uniface 10.3 and Uniface 9.7.05 built using new compilers (updated June 27)

Author: Adrian Gosbell 

With effect from Uniface 10.3 and Uniface 9.7.05, Uniface has been rebuilt with newer C++ compilers on most platforms.   The project is primarily to make Uniface secure on Windows platforms by using a version of the Microsoft Visual Studio (MSVC) that is fully supported by Microsoft.   The windows versions of Uniface 10.3 and Uniface 9.7.05 are both built with Microsoft Visual Studio (MSVC) C++ 2015.   The delivery of Uniface using MSVC 2015 has been a significant project across most Uniface platforms, for example:

• A number of 3^rd party libraries, tools, etc were at a version that were not supported by MS VC 2015, and they had to be updated.
• As we updated those 3^rd party products to new versions, it meant that compilers on Linux, UNIX, I (iSeries, AS/400) also had to be changed to newer versions.
• A number of C++ development techniques have changed
  • New compiler warnings which had to analysed and resolved.
  • Some C++ functions were no longer supported, so the implementation was revised.

All of this is very much ‘under the hood’, and where we have changed the source code, we have also gone through a thorough testing approach to do all we can to prevent a negative impact on the functionality of Uniface, for example:

• Automated test results are compared between ‘before and after’.
• Functionality needing to be reimplemented was also ‘back-ported’ to Uniface 10.2 and Uniface 9.7.05 where feasible and has been delivered in patches. (compiled using MSVC 2005).
• We identified areas where automated test coverage could be improved with new tests or revising existing ones.
• We have a number of customer apps that we have been using for the Uniface 10 project, and where appropriate, we also used those for additional testing.
• We gave early builds to some customers to help with some A/B testing.
• The tech support team have been testing using various test sets, utilities and so forth.

We also took the opportunity to clean up a lot of source code, removing legacy code which is no longer relevant.   There are a number of points to be aware of when using Uniface 10.3 and Uniface 9.7.05. (and upwards).   License Feature: A new license feature (UESC) is required for both Uniface 10.3 and Uniface 9.7.05.   Currency: Due to the changes in compiler versions:

• A number of older operating system versions are no longer supported by Uniface.
• Windows CE is no longer supported or available.
• OpenVMS is not supported. 
• Windows XP will not work.
• Older (unsupported) Java versions are no longer supported.

Please refer to the Uniface 10.3 and Uniface 9.7.05 PAM for details (not published at this time)   User defined 3gl:

• Any user defined 3gl should be recompiled.

Activate statement:

• When using the activate command with a form and without specifying the position, the default position is different.
  • This is functionality controlled by Windows, and we have decided to not try and force the previous behaviour.
  • If exact positioning is required, it can (and should) be specified.

MSVS runtime redistributable: The MSVC 2015 redistributable is required to run Uniface 10.3 and Uniface 9.7.05.

• The MS distributable is included with the Uniface distribution is the version we advise to use. This is the version we use for testing Uniface.
• It does appear that the MSVC 2017 redistributable is backwards compatible and also works, but we have not tested this.
• Older redistributables do not work.
• The Uniface 10.3 and Uniface 9.7.05 installer will automatically install the required runtime in the correct location.
• Using the MG04 Service pack will NOT automatically update the runtime. Our service pack and patch mechanism will only overlay Uniface components.
• Using MG04 will require the download and installation of the distributable from Microsoft.
• The "Microsoft Visual C++ 2015 Redistributable" can be downloaded from Microsoft page: https://www.microsoft.com/en-us/download/details.aspx?id=52685

Distributed License Manager (DLM) 9.1

• DLM has been rebuilt using the newer compilers, including MSVC 2015, and the minor version number has been changed to be 9.1.
• There is no new, additional functionality included or added to DLM.

ICU Language libraries ‘under the hood’ of Uniface, we use CLDR (Common Locale Data Repository) libraries from ICU (International Components for Unicode) for handling of locale (language specific) display and printing.

• In Uniface 9.7.04 and older versions, this was version 4.8, which is not compatible with the newer compilers we are using for Uniface 10.3 and Uniface 9.7.05.
• We have moved to version 5.8 on all platforms where we changed compilers.
• ICU 5.8 has more additional capabilities and functionality, details are available on their website: http://site.icu-project.org/
• Where NLS Display Formats are used, there could be changes in display due to revised or new Unicode standards.
  • An example we found during testing: DIS($NLS(short)) in French will be: dd/MM/yyyy , and was previously: dd/MM/yy
  • In the case of a change when used in a fixed space, for example printing a report, the display could be truncated rather than realigned.
• We will comply with the standards from ICU rather than try and change the old version (and therefore break the standards).
• Note the ICU libraries are solely used for the display and printing of NLS specifics.

Floating Point Rounding Microsoft has made changes to its handling of floating point operations in recent versions of MSVC.

• In the case of some ‘extreme decimal place’ testing, we did see a difference.
• We have not changed Uniface to mimic the previous compiler behavior.
• Further details are available from Microsoft (https://docs.microsoft.com/en-us/cpp/porting/floating-point-migration-issues )

Platforms that we did not change compilers: The HP-UX platform is not supported with Uniface 10, so we decided not to change the compiler or internal libraries as part of the Uniface 9.7.05 delivery.   Update history: Added that OpenVMS is not supported.  Added details of the new license feature

Hi Adrian, as Gianni has said: thanks for the detailed information.   You mentioned that "old 3gl" needs to be recompiled with the new libraries and include files. As I couldn't find a way to download the 2015 compiler from the microsoft pages (and MS has changed it's business model to monthly rates instead of a fixed price) it looks like this task may cost some effort and money for a "one-off activity". For a much easier way my question: Is it possible to do this recompile job for 10.3 with the Visual Studio C++ 2017 Community Edition (downloadable for free)? Greetings from Frankfurt/Germany, Uli

ulrich-merkel said Hi Adrian, as Gianni has said: thanks for the detailed information.   You mentioned that "old 3gl" needs to be recompiled with the new libraries and include files. As I couldn't find a way to download the 2015 compiler from the microsoft pages (and MS has changed it's business model to monthly rates instead of a fixed price) it looks like this task may cost some effort and money for a "one-off activity". For a much easier way my question: Is it possible to do this recompile job for 10.3 with the Visual Studio C++ 2017 Community Edition (downloadable for free)? Greetings from Frankfurt/Germany, Uli  

I will see if I can find out.  BTW, we had mixed results when testing user defined 3gl that was not recompiled. We know using 2015 is the safest, hence the message.  The 2017 compiler is a lot stricter than 2015. I know that getting Scintilla recompiled to it was a real challenge for them. (we use the Scintilla Editor in Uniface 10). 

Hi Adrian, I assume we can just test the strictness of the compiler with the 2017 Community Version against our homebrewd code with the actual includes/libraries so we have a feeling what corrections needs to be done. TIA for your effort, think it would help us customers a lot so we can be prepared for the 10.3 GA, Uli

ulrich-merkel said Hi Adrian, I assume we can just test the strictness of the compiler with the 2017 Community Version against our homebrewd code with the actual includes/libraries so we have a feeling what corrections needs to be done. TIA for your effort, think it would help us customers a lot so we can be prepared for the 10.3 GA, Uli  

Yes, I would assume so. The strictness is a MS thing, not a Uniface thing. 

Just had my first experiments with 2017 Community compiler. My old one was a Visual C++ 6.0  from 1994-1998 After the automatic conversion from my old *.dsw to *.vcxproj, it looked pretty fine, but the build returned a lot of SAFESEH errors. Found a description at: https://stackoverflow.com/questions/10599940/module-unsafe-for-safeseh-image-c

This happens when you link an .obj or .lib that contains code created by an earlier version of the compiler. Which of course would be common if you downloaded a binary for opencv_ffmpeg instead of the source. You can turn the linker option off but then you'll still have a CRT version incompatibility that can byte. Rebuild the library from source. – Hans Passant May 15 at 13:01 

Solution: Disabling option "Image has Safe Exception Handlers" in Project properties -> Configuration Properties -> Linker -> Advanced tab helped me.

So the build run without problems after disabling, further experiments will follow, Uli