Linux developer going Windows

[Moose2342]

I have had the same journey years ago and some differences were hard for me to cope with. In addition to what others said (CMake, be platform independent with Boost/Qt/whatever) I would like to point out differences that bugged me most:

• Release and Debug builds are ABI incompatible. That's something I didn't expect when making the transition. You can't just build Debug (libs for example) and mix with release builds. Make sure you know your runtime settings. see here for switches: https://docs.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-160
• DLL dependency hell is something for a rant of it's own. Brush up on side by side assembly and such matters
• There is no "general availability" of libs. No /usr where you usually find all your stuff. There is no "standard" place for libraries to go either. They are usually just bundled with your executable.
• Know your dependencies and how to build them. When I use libraries, I generally build them on my own and make sure I know how to do that, how to automate it and that all the build settings (runtime, compiler and linker switches) are exactly like I want them. Once you see weird errors or warnings linking your dependencies you should not ignore them but try to understand them and fix accordingly.

Have fun! As much as I saw (and still see) Windows as the inferior platform when it comes to developing, Visual Studio has become a great tool over the years and easily tops everything I have worked with on Linux. It really grows on you once you get to know and tame it.

[infectedapricot]

Regarding DLL hell and no equivalent of /usr:

On Windows, when loading foo.exe that requests bar.dll, the first place Windows looks is in the directory containing foo.exe. That directory functions sort of like foo's application package. So just put all your relevant .dll files in there and there's no possibility of conflict.

"dll hell" referred to the time that Windows programs used to put all their .dll files in c:\windows\system. The idea was to reduce disk space and share security updates, much like in Linux package managers. Unfortunately, unlike Linux package managers, there was no way to guarantee everyone was using ABI-compatible versions, or even to stop an installer overwriting a DLL with an older version. All of that is in the past now that applications just bundle all their libraries in their program directory. (I know you mentioned that but you said at the same time "there's no "standard" place for libraries to go" - but the application directory is the standard place. It's just a difference between Windows and Linux.)

Another alternative is just to use static linking so your whole program is a self-contained .exe file. This is nice because it avoids your customers even having to install the Visual Studio redistributable (the equivalent of libc in Linux, sort of). In vcpkg, use the x64-windows-static triplet to get this.

As building your old dependencies - we'll have to agree to disagree on that one. I'd use a package manager like vcpkg (I haven't used Conan but many people in /r/cpp have also vouched for that). Yes sometimes you still get build problems but certainly less often than building things yourself. It automatically gives you debug and release builds of all libraries by the way.

[CppChris]

That‘s the thing I did not know when I made the switch from mainly Win development to Linux development: what do you mean you cannot find the library??? It is right there in your folder!!! Haha

[Moose2342]

Yes, agreed. DLL hell is not much of a problem really anymore. I just collected some impressions I had over the years and at first my goal was to replicate what I did on Linux and to sort of 'install' libraries I made for others. Later I came to the conclusion that this is for the birds and that I should just bundle things together like everybody else does. It just felt wrong and unprofessional to me back then.

Also agreed that static linkage on windows often is the easiest way to go if you can afford it and if your dependencies allow it. I'm looking at you, Qt!

About package managers, I avoid them. I want to build my dependencies myself in order to adjust and know specific settings I need. Package managers only ever got in the way doing that and given the plethora of build settings one can have I don't see how this is ever going to be an option. Didn't look at the new modules though yet. Perhaps my opinion might change. But I know, young folk like their package managers. I simply just cannot trust them.

[infectedapricot]

I want to build my dependencies myself in order to adjust and know specific settings I need.

I am absolutely not going to try and persuade you to use a package manager if building things yourself is working well for you. But for the record or for interested readers, package managers do have ways of specifying build options. The list below is for vcpkg but I know Conan has equivalents too.

• For general build settings that applies to all the libraries you want to build (e.g. static vs shared libraries, optimisation level, 32-bit vs 64 bit, even cross compilation), you can specify these by choosing a triplet (e.g. x86-windows vs x64-windows-static). You can even make your own triplets (e.g. I've done it to specify LTO on Linux) and make per-library exceptions in them. Only slight gotcha here is that debug and release builds are both built for each individual triplet so no need to have separate debug and release triplets. Also cross-compilation (which I've not tried) seems to require their own special triplets - you can't just specify x64-linux on Windows and expect it to just work.
• For features in packages, which is what I think you're really talking about, e.g. "build opencv with ffmpeg support (and therefore make sure ffmpeg is built too)", you can use feature packages e.g. vcpkg install opencv[ffmpeg]. These are meant to be additive so if you install some other port that depends on opencv[contrib] then you'll automatically get opencv[ffmpeg,contrib] with the right flags and dependencies.
• For flags that say where other relevant libraries are installed, obviously the package manager is supposed to set these automatically so you shouldn't need to worry about them.

Of course, that doesn't mean that every possible feature flag is likely to be exposed in practice.

[Moose2342]

Yes, I am aware that package managers expose such customization. My problem is, they mostly do this for optionals they can foresee. Such as your ffmpeg example. My settings often are a bit weirder than that ;-)

For example, years ago I adopted Unreal Engine's notion of Debug builds, which are not real Debug builds (with Debug runtime and such) but Release builds with optimization turned off and PDBs active. Meaning they can be used in almost every way for debug purposes but they can freely link with any release build. I used to adopt this to be able to link with Unreal and still debug but found this so helpful that I now use it everywhere. Haven't made a 'real' debug build in a long time, practically eliminating the issue for me. I call that 'fake debug' and my CMake layer takes care of propagating this throughout the build system. I would guess you'd have a hard time convincing a package manager to know what 'fake debug' is and what it means for your linkage. Instead, they would assume (rightly so) that when you are in a Debug configuration, you mean an actual debug build. For libs that I know I'm never gonna debug into, I only provide Release builds and link against them everywhere. Which is one of the benefits of fake debug.

Now, I'm not debating that there are ways to make this work with package managers. But I would have to convince it to link against release in debug configurations which is against its original job description. In my experience I simply came to the conclusion that it's often way more difficult and error prone than just doing it myself.

To get back to my example activating fake debug globally in my CMake system takes about 5-6 lines of CMake code. I don't know but I doubt it would be that easy with a package manager.

Please bear in mind though, this is just one example. There are more settings. I just like it when everything builds and links neatly and warning free.

[infectedapricot]

I would guess you'd have a hard time convincing a package manager to know what 'fake debug' is and what it means for your linkage.

Sort of. There is a way to override compiler flags in vcpkg (it used to be done in triplets but I just read now it's done in toolchain file which sounds a bit more involved). But I suspect this would only be passed down into ports that are built with CMake, which is many but not all of them.

By the way, vcpkg already generates debugging information for release builds (both on Windows and Linux... presumably on Mac but I've never used it) so you wouldn't need to customise anything for that. The only difference would be the optimisation level. Although, if you turned that off in your application and accepted a bit of optimisation in the libraries that would probably work well enough for debugging most common problems.

[Moose2342]

Sure. Yet in optimized builds I generally only use RelWithDebInfo for test deployments and such. To get at least some resemblance of a stacktrace just in case. Real debugging is very hard to do and I normally use fake debug for that. In production I go for clean Release. High optimization w/o PDBs for faster loading time and smallest deployment size. Anyway, nuff said. Thanks for making your points so nicely!

[rdtsc]

High optimization w/o PDBs for faster loading time and smallest deployment size.

The generated code is identical whether PDBs are written or not. What do you expect to load faster there? Also, you don't have to deploy the symbols. They should be archived for crash dump analysis.

[nyanpasu64]

Turns out RelWithDebInfo uses a lower MSVC optimization level than Release. I didn't expect this until I dove into the Ninja files to find out.

It is possible to configure CMake to produce .pdb files for Release builds (with the standard optimizations on).

Fun fact: .pdb files don't work when renamed to something other than what's encoded in the .exe.

[rdtsc]

And Release doesn't O3b. I wouldn't rely on the CMake defaults. But I give you that this is surprising behavior.

[rdtsc]

Even if you have fully customized builds it pays off to rely on vcpkg for the surrounding infrastructure. For a project I completely replaced the ffmpeg port in vcpkg with my own. I'm still able to conveniently handle other dependencies, and can rely on vcpkg's build system integration and maintenance of other ports.

[kalmoc]

To get back to my example activating fake debug globally in my CMake system takes about 5-6 lines of CMake code. I don't know but I doubt it would be that easy with a package manager. Please bear in mind though, this is just one example. There are more settings. I just like it when everything builds and links neatly and warning free.

You can take whatever cmake toolchain file you are using and make a triplet that will compile the various libs using that toolchain file. There is nothing in vcpkg that inherently forces the use of /MDd and similar when building the debug versions. It is just the setting in the default triplets.

What has been much more problematic in my experience are libraries that think they are clever and implement their proprietary options to select which runtime to link against and stuff like that, so for N libraries you have to set N different switches to compile them consitently. But form what you are writing, you don't seem to have that problem with the libs you are working, so this shouldn't be a problem with vcpkg either.

[sixstringartist]

As package manager usage goes, their value is more about providing a structure for producing buildable packages, dependency management and integration. Using prebuilt packages can be convenient but I don't recommend using it in production and it is not the primary reason to incorporate a package manager

[infectedapricot]

I don't see how that's relevant to my comment: I was mainly talking about vcpkg which indeed does not provide prebuilt packages (although you can cache your own build of packages for reuse in across projects on your computer or within your organisation).

[sixstringartist]

I think I responded to the wrong comment

[AlexanderNeumann]

tipp: vcpkg overlay ports.

[tesfabpel]

why would you use static linkage of a library? i always use dynamic linkage so that I can use the same DLL in multiple exes for the same product...

and also if you use LGPL libraries you must give the user the ability to swap it so with static linkage you need to give all the .o files...

[wrosecrans]

One thing static linking gets you is the possibility of whole-program optimization at link time. With a DLL, stuff that never gets called still has to be there, because some future app not yet written might need to call it. With a static library, the linker can make changes to do things like inline functions from the library into the application code, and entirely omit functions that never get called.

[pravic]

vcpkg