cleanup: support Win64 builds on Windows 11

[ericjbohm]

If you do the following, you can build charm++ on windows 0. install WSL, Cygwin64, and Visual Studio Community

1. launch a Native x64 Developer Command Prompt for Visual Studio 2022
2. wsl
3. /cygwin/c/cygwin64/bin/bash --login
4. cd charm
5. ./buildold charm++ multicore-win-x86_64 msvc -j --with-production

These changes update the unix2nt_cc wrapper script to inherit the necessary path information from Windows (via WSL and Cygwin). Some additional changes disable a few problematic edge cases and turn off the building of charmrun (which never worked on windows).

[evan-charmworks]

This PR makes a mess. Building on 64-bit Windows is fully supported. (Charm does not support 32-bit Windows any more.) I wrote the following wiki article to document how to do it. https://github.com/charmplusplus/charm/wiki/Building-Charm-on-Windows

I don't agree with disabling charmrun. It builds fine, even if not fully featured compared to Linux.

Any preprocessor line that already mentions _WIN32 does not need to be changed. _WIN32 is defined regardless of the target bitness. defined(_WIN32) || defined(_WIN64) is redundant.

[ericjbohm]

This PR makes a mess. Building on 64-bit Windows is fully supported. (Charm does not support 32-bit Windows any more.) I wrote the following wiki article to document how to do it. https://github.com/charmplusplus/charm/wiki/Building-Charm-on-Windows

I don't agree with disabling charmrun. It builds fine, even if not fully featured compared to Linux.

Any preprocessor line that already mentions _WIN32 does not need to be changed. _WIN32 is defined regardless of the target bitness. defined(_WIN32) || defined(_WIN64) is redundant.

I wish I'd checked for that wiki page before. It did not come up in my google searches. The bulk of the _WIN64 changes were in aid of getting compilation to go through with only Cygwin GCC. A tack I eventually abandoned in favor of the WSL + Cygwin + MSVC approach.

I'll work on a different commit to reconcile the MSYS2 approach described in the Wiki page with this WSL based scheme so that either scheme can be used. I will also check to see how charmrun is being handled in the MSYS2 multicore scheme for to the multicore-win target, where it is entirely redundant and is creating a basically pointless build failure for my scheme.

[ericjbohm]

Interesting side note: for reasons that elude me, NAMD3 is about 10-20% faster when compiled via the WSL scheme than it is when compiled using the MSYS2 scheme. Running the equivalent linux binary via WSL is always faster than either of the former approaches, but that is attributable to known Windows 11 issues.

[evan-charmworks]

Interesting side note: for reasons that elude me, NAMD3 is about 10-20% faster when compiled via the WSL scheme than it is when compiled using the MSYS2 scheme.

Do these measurements hold when controlling for which shell is used to run them? How about multicore builds?

[ericjbohm]

Interesting side note: for reasons that elude me, NAMD3 is about 10-20% faster when compiled via the WSL scheme than it is when compiled using the MSYS2 scheme.

Do these measurements hold when controlling for which shell is used to run them? How about multicore builds?

Yes, the performance difference is invariant. I can run both binaries in the MSYS2 environment or WSL and see the WSL version out perform MSYS2 in the same way in both environments. So far, I have only measured the multicore builds, as those are what 99% of our windows users will be using.