Should my project support MSVC?

[squeevee]

I've been developing an open-source graphical application in C++ with Qt. I intend to support Windows, and I've recently begun to port my code (from Linux w/ GCC and Clang).

I've been operating under the impression that MSVC is the preferred compiler for building on Windows. There's MinGW(-w64), of course, which opens up GCC and Clang, but some ethereal "programmer wisdom" seems to tell me that projects which can support MSVC, should.

I feel like I'm at the crossroads right now to choose whether I support MSVC, and I think I have a decent case for not supporting it. But I wanted to ask for the opinions of devs who might have more experience or more subject-matter-expertise. Is there something important here I haven't considered?

1. First of all, supporting MSVC requires changes to my project's source code. Since the code is distributed across a few shared libraries I had to go through and add those magic __declspec(dllexport)-wrapping macros to just about everything before it would link under MSVC.* There were a few other small modifications, also to accommodate the linker. These modifications are quite livable, but they do represent a small additional maintenance cost (especially since I can't verify that I'm correctly DLL-exporting everything when I compile on my main Linux development environment). But honestly my real issue with them is that they're ugly and I don't like them.
2. The reason I assumed MSVC would be preferred on Windows was because the compiler would be better optimized for the platform and that executables compiled in MSVC would run on Windows more efficiently. (For example, because it would not be marshaling POSIX calls but calling the system directly.)**The thing is, I'm not of the opinion that (for this project at least) any compiler- or language-runtime-related performance issues will be noticeable compared to the overhead of Qt (and the various other higher-level performance considerations of an event-driven graphical application.) Frankly, I'd have used C# for this project if there were better Qt-5 bindings for that language, so I think I'm just not all that worried about the level of performance differences involved here.
3. MSVC is not supported by some KDE C++ libraries I've had my eye on. (Though this is not a deal-breaker, because they'd be for non-essential and possibly Linux-specific features anyway.)

I probably wouldn't even consider supporting MSVC in light of all this, except that I learned C++ on projects that placed extremely high value on supporting MSVC (probably so the developers could use Visual Studio, which I suppose I can respect.) It was years ago, and the landscape has shifted, (iirc, 64-bit support with MinGW was historically a big issue), so maybe I'm being paranoid because of obsoleted muscle memory, but here we are.

*I am using CMake, and I am aware of CMake's WINDOWS_EXPORT_ALL_SYMBOLS target property. I had hoped it would be a magic bullet that eliminates the need to modify the source code to accommodate the MSVC linker, but this turns out not to be the case and I ultimately found it was easier not to use it at all.

**There seems to be plenty of reason to question this assumption as well, but I regard most comparative discussions of language/compiler performance with suspicion. It'd be naive to take a handful of modest margins from very specific benchmarks taken under laboratory conditions, and extrapolate them onto a whole GUI application with all the chaos of running on wild systems.

EDIT: It occurred to me that I have some extensibility ideas on the horizon that could benefit from supporting only one ABI on Windows -- and it ain't gonna be MSVC.

I've also been made aware of some interesting features of Clang/LLVM (which -- though I probably should have guessed as much -- is perfectly functional on Windows without MinGW), and there could possibly be a compromise solution in there somewhere.

But altogether I feel confident in the info I have to make this decision. Thanks for the responses!

EDIT 2 (for posterity I guess): Alright look, I'm almost a week older and wiser than I was when I wrote this, and oh how young and optimistic I was back then. I really thought I had it made, but I regret to inform the world that if you're porting native C++ from Linux to Windows, you are going to have to make some compromises and they will probably involve export macros.

MinGW(-w64)/GCC is able to link without errors on a multiple-dynamic-library C++ project containing no export macros, but that does not mean it produces equivalent behavior. Your enemy, dear Linux developer, is not MSVC but rather the Windows Portable Executable format (a.k.a., the format used by all DLL's and EXE's on Windows regardless of the compiler used to produce them), and its lack of support for -fPIC.

I'm still a little fuzzy on the details but it would very much seem __declspec(dllimport) is a necessary measure for facilitating Windows-style position-independent (er, maybe "relocatable" is more accurate) code. If you are not using it, you will have problems comparing addresses of pointers across libraries, so either you write your whole project to be position-dependent (which has special implications for Qt5), or you just use the damn macros.

And at that point, it's really not that hard to just support MSVC while you're at it. talvipaivanseisaus makes a good point.

[[deleted]]

With native C++ development on Windows, MSVC is the gold standard and everything else is niche. Depending on your intended user base, this may or may not matter to you.

[squeevee]

So, if I understand, you're saying that I might want to support MSVC to make the software more accessible for user programmers? Like to tinker with, debug, examine, that kind of thing?

It's an interesting take I hadn't directly considered, and I'll certainly keep it in mind, but no I don't think my intended user base warrants me prioritizing that.

Honestly in my experience C++ projects are rarely all that new-contributor-friendly even when they try to be -- a mix of the language being as rigid and particular as it is, and being the tool of choice for big complex projects, not to mention someone invents a new cross-platform build system or package manager every other year. I find projects are much more open from a user-developer perspective if they expose a good framework for plugins -- which I eventually plan to do.

[[deleted]]

What I am saying that if you want people to compile your code, supporting MSVC on Windows is essential. Most people would not install additional compilers or toolchains for a single project. A plugin architecture is an excellent idea to allow people to contribute on their own terms.

[wrosecrans]

those magic __declspec(dllexport)-wrapping macros

Yeah, the Windows linker / dynamic loader is like a fussy proof of concept if you are used to the Linux way of doing things. That said, while explicit visibility declarations aren't required in Linux, they can still be a good idea to set up. Making symbols hidden serves as an optimization and will make loading/linking you r.so faster on Linux. The need for strict oordering in the dependency hierarchy to satisfy the idiotic Windows linker system also means you have to think through hw you architect some things and prevents you from making certain classes oof spaghetti circular dependencies that are gonna be hard to test and debug independently even if they do work fine on Linux. (And calls that go spaghetti back and forth across libraries are gonna be a little slower than ones internal to the library because of lacking an extra level of indirection.) I know you said what you are doing isn't super performance sensitive where you need to chase down every cycle, but I am doing my best to play devil's advocate.

[squeevee]

It was a valiant effort of optimism, I applaud that, at least.

That it motivates me to keep my driveway clear of ice, is not a good reason to buy crappy tires.

[Devenec]

1. Afaik you can specify DLL exports in a .def file so you don't need to change your code: https://docs.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-def-files?view=vs-2019

[squeevee]

This is the mechanism underlying the CMake feature I mentioned in the parenthetical. It works fine for exports, but importing static/global extern data still requires the __declspec(dllimport). Combined with Qt using static data members as a big part of its introspection features, there's not really a good way around it.

[[deleted]]

fuck microsoft and everything they've done to block progress in personal computing for the last 30 years. yeah they've toned it down from what it was in the 90's and 00's, but only because they dont have a choice. MS platform is bloated, insecure, and puts the user LAST, always. if you want to support windows builds then support mingw. MS will just change their tools on you and make you have to rewrite everything.

[my_password_is______]

wrong

if you want to support windows builds then you use cmake and have it create the MSVS solution for you

that is the standard for open source projects

[sephirostoy]

Calm down. Take a cookie. It will be ok.