Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

C-API Visual Studio 2017 Domino 10 and higher

Daniel Nashed  31 May 2020 15:53:29

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

1Pavel  31.05.2020 17:23:39  C-API Visual Studio 2017 Domino 10 and higher

Hi!.

It's a good news!

Mr. Nash, could you post an example capi application for linux?

For example: getting the server name.

I think that will be enough to demonstrate this.

It will also show that you can work with Domino not only with DDE.

I know how to do in C # and the library "Interop.Domino.dll". But a client is required for the connection ... which limits me in choosing the OS.

TNX!

2Daniel Nashed  31.05.2020 20:54:53  C-API Visual Studio 2017 Domino 10 and higher

Hi Pavel,

the C-API toolkit is full of examples. Check the samples directory.

Most of the examples are working on Linux.

The examples have makefiles for Linux. You just need to remove the "-lnsl" from the libs that you link against.

The C-API toolkit is cross platform like Domino itself ..

-- Daniel

3John Curtis  31.05.2020 21:00:16  C-API Visual Studio 2017 Domino 10 and higher

You wouldn't believe what we were using before v10. Maybe you would. Good post though, and THANK YOU.

4John Detterline  01.06.2020 20:15:12  C-API Visual Studio 2017 Domino 10 and higher

Have the updated the documentation for the C API to reflect the new compilers?

Archives


  • [IBM Lotus Domino]
  • [Domino on Linux]
  • [Nash!Com]
  • [Daniel Nashed]