Daniel Nashed's Blog

C-API Visual Studio 2017 Domino 10 and higher

Quite a long post, but I think important for many of my ISV friends. I will update my post once I get an official technote from HCL about this new compiler recommendation.
This week I figured out that already Domino 10 is build with Visual Studio 2017 instead of the old Visual Studio 2010 SP1 (VS2010 SP1) compiler.
For Linux we got the official info, that beginning with Domino 10 we have to switch to the GCC compiler CentOS 7.4.
But there wasn't any official statement for compiling C-API applications for Win64 and the old requirement was to build with VS2010 SP1.
Also existing applications compiled with VS2010 SP1 continue to work in most cases with Domino 10 & 11 in contrast to Linux (glibc incompatibility).

I just found out this week HCL switched to Visual Studio 2017 already beginning with Domino 10.

It makes a lot if sense to switch to the new compiler and rely on the new Universal C run-time (see below).
I never ran into issues with applications compiled with VS2010SP1 but I did some research and testing over the weekend.
This included installing Win2012 R2 and Win2019 from scratch to have no inherited run-time installed. And than tested with Domino 9 and Domino 11.

Universal C run-time in Windows

Microsoft introduced the new Universal run-time which is automatically installed with Win2012+ (just tested installing from scratch with Win2012 R2).
So there are no additional run-time components to install with the new compiler.

The links inside this article are broken. But the article itself is helpful: https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt

Also see the official download page (but it's included already if you are on a support Domino Windows version).
(https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows)


Applications compiled with VS2010 SP1 on new installed Domino 10/11 servers might fail on older Windows server versions!

Domino 9 installs a couple of older Visual Studio runtimes (VS 2005 and VS 2010).
But the current HCL Domino versions only use the Visual Studio 2017 universal run-time.
If you run on an existing environment that has been upgraded, you should be on the safe side, because Domino 9 installed the needed run-times already for you.
But with a breand new Domino 11 server installed, you will miss the old VS2010 run-time!
The first missing file reported is "msvcr100.dll" and you would have to install "Microsoft Visual C++ 2010 SP1 Redistributable Package (x64)"

So this should still work but needs to be taken care of in those edge cases.

Dynamically Linking recommended

Domino itself is dynamically liked with /MD compile switch and this is also the official Microsoft recommendation I found:
"We strongly recommend against static linking of the Visual C++ libraries, for both performance and serviceability reasons"

So you should make sure your are also compiling in the same way if there are no other good reasons to statically link.


Moving to Visual Studio 2017

Over the weekend I updated my production build environment.
I have installed Visual Studio 2017 and have looked into existing makefiles and build scripts.

In my environment I use makefiles. Because this is how I started like 20 years ago and this is what makes a lot of sense for cross platform development.
I have separate makefiles for all the platforms but I looked into standardizing them including some build-commands having W32+W64 on the same machine.

It turned out that we can't continue to use the makefiles as they have been used with Visual Studio 2010.
So if you used the same makfile style Lotus introduced long time about in the sample applications, you need some changes!


SDK Changes

VS2010 was using "Microsoft SDKs\Windows\v7.x", which contained win32.mak.
This file defined a couple of variables used in the sample makefiles like "conlibsmt" and "cvarsmt".

This makefile include is not present in the Microsoft 10 SDK used in Visual Studio 2017.

Without the includes you have to use your own defines. And this is also what you find in the build command line shipped with the C-API toolkit in the "cmp" directory.
The cmp does contain the the original build switches used to build Domino 9. They should still be fine with the new compiler. At least in my tests they worked well.
See my example makefile below. This is my current working makefile for testing. And I will have to convert makefiles for all of my applications step by step.



Use of new features with current WINVER

For one of my applications I had to increase the minimum OS version when compiling with VS2010 when working on a punycode research project (needed for DNS resolution for none ASCII chars).

I set /DWINVER=0x0600 which would be the equivalent of Windows Vista / Server 2008.

The default WINVER compiled by VS2010 SP1 is 0x0500 (Windows 2000) and for VS2017 the default is 0xA00 (Windows 10).

The table here does not show the current server versions https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt

But I looking into other build numbers it should be the following mapping:

Windows 8	Windows Server 2012
Windows 8.1	Windows Server 2012 R2
Windows 10	Windows Server 2016

So if we want to ensure compatibility with Win 20012 we should probably stay with /DWINVER=0x0602 (Windows 2012).



Conclusion

The step to move to Visual Studio 2017 is a very positive and good move!
And using the Universal C run-time in future will make things easier in future.
Dynamically linking in this context makes also a lot of sense. And we are on the safe side using the same compilers and link options than HCL.
-- Daniel


Appendix: Simple Example Makefile W64 C-API Servertasks with Visual Studio 2017

This is the example from my punycode tests where I changed the WINVER earlier.
You will usually not link with Normaliz.lib Ws2_32.lib Kernel32.lib.. But that was needed in my case.


# C-API makefile
# Nash!Com / Daniel Nashed
# Windows 64-bit version using
# Microsoft Visual Studio 2017

PROGRAM=nshidn

NODEBUG=1

# Link command

n$(PROGRAM).exe: $(PROGRAM).obj
        link /SUBSYSTEM:CONSOLE $(PROGRAM).obj notes0.obj notesai0.obj notes.lib msvcrt.lib user32.lib Normaliz.lib Ws2_32.lib Kernel32.lib /PDB:$*.pdb /DEBUG /PDBSTRIPPED:$*_small.pdb -out:$@
        del $*.pdb $*.sym
        rename $*_small.pdb $*.pdb

# Compile command

.c.obj:
        cl -nologo -c -D_MT -MT /Zi /Ot /O2 /Ob2 /Oy- -Gd /Gy /GF /Gs4096 /GS- /favor:INTEL64 /EHsc /Zc:wchar_t- /DWINVER=0x0602 -Zl -W1 -DNT -DW32 -DW -DW64 -DND64 -D_AMD64_ -DDTRACE -D_CRT_SECURE_NO_WARNINGS -DND64SERVER -DPRODUCTION_VERSION /DUSE_WIN32_IDN  $*.c

all:
        n$(PROGRAM).exe

clean:
        del *.obj *.pdb *.exe *.dll *.ilk *.sym *.map

• Comments [4]