# Rippled Windows builds

### Problem

I have been working on building rippled on Windows. I read on stack that newer versions of Visual Studio (> 2017) didn't work, because of an issue with constexpr/static string aliasing.

I did try using the latest compiler (Visual Studio 2022) with the latest toolset, and the recommended boost 1.71 and OpenSSL 1.1, and while rippled built fine, the unittests revealed failures:

478.7s, 209 suites, 1471 cases, 505397 tests total, 269 failures

I had the exact same results with vs 2019, default toolset.

### String aliasing issue?

So I talked with Ed, our resident Windows expert. He pointed me to a [repo](https://github.com/ximinez/staticstring) reproducing the string aliasing difference. Interestingly, the non-aliasing occurs only with the solution file generated by cmake, not with the default solution file.

### More investigation

I figured out that the difference between the two was that the default solution file had:

`Debug Information Format: Program Database for Edit And Continue (/ZI)`

while the cmake generated one had:

`Debug Information Format: Program Database (/Zi)`

So armed with this info, I updated the cmake generated solution file for rippled by setting the [`/ZI`](https://docs.microsoft.com/en-us/cpp/build/reference/z7-zi-zi-debug-information-format?view=msvc-170) flag, and I also had to remove the [`/Gy-`](https://docs.microsoft.com/en-us/cpp/build/reference/gy-enable-function-level-linking?view=msvc-170) flag which [disables Function-Level Linking](https://docs.microsoft.com/en-us/cpp/build/reference/gy-enable-function-level-linking?view=msvc-170).

With these two changes, and after rebuilding, I was able to run the unit tests without failures (both in debug abd release):

509.6s, 209 suites, 1471 cases, 505397 tests total, 0 failures

### The way forward

So the good news is that we have a way to build rippled with the latest msvc compilers, however some questions remain (at least for me):

1. Why do we specifically disable Function-Level linking in our cmake config? My understanding is that enabling it will lead to smaller executables (by removing duplicated functions), but the link with be a bit slower. Was there an issue when it was enabled that caused us to specifically disable it?

2. The [StaticString repo](https://github.com/ximinez/staticstring) shows that in some case, the strings compare equal when we use `strcmp()` to compare them, but not when we compare the pointers. This occurs when declaring a `char const *` pointer initialuzed with a previously declared `constexpr char const *` pointer.

### The solution (maybe)

So Ed (again) pointed me to the right location of the misbehaving code which is in `src/ripple/rpc/impl/RPCHelpers.cpp`. Code in question is:


with the `jss::` StaticStrings reference in the array declaration at the beginning defined as:


What happens is that when the static array at the beginning of `getSeedFromRPC` is initialized with the constexpr strings, the compiler actually copies the string itself (not the pointer) to another memory location and stores in seedTypes the pointer to this new memory location.

So later when we compare `seedType == jss::seed.c_str()`, the comparison always fails even though the strings the pointers point to are identical.

I suggest the following solution: make the array `constexpr` instead of `static`, as was suggested in the comment above the array declaration. While I have not checked with all compilers, this compiles fine and passes the unittests with vs2022.

So the new declaration would be as follows (`static` changed to `constexpr`):


I was a little bit concerned that not having `static` would be slightly slower, as the array of three pointers would be constructed at every call, but upon watching this [video](https://www.youtube.com/watch?v=IDQ0ng8RIqs) I am now pretty convinced that it will be faster if anything.